V5 Ultimate
Compliance · The complete guide

FDA Pre-Cert (Software Precertification)

TL;DR

FDA’s Software Precertification Pilot (2017–2022) tested organization‑level oversight for SaMD, then ended when the agency concluded new legislation would be required. Its lessons now inform PCCPs, QMSR alignment, evidence planning, and postmarket monitoring under existing device pathways.

Reviewed · By V5 Ultimate compliance team· 1,859 words · ~9 min read
AI · Explain it for MY operation

How does FDA Pre-Cert (Software Precertification) apply to your shop floor?

Pick your industry and scale — Ask V5 rewrites the definition in your context, gives a worked example, and shows what V5 does on day one.

Your scale

01What FDA Software Pre‑Cert Was and Why It Matters

From 2017 to 2022, FDA’s Software Precertification (Pre‑Cert) Pilot assessed whether an organization’s culture of quality and performance could be appraised up front and then used to streamline review of Software as a Medical Device. The hypothesis was that mature software teams, operating with transparent metrics and disciplined postmarket learning, could release updates faster without compromising safety or effectiveness.

The pilot generated playbooks for organizational excellence, approaches to real‑world performance monitoring, and experiments with streamlined submissions. It also revealed hard statutory limits: the FD&C Act is product‑centric, and FDA determined it lacked sufficient legislative authority to turn entity‑level certification into an alternative to device‑specific findings.

Although the pilot closed in September 2022, its ideas persist. They now appear in risk‑appropriate evidence planning, structured change protocols for learning systems, and a stronger expectation that sponsors define crisp intended uses and monitor fielded software in a way that is actionable. For SaMD teams, the Pre‑Cert story remains a practical guidepost for building submissions that are lean, auditable, and resilient to iteration.

If you develop stand‑alone medical software, review foundational concepts such as samd, medical device classification, and approaches to real‑world evidence. These elements—rather than any notion of entity certification—determine the U.S. pathway and the scope of evidence you need.

02Statutory Foundations and Why the Pilot Ended

U.S. device law is anchored in the Federal Food, Drug, and Cosmetic Act, which requires FDA to make product‑specific findings. Section 510(k) (21 U.S.C. 360(k)) governs substantial equivalence determinations, Section 515 (21 U.S.C. 360e) establishes the premarket approval standard for Class III devices, and De Novo (21 U.S.C. 360c(f)(2)) enables risk‑based classification for novel, low‑to‑moderate risk technologies.

During the pilot, FDA explored whether an organization’s excellence could lawfully substitute for some evidence otherwise tied to a specific device. The agency concluded it could not. Without new statutory authority, entity‑level precertification cannot replace the FD&C Act’s requirement that each device demonstrate safety and effectiveness for its intended use.

The 21st Century Cures Act encouraged digital health innovation and clarified exclusions for certain wellness functions, but it did not authorize acceptance of an organization certification in lieu of device‑level findings. Accordingly, FDA closed the pilot and redirected its insights into mechanisms compatible with current law, such as enhanced pre‑submission engagement, risk‑based review practices, and structured change protocols evaluated within individual submissions.

For sponsors, the implication is clear: organizational maturity may speed interactions and improve dossier quality, yet it cannot stand in for the statutory determinations FDA must make. Teams should align their quality management to FDA’s Quality Management System Regulation and ISO 13485 principles while planning device‑specific clinical, analytical, cybersecurity, and usability evidence.

03Scope: SaMD, Risk, and Intended Use

Pre‑Cert focused on Software as a Medical Device, meaning stand‑alone software that performs a medical function without being part of hardware. Examples include software that detects, diagnoses, or predicts conditions, or that recommends or optimizes treatments. By contrast, general wellness or administrative features without medical purpose fall outside device scope.

Risk classification spans Class I through Class III, driven by intended use, user type, clinical context, and the severity of potential harm if the software errs. A diagnostic or treatment recommendation tool typically presents higher risk than an informational aid, which raises the evidentiary bar for performance claims, human factors, and cybersecurity.

