FDA 510(k) for software as a medical device: the US routes

First question: is your software a device, and in which class?

Before choosing a route, confirm the FDA regulates your software at all. Section 520(o) of the Federal Food, Drug, and Cosmetic Act excludes certain software functions from the definition of a device, including some clinical decision support software that meets the criteria set out in the statute. The FDA's Clinical Decision Support Software guidance and its General Wellness guidance set out how the agency reads those boundaries. Both were reissued in January 2026, so read the current versions rather than relying on an older summary.

If your software is a device, its class drives everything else. The FDA uses three classes, defined at 21 CFR 860.3. Class I devices are subject only to general controls; Class II devices also require special controls; Class III devices require premarket approval. Unlike the EU, you do not classify by applying rules yourself. You find the classification regulation and product code that fits your device's intended use, or you establish that none exists.

Note the terminology, because it signals which route was used: a 510(k) device is cleared, a De Novo request is granted, and a PMA is approved.

Three routes, and how software ends up on each

Which route applies is largely determined by whether a suitable predicate exists and how much risk the device carries.

For AI and other novel software, De Novo is often the realistic route when no predicate fits: it creates a new classification regulation, usually with special controls, and the granted device can then serve as a predicate for later 510(k)s. The De Novo process is codified at 21 CFR Part 860 Subpart D (final rule 86 FR 54826, published 5 October 2021, effective 3 January 2022). Some Class I and Class II devices are exempt from 510(k) altogether, so check the classification regulation before assuming you need a submission.

Fees change every 1 October. The figures in the table apply from 1 October 2026 to 30 September 2027. Separately, every establishment pays an annual registration fee of $13,785 for that year, with no small business reduction.

Predicates and substantial equivalence

Substantial equivalence is defined in the statute (FD&C Act section 513(i)). Your device must have the same intended use as the predicate. It then needs either the same technological characteristics, or different characteristics where the information you submit shows that the device is as safe and effective as a legally marketed device and does not raise different questions of safety and effectiveness. The FDA sets out how it applies this test in its guidance “The 510(k) Program: Evaluating Substantial Equivalence in Premarket Notifications” (July 2014).

For software, the predicate choice is the whole argument, and most problems are visible at this stage.

• Intended use comes first. If your indications for use go beyond the predicate's, for example a new patient population, a new clinical decision or a move from triage support to diagnosis, you may not have a predicate at all.
• Technological differences are expected, not fatal. A new algorithm doing the same job can be substantially equivalent, but the difference must not raise a different type of safety or effectiveness question. Moving from rule-based logic to a machine learning model often does raise new questions, about training data, generalisation and performance drift, and those must be answered with evidence.
• Performance testing carries the weight. Your comparison is usually made with bench and analytical performance data against the predicate's claims. EU clinical evaluation reports do not map across directly; the evidence may be reusable, but the argument has to be rebuilt around the predicate.
• Use the Q-Submission programme. If predicate choice or the testing plan is uncertain, a Pre-Submission lets you get FDA feedback before you file.

What a software 510(k) has to contain

The submission format is fixed. Since 1 October 2023, 510(k)s must be submitted electronically using eSTAR unless exempted. Inside it, software content follows the FDA's “Content of Premarket Submissions for Device Software Functions” guidance (June 2023), which replaced the 2005 software guidance.

• Documentation level: that guidance sets two levels. Enhanced Documentation applies where a failure or flaw of the software could present a hazardous situation with a probable risk of death or serious injury, assessed before risk controls. Basic Documentation applies otherwise.
• Cybersecurity: a device that includes software, can connect to the internet, and has characteristics that could be vulnerable to cybersecurity threats is a “cyber device” under FD&C Act section 524B, with specific premarket submission obligations. The FDA's cybersecurity guidance was revised in February 2026.
• Recognised standards: the FDA recognises IEC 62304 (software life cycle), ISO 14971:2019 (risk management) and IEC 62366-1 (usability engineering) as consensus standards, and you can declare conformity to them in a submission. If your EU file is built on these standards, a large share of the underlying work transfers; the presentation does not.
• Review time: the FDA states that a substantial equivalence determination is usually made within 90 days. Plan on a longer calendar period, because the time you spend answering FDA requests for additional information comes on top.

Predetermined Change Control Plans for software that changes

Software changes constantly, and under a 510(k) a significant change can require a new submission. The FDA's “Deciding When to Submit a 510(k) for a Software Change to an Existing Device” guidance (October 2017) is the test for changes you have not planned for.

A Predetermined Change Control Plan lets you get planned changes authorised up front. The statutory basis is FD&C Act section 515C, added in December 2022: a change consistent with an authorised plan does not need a new PMA supplement, or, for a 510(k) cleared device, a new 510(k). The FDA's final guidance on PCCPs for AI-enabled device software functions was issued on 3 December 2024 and revised in August 2025, and it applies across 510(k), De Novo and PMA submissions.

A PCCP is not a licence to change anything. It describes specific modifications, the methods for developing, validating and implementing them, and an assessment of their impact. Changes outside the plan still go through the normal change assessment.

• The FDA, Health Canada and the MHRA jointly published guiding principles for PCCPs for machine learning-enabled devices on 24 October 2023, which is useful if you want one change control approach across the US and Great Britain.
• A broader PCCP guidance covering all devices was issued in draft in August 2024 and, as of 29 September 2026, remains draft.
• The FDA's draft guidance on AI-enabled device software functions lifecycle management (January 2025) also remains draft. Draft guidance is not binding and can change.

What your ISO 13485 system does and does not give you

This is where the US route has become far more compatible with the EU. Since 2 February 2026, 21 CFR Part 820 is the Quality Management System Regulation, which incorporates ISO 13485:2016 by reference (final rule 89 FR 7496, 2 February 2024; technical amendments 90 FR 55978, 4 December 2025). A quality system built properly to ISO 13485 is now the foundation of US compliance, which you extend for the US rather than duplicate.

But three things do not carry across. First, the FDA does not require or issue ISO 13485 certificates, and a certificate does not exempt you from FDA inspection; the FDA inspects under Compliance Program 7382.850. Second, Part 820 adds requirements beyond ISO 13485. Third, the US has its own obligations outside Part 820 altogether.

So the honest version is narrower than the usual pitch: one quality system can serve both markets, provided you extend it deliberately with US procedures, records and reporting, and prepare for an FDA inspector who assesses it on its own terms. The split looks like this.