In this article:
- The Testing Decision Framework: What Do You Actually Need?
- Performance and Bench Testing: Proving Your Device Works
- Software Validation for Medical Devices: IEC 62304 and FDA Expectations
- Biocompatibility Testing for Medical Devices: ISO 10993 Framework
- Specialized Testing Requirements
- Testing Strategy: Sequence and Timing
- Common Testing Failures That Trigger FDA Retesting
- The Fastest Path to Market
- Critical Takeaways
FDA expects performance testing that demonstrates your device functions as intended and does not raise different questions of safety or effectiveness compared to your predicate. The scope of testing depends on device type, risk, and technological differences, but most 510(k)s include bench or performance testing, software validation where applicable, and biocompatibility assessment for patient-contacting components. This guide shows you exactly which tests FDA requires for your specific device type, how to determine test methods that FDA will accept, and how to avoid the expensive retesting trap.
The Testing Decision Framework: What Do You Actually Need?
FDA does not publish a universal testing checklist. Performance testing expectations are risk-based and depend on your device’s intended use, technological characteristics, and how it compares to the predicate device. This framework helps determine what FDA is likely to expect.
Question 1: Does Your Predicate’s 510(k) Describe Testing?
Start with the predicate’s publicly available 510(k) summary, typically under sections like “Performance Testing” or “Non-Clinical Testing.”
If the predicate lists specific tests, FDA generally expects you to:
- Address the same testing areas, and
- Use the same or scientifically justified equivalent methods, and
- Demonstrate comparable performance relative to the predicate
If the summary is vague or incomplete:
- Review similar devices in the same classification
- Consider requesting the full submission through FOIA (which can take weeks to months)
- Use a Pre-Submission meeting to clarify FDA’s expectations
Illustrative example (infusion pump): Predicate testing may include flow accuracy, occlusion pressure, alarm performance, electrical safety, and EMC testing. FDA would typically expect you to address these areas unless you can justify why a specific test does not apply.
Question 2: Are There Technological Differences From the Predicate?
For each technological difference, FDA expects you to explain how it is addressed.
Key questions:
- Does the difference affect safety or effectiveness?
- How is that risk evaluated or mitigated?
- What evidence supports equivalence?
Not every difference requires new testing, but every difference must be addressed, often through testing, analysis, or both.
Examples:
- Material change: May require strength testing, corrosion analysis, and biocompatibility evaluation depending on contact type
- Added software or connectivity: May require software validation, cybersecurity assessment, and wireless coexistence testing
Question 3: Does FDA Guidance Specify Expectations?
Search for device-specific FDA guidance and special controls related to your classification.
If guidance exists, FDA generally expects submissions to align with the testing described, or clearly justify any deviations. Guidance often references recognized consensus standards (ISO, IEC, ASTM) that FDA reviewers rely on.
Example: For continuous glucose monitoring systems, FDA guidance highlights expectations around accuracy, interference testing, user performance, and software validation beyond basic bench testing.
If no guidance exists, FDA typically looks to recognized standards and a well-documented risk-based rationale.
Question 4: What Is Your Device Classification?
- Class I (often 510(k)-exempt): Testing is still expected to support basic safety and performance, depending on risk.
- Class II (most 510(k)s): Non-clinical performance testing is usually required to demonstrate substantial equivalence and meet any applicable special controls.
- Class III (PMA): Requires extensive non-clinical and often clinical evidence and is beyond the scope of this guide.
The Reviewer’s Core Question
Across all device types, FDA is ultimately asking:
Structuring your testing strategy around that question, and clearly linking differences to data, is what prevents rework and delays.
Performance and Bench Testing: Proving Your Device Works
Performance testing provides objective evidence that your device meets its design specifications and does not raise different questions of safety or effectiveness compared to the predicate device.
The exact tests FDA expects depend on device type, intended use, and technological characteristics.
Representative Performance Testing by Device Category
Mechanical and Implantable Devices
Common testing areas may include:
- Dimensional verification and tolerances
- Mechanical strength and fatigue
- Wear and durability under simulated use
- Corrosion resistance for metallic components
Example (orthopedic fixation): Testing often evaluates axial strength, torsional performance, and cyclic loading using applicable ASTM standards, with test parameters selected to reflect clinical use.
Fluid Management Devices
Testing may address:
- Flow rate accuracy across operating range
- Pressure resistance and leak integrity
- Occlusion detection or response behavior
Example (IV catheter or pump): Flow performance and kink resistance are commonly evaluated under representative pressure and orientation conditions.
Diagnostic Devices
Performance testing typically includes:
- Analytical sensitivity and specificity
- Precision and repeatability
- Accuracy relative to a reference method
- Environmental and interferent testing
Example (blood glucose monitoring): Accuracy and precision testing is often aligned with the applicable version of ISO 15197, along with evaluation of common interferents and environmental conditions.
Surgical Instruments
Testing may include:
- Functional performance (cutting, clamping, actuation)
- Reprocessing and durability for reusable devices
- Compatibility with sterilization cycles
Comparative Performance Testing: You vs. the Predicate
When technological characteristics differ, FDA often expects comparative performance data demonstrating that your device performs comparably to the predicate.
A typical approach includes:
- Identifying relevant predicate specifications
- Using the same or scientifically justified equivalent test methods
- Testing both devices under identical conditions
- Comparing results using predefined acceptance criteria
Complizen’s comparison tables help teams map predicate specifications directly to test results, making equivalence easier to assess during review.
Test Method Selection
FDA generally prefers:
- Same test methods used by the predicate, when available
- Recognized consensus standards (ISO, IEC, ASTM, AAMI)
- FDA-recognized standards listed in FDA’s database
- Internally validated methods, when no standard exists (with justification)
Using updated or alternative standards is acceptable when scientifically justified and clearly explained.
Sample Size and Data Analysis
FDA does not prescribe fixed sample sizes. Instead, reviewers expect:
- Sufficient samples to support reliable conclusions
- Predefined acceptance criteria
- Appropriate statistical analysis when making comparative claims
Failures should be fully documented, including root cause analysis and any design changes, with retesting as needed.
The Reviewer’s Perspective
FDA reviewers are not checking whether you ran a lot of tests. They are asking:
Structuring performance testing around that question, and clearly linking differences to data, is what prevents rework and delays.
Software Validation for Medical Devices: IEC 62304 and FDA Expectations
If your device includes software or firmware, FDA expe cts software validation evidence demonstrating that the software performs as intended and does not introduce unacceptable risk. While FDA does not mandate a specific standard, IEC 62304 is a commonly used, FDA-recognized framework for organizing software lifecycle activities.
Software Safety Classification (IEC 62304)
IEC 62304 categorizes software based on the severity of harm that could result from a software failure:
- Class A: No injury or damage to health possible
- Class B: Non-serious injury possible
- Class C: Death or serious injury possible
Classification is determined by:
- Software-related hazard analysis
- Worst-case failure modes
- Severity of potential harm
- Integration with overall device risk management
The classification must be justified and documented as part of the device risk analysis.
Software Lifecycle Evidence FDA Commonly Expects
The scope of software documentation scales with risk and software safety class. FDA generally looks for evidence covering:
- Software requirements and architecture
- Risk management applied to software hazards
- Verification and validation activities
- Traceability showing requirements are tested
Under IEC 62304, higher-risk software requires deeper lifecycle control, including more extensive testing, formal risk management, and change control processes.
Core Software Documentation in a 510(k)
FDA commonly reviews:
Software Description
- Architecture and major components
- Operating environment and hardware dependencies
- Third-party software and SOUP components
- Software safety classification rationale
Software Requirements
- Functional and performance requirements
- User interface and alarm behavior
- Safety and fault-handling requirements
Verification and Validation Evidence
- Test plans and protocols
- Executed test results
- Anomaly resolution
- Traceability linking requirements to tests
Cybersecurity Expectations (2023 FDA Rule)
For devices with connectivity, updateable software, or network interfaces, FDA now enforces premarket cybersecurity requirements under the 2023 final rule.
FDA typically expects:
- A Software Bill of Materials (SBOM)
- Secure development practices documentation
- Vulnerability management and patching processes
- Evidence of security testing appropriate to risk
Testing may include penetration testing, vulnerability scanning, authentication controls, encryption verification, and secure update mechanisms, depending on device risk.
AI and Machine Learning Software
For devices using AI or ML, FDA focuses on:
- Training and validation dataset representativeness
- Performance metrics and robustness
- Bias assessment across populations
- Handling of edge cases
FDA has emphasized the importance of a Predetermined Change Control Plan (PCCP) for systems that may evolve post-market.
The Reviewer’s Core Question
Across all software-enabled devices, FDA is asking:
Clear classification, traceable documentation, and risk-aligned testing are what prevent software-related AI requests.
Biocompatibility Testing for Medical Devices: ISO 10993 Framework
For devices with direct or indirect patient contact, FDA expects a biological evaluation demonstrating that materials do not introduce unacceptable biological risk.
This evaluation is typically structured using ISO 10993-1, an FDA-recognized consensus standard.
Importantly, FDA expects a risk-based evaluation, not automatic testing.
Step 1: Define Contact Type
ISO 10993-1 categorizes devices by how they contact the body:
- Surface contact: Intact skin, mucosal membranes, breached or compromised surfaces
- External communicating: Blood path, tissue, bone, dentin, or circulating blood
- Implant: Tissue, bone, or blood
Correctly classifying contact type is foundational, as it drives which biological risks must be addressed.
Step 2: Define Contact Duration
Duration further influences testing expectations:
- Limited: ≤24 hours
- Prolonged: >24 hours to 30 days
- Permanent: >30 days
Shorter duration and less invasive contact generally correspond to lower biological risk.
Step 3: Identify Biological Endpoints to Address
ISO 10993-1 provides a matrix of biological endpoints to consider, based on contact type and duration. These may include cytotoxicity, sensitization, irritation, systemic toxicity, genotoxicity, implantation, and hemocompatibility.
Not every endpoint requires new testing. FDA allows endpoints to be addressed through:
- Existing test data
- Predicate device data
- Material characterization
- Scientific rationale
The key is that every relevant biological risk is addressed and justified.
Using Predicate Biocompatibility Data
FDA may allow you to reference predicate biocompatibility data only when equivalence is well supported.
Common acceptable scenarios include:
- Identical material composition, processing, and sterilization
- Equivalent or less risky contact type
- Equivalent or shorter contact duration
For example, referencing implant-grade material data for a lower-risk surface-contact application may be acceptable if equivalence is clearly demonstrated.
FDA will closely scrutinize these claims and typically expects:
- Material specifications and certificates
- Processing and sterilization details
- Clear justification for biological equivalence
Chemical Characterization (ISO 10993-18)
FDA increasingly emphasizes chemical characterization as part of biological evaluation, particularly for:
- New or novel materials
- Prolonged or permanent contact
- Materials with limited clinical history
Chemical characterization involves identifying potential extractables and leachables and performing a toxicological risk assessment to determine whether biological testing can be reduced or avoided.
For well-characterized, widely used medical-grade materials, FDA may accept a rationale in place of extensive testing, provided it is well documented.
The Reviewer’s Core Question
FDA reviewers are asking:
Over-testing wastes time and money. Under-justifying triggers AI requests. The goal is a complete, risk-based biological evaluation.
Specialized Testing Requirements
Beyond performance, software, and biocompatibility, many device types require additional testing to support safety, labeling claims, and substantial equivalence.
Sterilization Validation
Applies to: Any device labeled “sterile.” FDA expects sterilization information appropriate to the sterilization method and the device’s intended use.
Common sterilization standards by method (as applicable):
- Ethylene Oxide (EO): ISO 11135
- Moist Heat (Steam/Autoclave): ISO 17665
- Radiation: ISO 11137
- Low-temperature processes (including VH2O2): often supported using ISO 14937 as a general framework, plus process-specific evidence
Typical validation elements (often described as IQ, OQ, PQ):
- Installation Qualification (IQ): evidence the sterilization equipment is installed and configured properly
- Operational Qualification (OQ): evidence the process operates within defined parameters, including worst-case conditions
- Performance Qualification (PQ): evidence the validated process consistently achieves sterility for your defined load and packaging configuration, often using repeated successful cycles under worst-case conditions
Sterility assurance: Terminal sterilization is typically validated to a sterility assurance level (SAL) of 10⁻⁶, unless an alternative approach is scientifically justified.
Common mistake: treating sterilization as a late-stage checkbox, then discovering material, packaging, or functional degradation after sterilization. That creates redesign loops.
Packaging Validation
Applies to: sterile barrier systems and any device with shelf-life claims. Packaging validation is commonly structured around ISO 11607 (FDA-recognized).
Common test categories include:
Package integrity and seal quality
- Seal strength testing (commonly ASTM F88)
- Package integrity tests, such as burst, leak, or dye-based methods, depending on packaging type and risk
Distribution and transit simulation
- Distribution testing commonly follows ASTM D4169 (FDA-recognized) or an ISTA procedure appropriate to the distribution environment.
Aging and shelf life
- Real-time aging supports the labeled shelf life directly
- Accelerated aging is often designed using ASTM F1980 guidance, with clearly justified assumptions and acceptance criteria
Important correction: Avoid presenting a single “Q10 conversion” as a universal rule. FDA reviewers will look for the assumptions, rationale, and validation plan, not a shortcut formula.
Electromagnetic Compatibility
Applies to: many electrically powered medical devices, especially medical electrical equipment within scope of IEC 60601 standards. FDA has guidance describing how EMC is evaluated, often using IEC 60601-1-2 or another appropriate recognized standard.
EMC testing typically evaluates:
- Emissions, so your device does not disrupt other equipment
- Immunity, so your device maintains essential performance during expected electromagnetic disturbances
Practical tip: early pre-compliance checks on prototypes can reduce late-stage surprises.
Electrical Safety
Applies to: many medical electrical devices, often assessed using the IEC 60601-1 series where applicable. FDA references the 60601/80601 family as part of the recognized standards landscape for medical electrical equipment.
Electrical safety testing commonly includes:
- Leakage currents and grounding
- Insulation and dielectric strength
- Temperature and mechanical safety
- Ingress protection where relevant
Applied parts (IEC 60601-1 concept):
- Type B, BF, CF classifications depend on how the applied part contacts the patient and the required protection level.
Note: Electrical safety and EMC testing are often coordinated together in the same test program.
Testing Strategy: Sequence and Timing
A well-planned testing sequence reduces redesign loops, minimizes retesting, and shortens the path to clearance. FDA does not prescribe a single testing order, but reviewers expect a logical, risk-based progression aligned with design controls and substantial equivalence.
Early Design and Feasibility (Prototype Stage)
Purpose: Identify fundamental technical or material issues before design lock.
Typical activities include:
- Feasibility testing to confirm basic functionality
- Material compatibility and fit checks
- Preliminary performance characterization
- Informal EMC or electrical screening to identify obvious risks
This work is usually performed internally or with non-submission labs and is not intended for FDA review. The goal is rapid learning, not regulatory evidence.
Design Verification (Production-Equivalent Configuration)
Purpose: Demonstrate that the finalized design meets engineering and performance specifications.
Often includes:
- Full bench and performance testing across operating ranges
- Software verification activities (unit and integration testing)
- Reliability and durability testing
- Initiation of biocompatibility evaluation once materials are locked
- Preliminary packaging and labeling evaluations
Verification testing may be performed using internal resources or external laboratories, depending on test complexity and independence requirements.
Design Validation (Market-Ready Configuration)
Purpose: Demonstrate that the device meets user needs and intended use under expected conditions.
Common validation activities include:
- Human factors validation
- Sterilization validation using production-equivalent devices and packaging
- Packaging validation, including aging where shelf life is claimed
- Final electrical safety and EMC testing on the validated design
- System-level software validation
At this stage, design changes should be minimal. FDA reviewers expect validation evidence to reflect the device configuration that will be marketed.
Parallel vs. Sequential Testing
Testing often performed in parallel to save time:
- Performance testing and biocompatibility (using separate samples)
- Electrical safety and EMC (often coordinated in a single lab program)
- Software verification alongside bench testing
Testing that often must follow a sequence:
- Design stabilization before final validation
- Sterilization validation before final packaging validation (for terminally sterilized devices)
- Aging studies before making shelf-life claims
The exact sequence depends on device design, sterilization method, and packaging configuration. There is no one-size-fits-all order.
Using Predicate Devices to Inform Testing Strategy
A practical risk-reduction approach is to study how your predicate device was tested, using publicly available information.
Review the predicate’s 510(k) summary to identify:
- Types of testing performed
- Standards referenced
- Claimed performance parameters
Aligning your test methods and sequencing with an FDA-cleared predicate does not guarantee acceptance, but it often reduces reviewer uncertainty because the approach has precedent within the same device type.
The Reviewer’s Lens
FDA is not evaluating whether you followed a “phase model.” They are asking:
Clear sequencing, documented rationale, and alignment with predicate precedent make that answer easy.
Common Testing Failures That Trigger FDA Retesting
Many Additional Information (AI) requests stem from avoidable testing mistakes. These issues frequently force partial or full retesting and extend review timelines.
Failure#1: Using the Wrong Test Method
Scenario: You perform testing using one method, while your predicate device used a different method. FDA requests retesting using the predicate’s approach or a justified equivalent.
Why FDA cares: Test methods define how performance is measured. If methods differ, results may not be comparable, even if performance looks acceptable.
Prevention:
- Identify test methods used by your predicate device
- Use the same method where possible, or clearly justify scientific equivalence
- Document the rationale before testing begins
Failure#2: Inadequate Sample Size or Statistics
Scenario: You submit testing based on a small number of samples without statistical justification. FDA questions whether results are representative.
Why FDA cares: FDA evaluates whether your data adequately supports safety and effectiveness claims, not whether a specific sample count was used.
Prevention:
- Follow recognized standards where sample sizes are defined
- Use statistical rationale tied to variability and risk
- Define acceptance criteria and analysis methods before testing
Failure#3: Formal Testing Before Design Is Stable
Scenario: You complete formal testing, then make a design change that affects performance, materials, or interfaces. Testing must be repeated.
Why FDA cares: Validation evidence must reflect the final marketed design.
Prevention:
- Use informal or feasibility testing during development
- Lock design inputs and outputs before regulatory testing
- Reserve certified testing for production-equivalent configurations
Failure#4: Sterilization Effects Discovered Too Late
Scenario: Sterilization is validated, but post-sterilization testing reveals degraded performance, material changes, or functional failures.
Why FDA cares: Sterilization is part of the device lifecycle. Performance must be acceptable after sterilization.
Prevention:
- Evaluate device performance following sterilization when materials or function could be affected
- Incorporate post-sterilization checks into your validation strategy
- Consider worst-case sterilization conditions
Failure#5: Missing a Required Specialized Test
Scenario: Your device is subject to Special Controls or device-specific guidance requiring a particular test, which was not included in the submission.
Why FDA cares: Special Controls are legally binding requirements for that device type.
Prevention:
- Verify device classification and Special Controls early
- Review FDA guidance documents for your product code
- Align your test plan explicitly to those requirements
Failure#6: No Comparative Data to Predicate
Scenario: You submit standalone testing showing your device works, but do not demonstrate equivalence to the predicate device.
Why FDA cares: 510(k) clearance is based on substantial equivalence, not standalone performance.
Prevention:
- Perform side-by-side testing against the predicate where feasible
- Use identical test methods and conditions
- Present results in direct comparison tables
The Reviewer’s Question
FDA is not asking:
They are asking:
Clear planning, documented rationale, and predicate-aligned testing prevent most retesting scenarios.
The Fastest Path to Market
No more guesswork. Move from research to a defendable FDA strategy, faster. Backed by FDA sources. Teams report 12 hours saved weekly.
Critical Takeaways
- Your predicate’s testing informs your strategy, not a guarantee.Using the same test methods, standards, and acceptance criteria as a cleared predicate reduces FDA uncertainty, but differences must still be justified scientifically.
- Testing scope varies widely by device.Electrically powered, software-driven, sterile, or implantable devices typically require broader testing than simple mechanical products. Plan for contingencies.
- Some tests inherently take time.Sterilization validation, aging studies, and reliability testing often drive timelines. Parallel testing can shorten schedules when design allows.
- Wrong test methods trigger AI requests.FDA frequently asks for retesting when submitted methods differ from predicate methods without clear equivalence justification. Verify methods before formal testing.
- Biocompatibility data reuse requires true material equivalence.Identical composition, processing, sterilization, and contact conditions must be justified. If equivalence cannot be demonstrated, independent testing is expected.
- Software validation effort scales with risk, not price tags.Higher software safety classes require more lifecycle evidence, deeper testing, and stronger traceability. FDA evaluates adequacy, not spend.
- Validate production-equivalent devices.FDA expects verification and validation evidence to reflect the configuration that will be marketed. Design changes after testing often invalidate results.
- Comparative testing is central to substantial equivalence.Standalone performance data is rarely sufficient. Side-by-side comparison to the predicate, using the same methods, makes equivalence clear.
- Special Controls are mandatory.Device-specific requirements in the FDA classification database must be addressed explicitly. Missing them almost always results in an AI request.
- Pre-Submission meetings reduce risk.Early FDA feedback on testing plans helps avoid misaligned test strategies and late-stage surprises.