Clarity of intended use remains the fulcrum. It anchors labeling, verification and validation depth, and change management boundaries. It also shapes whether a predicate device exists for 510(k), whether De Novo is appropriate, or whether PMA is required. Early articulation of intended use and context of use reduces rework and accelerates regulatory convergence across markets.

Teams new to SaMD should ground their plans in device classification heuristics and risk practices, then confirm alignment through early interaction with FDA. See software as a medical device readiness, ISO 14971 risk management readiness, and our primer on risk matrix construction for scoping evidence and test depth.

04How the Pre‑Cert Pilot Operated in Practice

Operationally, the pilot attempted to appraise a developer’s culture of quality and organizational performance, then use that appraisal to streamline product reviews. FDA and participants iterated on assessment methods, metrics, and documentation templates intended to predict consistent, safe execution across releases.

The program also tested real‑world performance constructs to verify that fielded software met expectations and that monitoring could rapidly detect drifts, degradations, or cybersecurity signals. These constructs foreshadowed the modern emphasis on continuous learning cycles, data governance, and pre‑specified update plans for learning components.

Finally, the pilot ran submission experiments to explore how much documentation could be streamlined when an organization demonstrated maturity. While promising in concept, these experiments could not supplant statutory evidence obligations tied to each device’s intended use and risk profile.

  • Organizational excellence appraisals focused on leadership, design controls, verification and validation, and postmarket vigilance.
  • Defined metrics for quality and performance intended to predict consistent outcomes across releases.
  • Experiments with streamlined content for lower‑risk changes, bounded by intended use and risk controls.
  • Real‑world performance monitoring frameworks to detect model drift, safety signals, and usability issues.
  • Feedback loops to translate monitoring signals into corrective and preventive actions and labeling updates.

05What Endured: QMSR Alignment, Monitoring, and Structured Change Protocols

With the pilot closed, FDA emphasized tools that fit fully within existing law. Chief among them are the Quality Management System Regulation (21 CFR Part 820, as amended), which aligns with ISO 13485:2016 principles, and a stronger expectation that sponsors maintain design control rigor, postmarket surveillance discipline, and transparent corrective and preventive actions.

For adaptive algorithms, FDA has prioritized the Predetermined Change Control Plan (PCCP) model, in which sponsors define, validate, and seek premarket review of permissible changes, data update procedures, and verification safeguards. PCCPs enable iterative improvement while preserving the statutory requirement that changes be bounded, validated, and reviewable.

Early dialogue remains essential. The FDA Q‑Submission Program is the venue to test intended use, classification, and PCCP scope before committing to pivotal evidence. Cybersecurity expectations have also matured, as reflected in agency communications summarized in FDA Cybersecurity (Premarket, 2023), reinforcing secure update mechanisms, SBOM discipline, and threat‑informed testing.

Sponsors should compare frameworks using QMSR vs. ISO 13485 to harmonize procedures globally while meeting U.S. expectations. Aligning to fda qmsr and iso 13485 reduces friction when translating organizational excellence into auditable, device‑level evidence and change control.

06The Pathways in Force and Where Pre‑Cert Lessons Fit

In the United States, software devices proceed through 510(k), De Novo, or PMA depending on risk, novelty, and the availability of a suitable predicate. Pre‑Cert does not exist as a filing route. However, several of its concepts—organizational discipline, risk‑appropriate evidence, and continuous monitoring—strengthen submissions within these pathways.

For AI/ML‑enabled devices, a Predetermined Change Control Plan may be proposed within the submission to pre‑specify data and model update boundaries, verification procedures, and safeguards. The plan does not waive statutory findings; instead, it creates a structured framework for future changes that FDA can evaluate up front.

Use early pre‑submission interactions to confirm pathway, intended use language, and evidentiary scope, especially when classification and benefit‑risk arguments are finely balanced. These steps reduce surprises and help reviewers see how your quality system underpins device‑level claims.

