How do you know a medical device is ready for verification, validation, and manufacturing transfer?
A readiness framework for medical device program leaders moving from development into formal testing and production.
The direct answer
Verification requires stable, approved inputs and objective evidence that outputs meet those inputs. Validation requires something harder: units built using the actual materials, processes, and tooling intended for commercial production. Design transfer is complete only when manufacturing suitability has been verified and documented, not assumed.
If your program is using lab prototypes for formal validation, if test protocols are being written around current results rather than approved requirements, or if your traceability matrix has gaps, you are not ready. Proceeding anyway does not save time. It borrows it, at compounding interest.
This resource sets out nine questions to answer before committing to formal V&V and manufacturing transfer, each with what has to be true to answer yes, grounded in current FDA requirements, ISO standards, and recent enforcement evidence.
What goes wrong when a design is frozen too early?
The pressure to begin formal testing builds long before a design is ready for it. Runway is finite, program milestones drive resource allocation, and the visible output of V&V (protocols, test reports, data) feels like progress in a way that continued development work does not.
Beginning formal testing before the design has earned it creates the illusion of acceleration while building a debt that comes due later. Kapstone Medical calls it Safety Debt: a compounding liability created when a device is validated using processes, materials, or configurations that will not survive the transition to full-scale production 1. The concept mirrors technical debt in software, except the interest payments arrive as re-validation campaigns, regulatory delays, or recalls.
Safety Debt accumulates quietly. A startup achieves 510(k) clearance using a lab-scale process. The device works and the submission succeeds. Then manufacturing begins, and the process validated at ten units per week cannot produce ten thousand. The materials supplier qualified for prototyping cannot meet production volumes. The hand-assembled validation units performed beautifully, but the automated line introduces variability the test protocols never anticipated.
At that point the original validation data may no longer support the device. The clearance was earned on evidence from a process that no longer exists. The company then chooses between expensive re-validation and the quiet accumulation of risk that eventually surfaces as a field failure.
In early 2026, Abbott Diabetes Care faced two FDA actions on the FreeStyle Libre 3 platform. A January 23, 2026 warning letter found that Abbott's design transfer process did not ensure that sensor accuracy performance specifications were translated into manufacturing specifications for its third-party manufacturer, and that the contract manufacturers responsible for final assembly and release were not required to verify finished-device accuracy before release 14. Days later, on February 2, the FDA classified a separate recall of certain FreeStyle Libre 3 and Libre 3 Plus sensors as Class I, the most serious category, citing 860 serious injuries and seven deaths reported as of January 7, 2026 15. The FDA has not publicly linked the two. What the warning letter describes is a transfer gap, not a design flaw.
Teams that defer manufacturing reality are usually resource-constrained and making rational short-term decisions. The regulatory system does not forgive the gap. The requirement is explicit. The legacy FDA regulation required design validation on "initial production units, lots, or batches, or their equivalents" 20, and ISO 13485 Clause 7.3.7, now incorporated by the QMSR, requires validation on representative product, which the standard notes includes initial production units, batches, or their equivalents 5. There is no exception for startups or for schedule pressure.
The pattern holds at scale. Medical device recalls reached a four-year high in 2024 with 1,059 events, and Class I recalls hit their highest level in fifteen years, according to Sedgwick's recall index. Device failure became the leading cause of recalls for the first time in more than five years, at 11.1% of events, with software the second-leading cause 19. Designs are being transferred into production before the evidence supports the transition.
What does the February 2026 QMSR require for design transfer?
On February 2, 2026, the FDA's Quality Management System Regulation (QMSR) took effect, replacing the Quality System regulation that had governed medical device manufacturing since 1997. The QMSR incorporates ISO 13485:2016 by reference, aligning United States requirements with the standard already relied on in Canada, Europe, and other major markets 3.
For design transfer, the old 21 CFR 820.30(h), which required manufacturers to "establish and maintain procedures to ensure that the device design is correctly translated into production specifications" 20, has been replaced by ISO 13485 Clause 7.3.8. The new clause is more explicit about what that translation has to demonstrate.
Clause 7.3.8 requires three things. Procedures for the transfer must be documented. Design outputs must be verified as suitable for manufacturing before they become final production specifications, which a working prototype does not establish on its own. And production capability must be confirmed able to meet product requirements 4.
The word "verified" is doing significant work. It means objective evidence: documented proof that the design, as specified, can be manufactured consistently using the intended production processes. Engineering judgment alone does not satisfy it, and neither does verbal confirmation from the manufacturing team or the fact that a prototype was successfully assembled. This is a higher bar than many programs realize until an inspector asks to see the evidence.
Informal handoffs, where an engineer walks a drawing package to the production floor and answers questions as they arise, have never met the requirement, and the QMSR makes the evidence expectation explicit. The FDA has also removed the previous exceptions under § 820.180(c), so inspectors can now review management reviews, quality audits, and supplier audit reports that were previously shielded 3.
The distinction every program leader must internalize:
Design verification asks: did we design the product we said we would? It confirms that design outputs meet design inputs. It can often be performed before all production equipment is in place, though the further your test units diverge from production, the greater the risk that verified performance will not translate.
Design validation asks: did we design the right product? It confirms that the device meets user needs and intended uses under real-world conditions. It must be performed on production-equivalent units, built using the materials, processes, and controlled documentation intended for commercial manufacturing 2 5.
Treating these as sequential phases of one activity is a frequent cause of delay. Verification can begin earlier, on subsystems, using units that may not yet be production-equivalent, with justification. Validation comes later, requires the full system, and demands production-equivalent units under realistic use conditions. Programs that conflate them discover too late that their verification units cannot support validation claims, or that their validation protocol requires evidence verification never generated.
The QMSR does not change that distinction. What it changes is the documentation expectation. Under the legacy regulation some firms treated design transfer as a single signature confirming that drawings had been sent to manufacturing. Under the current framework, transfer is a process with its own verification requirements. The question is no longer "did we send the documents?" but "can we prove the design is manufacturable?"
Can we validate on prototypes instead of production-equivalent units?
No. Validation units must be representative of what will actually be manufactured and sold, and this is the single largest source of professional disagreement, regulatory observations, and program delay.
The difficulty is timing. Production equivalence requires manufacturing decisions on tooling, materials, suppliers, and process parameters before validation begins. For startups and first-time device companies those decisions feel premature. The regulation does not permit the alternative sequence. Validating a design on one process and manufacturing it on another requires demonstrating that the change does not affect validated performance, and demonstrating that equivalence after the fact is usually harder and more expensive than getting it right the first time.
The legacy FDA regulation required design validation on "initial production units, lots, or batches, or their equivalents" 20. ISO 13485 Clause 7.3.7 requires validation on representative product, which the standard notes includes initial production units, batches, or their equivalents 5.
A production-equivalent unit is created from controlled, approved documentation using equivalent materials and manufacturing processes to those intended for final commercial production. Any differences must be explicitly justified and documented 6.
Equivalent does not mean identical. A single-cavity injection mold can produce production-equivalent units if the material, process parameters, and controlled documentation match the intended multi-cavity production tool. What matters is whether the differences could affect the parameters being validated. If they could, the units are not equivalent, however similar they appear.
| Unit type | Acceptable for | Risk level |
|---|---|---|
| Final production units from validated line | Verification and validation | Lowest |
| Pilot production units (final tooling, final materials, controlled docs) | Verification and validation | Low |
| Units from single-cavity mold with production materials | Verification; validation with strong justification | Moderate |
| Hand-assembled units using production materials and controlled docs | Verification with justification | Elevated |
| Lab prototypes with substitute materials | Early feasibility testing only | Highest, not acceptable for formal V&V |
One nuance the professional community is clear about: there is no explicit regulatory requirement for production equivalence during verification, only during validation 7. Verification can sometimes be performed on non-production units, provided the differences are justified and do not affect the specific parameter under test. The further verification units diverge from production, the greater the risk that verified performance will not translate.
The practical test: if your process, materials, or suppliers will change between the units you tested and the units you sell, can you demonstrate with documented engineering justification that those changes do not affect the parameters you verified? If not, your verification data may not survive scrutiny. For validation there is no such flexibility.
The Device Master Record as the readiness test. The QMSR retires the DMR and DHF terms in favor of ISO 13485's medical device file and design and development file; the familiar names are used here because most teams still use them. One of the clearest indicators of production-equivalence readiness is whether a draft DMR exists documenting the revisions of all components, assemblies, and materials used to manufacture the test samples. If the team cannot produce that document, if knowledge of how validation units were built lives in engineers' heads rather than in controlled records, then production equivalence has been assumed rather than established. A successful transfer requires complete, controlled, buildable documentation 4. Otherwise the production floor becomes the place where design gaps are discovered, and by then the cost of discovery has multiplied by an order of magnitude.
Contract manufacturing adds complexity. When design and manufacturing sit in separate organizations, responsibilities during transfer can become unclear. Contract manufacturers may request changes to accommodate their equipment or preferred suppliers while development teams assume the design is final. In the Abbott warning letter, the FDA found that the contract manufacturers responsible for final assembly and release had not been given accuracy performance requirements and were not required to verify finished-device accuracy before release 14.
What must be finished in risk, software, and usability before V&V starts?
Three standards converge at V&V readiness, and their interaction is where programs most often find gaps they did not anticipate.
Risk management (ISO 14971)
ISO 14971 requires two separate verifications for every risk control measure 8. The first confirms that the control has been implemented in the final design, that it physically exists in the configuration being tested. The second confirms that the control actually reduces the risk as intended.
Both stages must be complete before overall residual risk can be declared acceptable. If risk controls are designed but not yet implemented in the configuration being tested, you are not ready for validation. If they are implemented but their effectiveness has not been confirmed, your risk management file is incomplete.
Software (IEC 62304)
For devices with software or firmware, IEC 62304 sets a safety classification (Class A, B, or C) that determines the rigor of lifecycle documentation required 9. A device is not ready for system-level validation if its software is not at a released, tested build state with all known anomalies dispositioned. Unresolved safety-critical software anomalies mean system-level validation cannot begin.
Software was the second-leading cause of medical device recall events in 2024, according to Sedgwick 19. As devices become more software-driven, firmware bugs, algorithm errors, and UI failures are increasingly classified as device failures rather than manufacturing defects. Software readiness is a primary V&V prerequisite.
Human factors (IEC 62366-1)
Summative human factors evaluation, the final validation of usability, must involve intended end users engaging with the final user-interface design under realistic conditions 10. The UI must be locked before summative testing begins. If formative testing revealed critical use errors that have not yet been mitigated through design changes, the device is not ready for summative validation.
The integration requirement: risk management, software lifecycle, and human factors engineering must converge at V&V readiness, not at submission. A design that is mechanically complete but carries unresolved software anomalies, unverified risk controls, or unmitigated use errors is not ready, however polished the hardware looks.
Process validation
Process validation, the IQ/OQ/PQ sequence, is the manufacturing counterpart to design validation. It establishes that a manufacturing process consistently produces product meeting predetermined specifications 2. It is required whenever the results of a process cannot be fully verified by subsequent inspection and test (ISO 13485 Clause 7.5.6), which describes most medical device manufacturing involving bonding, sterilization, sealing, molding, or software loading.
Process validation cannot be completed until the process is defined, equipment is installed and qualified, and operating parameters are established. The strategy must be defined during design development, because it determines what manufacturing evidence will be needed, what equipment must be in place, and what acceptance criteria the process must meet.
Programs that defer process validation planning until after design validation often find that their validated design cannot be consistently manufactured: process windows are tighter than anticipated, equipment variability exceeds design tolerances, or supplier lot-to-lot variation creates failures bench testing never predicted. That is another form of Safety Debt.
The design freeze question
"Design freeze" is not a regulatory term. It appears nowhere in ISO 13485 or FDA regulations 13. It is an internal risk-management milestone, a point where the team decides the design is stable enough to formally test.
The most effective programs use a layered freeze: product-level architecture first, then individual part specifications, then process parameters. This allows verification to begin on stable subsystems while other elements are still being finalized, provided the interactions are understood and the configuration is controlled.
What matters is whether the design is stable enough that formal testing will confirm intent rather than discover instability. If wholesale changes are still likely after V&V begins, the program will experience what one practitioner described as "a world of hurt": repeated testing, invalidated evidence, and schedule collapse 13.
How do we run a readiness review across the whole program?
Nine questions, answered together by engineering, quality, regulatory, manufacturing, and human factors, before formal testing resources are committed. They consolidate regulatory requirements, professional practice, and enforcement evidence into one review.
This is not a sequential checklist. Many of the nine can be answered in parallel. Each needs a yes, backed by evidence, before the program commits to formal V&V and manufacturing transfer. Open each question for what has to be true to answer yes.
What are the signs we are not ready for formal V&V?
The indicators below are drawn from FDA enforcement actions and professional practice, listed roughly in order of consequence. Each reflects a pattern seen in the enforcement actions, practitioner accounts, and program failures cited in this resource.
| # | Red flag | Why it matters |
|---|---|---|
| 1 | Validation planned on lab prototypes | Regulatory requirement violated; data will not support submission |
| 2 | Unresolved critical risks or unimplemented safety controls | ISO 14971 non-compliance; residual risk cannot be declared acceptable |
| 3 | Safety-critical software anomalies unresolved, or the build not under configuration control | System-level validation cannot start on software that is still changing |
| 4 | Intended use or architecture still changing | All downstream testing rests on an unstable foundation |
| 5 | Protocols modified after testing begins | Suggests testing is being used to justify rather than verify |
| 6 | Incomplete traceability matrix | Cannot demonstrate that all requirements have been tested |
| 7 | Assembly relies on undocumented knowledge | Transfer will fail when that knowledge is unavailable |
| 8 | Test methods not validated | Results may not be reproducible or defensible |
| 9 | DHF being assembled retrospectively | Missing information discovered too late to recover |
| 10 | Critical suppliers likely to change after validation | Production units may not match validated units |
| 11 | Critical use errors unmitigated before summative testing | Summative failure is predictable and preventable |
Recent enforcement evidence
Documented regulatory consequences from the past twelve months.
| Organization | What happened | Consequence |
|---|---|---|
| Abbott Diabetes Care (Jan and Feb 2026) | Warning letter: sensor accuracy specifications not translated into manufacturing specifications for the third-party manufacturer; finished devices not accuracy-tested at release 14 | Separate Class I recall of certain FreeStyle Libre 3 sensors: 7 deaths, 860 serious injuries reported as of January 7, 2026 15 |
| Medline Industries (Mar 2026) | Inadequate procedures for verifying device design; complaint trend thresholds exceeded for 3 quarters without escalation | Warning letter; product removal 16 |
| Zoll Medical (Apr 2026) | MRI compatibility of a ventilator evaluated only with a 3T scanner; no documented rationale for omitting 1.5T | Warning letter 17 |
| Happiest Baby (Jun 2026) | Unauthorized modifications to an infant sleeper; design validation on an average-sized model only, despite the intended weight range | Warning letter 18 12 |
None of the stated reasons for these actions was a design flaw. What the FDA cited in each case was translation: the gap between what was designed and what was manufactured, between what was tested and what was sold, between what was intended and what was documented. These are readiness failures, and they are preventable.
In fiscal year 2025, the FDA issued 44 medical device warning letters. CAPA procedures, often triggered by the downstream consequences of premature transfer, were the most-cited requirement at 26. Design controls followed at 25, and process validation appeared in 14 22. The transition from development to production is where programs fail.
What does being ready actually look like?
Readiness allows for uncertainty. Every program has open questions, evolving understanding, and imperfect information. Readiness is the state in which the remaining uncertainties are documented, bounded, and acceptable, where proceeding will confirm what you already know rather than reveal what you have not yet resolved.
Verification and validation are confirmation exercises, not discovery exercises. If your testing is likely to surface fundamental design problems, you are ready for more development rather than for formal testing.
This is a principle we hold at Inertia: V&V should confirm, not discover. When a program enters formal testing and the results expose ambiguity rather than building confidence, the design was not ready. Testing began before intent was fully resolved. The consequence is churn, delay, and evidence that cannot support a submission.
The distinction concerns the type of uncertainty. If testing reveals that a specific material performs differently under worst-case conditions than predicted, that is a legitimate finding. If testing reveals that the team never agreed on acceptance criteria, or that the design changed since the protocol was written, or that test units were built on a process that will not be used in production, those are readiness failures.
The framework exists to surface readiness failures before they become test failures. It is cheaper to find a gap in a readiness review than in a failed verification test, and far cheaper there than in a post-market recall.
What should we do next?
If your program is approaching the transition to formal verification and validation, the framework above can serve as the basis for an internal readiness review. Assemble your cross-functional leads (engineering, quality, regulatory, manufacturing, human factors) and work through each question honestly.
Where the honest answer is no, you have found the work that must happen before testing begins. That is the review doing its job.
If you need an independent perspective on your program's readiness, particularly where manufacturing transfer, production equivalence, or cross-functional integration are creating uncertainty, Inertia can run an independent readiness review against the nine questions before testing commitments are made. Contact Inertia