PathwayStatutory basisTypical risk classReview focusWhere Pre‑Cert ideas fit
510(k) Substantial Equivalence21 U.S.C. 360(k)Primarily Class II; some IEquivalence to a predicate in intended use and technological characteristics, with performance testing as neededLean, well‑scoped dossiers; disciplined [requirements traceability](/glossary/requirements-traceability); cybersecurity and postmarket monitoring plans
De Novo Classification21 U.S.C. 360c(f)(2)Novel Class I/IIRisk‑based classification with special controls; benefit‑risk rationale and clinical/analytical evidenceEarly Q‑Subs; PCCP proposals for bounded algorithm/data updates; robust real‑world performance plans
Premarket Approval (PMA)21 U.S.C. 360eClass IIIReasonable assurance of safety and effectiveness, often with clinical studies and post‑approval conditionsEnhanced design controls, cybersecurity hardening, real‑world surveillance, and change protocols tied to labeled claims
Predetermined Change Control Plan (PCCP)Within existing authorities; reviewed within 510(k), De Novo, or PMAApplies where appropriatePre‑specified change categories, data management, verification/validation guardrailsOperationalizes disciplined iteration without bypassing device‑level findings

07Practice Guidance and Common Pitfalls

In practice, success starts with scoping discipline. Write intended uses that are specific enough to bound validation, claims, and foreseeable misuse. Partition non‑device wellness or administrative functions so they do not blur labeling or introduce unmitigated hazards. Map hazards to controls using risk management consistent with ISO 13485‑aligned procedures.

Ensure evidence is commensurate with risk. Diagnostic claims demand robust analytical validity and, where appropriate, clinical performance data. Treatment recommendation tools often need human factors validation in the target clinical context and threat‑informed cybersecurity testing. Document these linkages with end‑to‑end requirements traceability and plan your change control so iterative releases remain within approved claims.

Engage FDA early to de‑risk classification, intended use wording, and PCCP scope. When a suitable predicate device is uncertain, a pre‑submission can surface comparators, test strategies, and special controls that shape your path to market. Treat monitoring plans as first‑class artifacts; define triggers that convert real‑world signals into CAPA and, when needed, labeling updates.

  • Do not cite “Pre‑Cert” as a basis for clearance, classification, or approval.
  • Avoid vague intended uses that obscure risk, claims, or performance endpoints.
  • Do not let non‑device features contaminate device labeling or user workflows.
  • Do not assume organizational maturity can replace device‑specific validation and cybersecurity evidence.
  • Avoid brittle update processes; design PCCPs and regression testing that scale with data and model changes.
  • Do not neglect postmarket metrics; define leading indicators and clear CAPA triggers.
  • Avoid gaps in documentation; maintain auditable, end‑to‑end traceability from hazards to verification and validation.

08Neighboring Frameworks and Global Alignment

While Pre‑Cert was U.S.‑specific, its themes resonate globally. Many regulators expect ISO 13485‑aligned quality systems, risk management per ISO 14971 principles, and postmarket vigilance proportional to risk. The European Union’s regulatory model remains device‑centric as well, with classification, conformity assessment, and postmarket surveillance defining evidence obligations for software.

Global planning benefits from early convergence on intended use, risk controls, and evidence packages that translate into U.S., EU, and other markets. Harmonizing your QMS to FDA’s Quality Management System Regulation and ISO 13485 reduces duplication in technical documentation and eases audits. Where AI governance frameworks apply, ensure they complement—not replace—medical device obligations.

Use regional engagement tools to clarify expectations country by country. In the U.S., leverage pre‑submissions; in the EU, align with notified body expectations; in Canada and Japan, coordinate early on software lifecycle controls and cybersecurity. Across all markets, bind real‑world monitoring to corrective actions and update management that reflect device risk and user context.

For a deeper orientation, see our cross‑market guides on USA medical device regulatory readiness and global medical device regulatory readiness, and context on AI oversight in EU AI Act (medical device). Maintain U.S. submissions anchored to FDA’s definitions and logic while planning for international alignment.

09Evidence Planning, Cybersecurity, and Monitoring

Evidence plans should be traceable to the intended use and driven by harm severity. Analytical validation demonstrates that inputs, preprocessing, and algorithms produce accurate, reliable outputs; clinical validation establishes clinical performance where claims demand it. Usability studies verify that target users, in real contexts, can safely and effectively rely on outputs.

Cybersecurity is now integral to safety and effectiveness. Premarket submissions should define secure development practices, threat modeling, SBOM discipline, vulnerability management, and update channels. Postmarket plans need monitoring thresholds, incident response, coordinated disclosure, and patch validation. See FDA Cybersecurity (Premarket, 2023) for expectations and align your controls to your device class and claim scope.

Real‑world performance monitoring closes the loop. Define metrics, data quality checks, and governance that detect drifts or degradations. Link those signals to CAPA and, if using a PCCP, to pre‑authorized change categories and regression testing. Transparent monitoring supports adaptive learning while preserving the statutory requirement for bounded, validated changes.

When designing studies, borrow methods from real‑world evidence while respecting device‑specific endpoints and bias controls. Use early Q‑Subs to align on clinically meaningful endpoints and analysis plans so your dossier remains defensible and efficient.

10How V5 Ultimate Supports Your Post‑Pre‑Cert Strategy

V5 Ultimate operationalizes the Pre‑Cert lessons that survived—without relying on the pilot as a pathway. Our platform anchors device development in traceable intended use, hazards, controls, verification and validation, and change protocols that scale with iterative releases. It helps teams show disciplined execution to FDA while keeping submissions lean and auditable.

Use V5 to model PCCPs, enforce regression testing gates, and connect postmarket signals to CAPA and labeling updates. Built‑in cybersecurity records, SBOM management, and event workflows make it easier to align with modern expectations for secure development and maintenance. Evidence libraries and submission views help assemble 510(k), De Novo, and PMA packages efficiently.

Core capabilities—qms, document control, traceability, ebmr/edhr, and analytics—map to FDA’s QMSR expectations and ISO 13485 principles. Templates for requirements traceability, change control, and pre‑submission briefing decks align teams for predictable reviewer interactions.

Frequently asked questions

Q.Is FDA’s Software Pre‑Cert a valid route to market?+

No. The pilot closed in 2022 and is not a marketing pathway. Sponsors must use 510(k), De Novo, or PMA, with device‑specific evidence calibrated to intended use and risk.

Q.What parts of Pre‑Cert still matter for SaMD teams?+

The enduring pieces are quality system rigor, real‑world performance monitoring, and structured change protocols such as PCCPs. These improve dossier quality and support iterative releases within existing law.

Q.Can organizational maturity replace clinical or performance evidence?+

No. The FD&C Act requires product‑specific findings. Organizational maturity can speed preparation and review, but it cannot substitute for device‑level validation or safety and effectiveness demonstrations.

Q.When should I propose a Predetermined Change Control Plan?+

When your software will update models or data regularly and you can clearly pre‑specify change categories, guardrails, and verification methods. Discuss scope and test plans in a pre‑submission meeting.

Q.How does QMSR affect my SaMD development process?+

QMSR aligns U.S. expectations with ISO 13485 principles. It reinforces design controls, supplier oversight, and postmarket vigilance. Harmonizing your QMS to QMSR streamlines audits and evidence assembly.

Q.What are common mistakes in SaMD submissions after Pre‑Cert?+

Vague intended uses, blurred device versus non‑device functions, thin cybersecurity evidence, and weak monitoring plans are frequent issues. Each undermines classification, benefit‑risk arguments, and change control.

Q.How should I scope international launches while meeting U.S. requirements?+

Anchor U.S. dossiers to FDA’s definitions and risk logic, then harmonize procedures to ISO 13485 for reuse. Align early with notified bodies and other regulators to avoid duplicative testing or conflicting claims.

Primary sources

Further reading

See FDA Pre-Cert (Software Precertification) working on a real shop floor

V5 Ultimate ships with the FDA Pre-Cert (Software Precertification) controls already wired in — audit trail, e-signatures, validation evidence. Free trial, no credit card, onboard in days, not months.