SaMD Certification and FDA Approval: A Step-by-Step Regulatory Guide

Most founders hit FDA software rules the hard way, in a meeting where someone explains that the app they’ve been building was a medical device all along. At that point the fix costs months of documentation, testing, and a submission the FDA will actually read.

This guide walks the SaMD certification process the way it runs in practice: which pathway fits your software, what the FDA asks for, what the fees cost, and how long review takes. We build these submissions for clients, and we’ve sat through the Pre-Sub meetings where the plan changes. Software as a medical device is a regulatory category, and the SaMD regulatory approval process follows from that first call.

How do you get SaMD approved by the FDA?

Classify the software as a medical device first, pick a pathway, and submit through eSTAR. Most software functions take the 510(k) or De Novo route; FDA review goals run 90 days for a 510(k), 150 for a De Novo, and 180 for a PMA, excluding holds. FY2026 user fees run from $26,067 for a 510(k) to $579,272 for a PMA.

Top Takeaways:

• Pathway: 510(k) when a predicate device exists, De Novo when your software is novel at moderate risk, PMA when it’s Class III.
• SaMD FDA approval time: FDA review goals are 90 days (510(k)), 150 (De Novo), and 180 (PMA), excluding holds.
• Money: FY2026 fees: $26,067 for a 510(k), up to $579,272 for a PMA. Small business rates are a quarter of that.
• Rules: QMSR (ISO 13485:2016) took effect February 2, 2026, and Section 524B cybersecurity applies to cyber devices. Every SaMD regulatory approval process starts with classification.

Table of Contents:

1. What counts as software as a medical device
2. How the FDA classifies SaMD
3. Choosing your FDA regulatory pathway
4. The SaMD regulatory approval process, step by step
   • Step 1: laying the regulatory groundwork before development
   • Step 2: Define intended use and indications for use
   • Step 3: Developing a regulatory strategy
   • Step 4: Testing and validation: ensuring safety, effectiveness, and usability
   • Step 5: Build the submission documentation (basic vs. enhanced level)
   • Step 6: Meet FDA cybersecurity requirements (Section 524B)
   • Step 7: Submit through eSTAR and respond to FDA questions
   • Step 8: Post-market surveillance and managing software changes
5. SaMD approval timeline and cost
6. Selling SaMD outside the U.S.: EU MDR and CE marking
7. Challenges in SaMD certification: common roadblocks and how to overcome them
8. SaMD case study: what a real submission looked like
9. AI-enabled SaMD: what the FDA expects in 2026

What counts as software as a medical device

What is SaMD? Software intended for a medical purpose that doesn’t live inside a hardware medical device. The FDA defines it as software used for one or more medical purposes without being part of a hardware device, covering:

• prevention
• diagnosis
• cure and mitigation
• treatment of a disease

Get this call wrong and you redo the whole submission file.

The definition makes software as a medical device a regulatory category of its own. One clause trips people up. SaMD doesn’t have to run alone. It can work with medical hardware or other software, as long as it doesn’t drive the device’s medical function. If the device does its clinical job without your app, you’re looking at SaMD. If the device goes dead without the software, that’s firmware, also called SiMD.

The FDA clears or approves software. Certification is the EU’s word: notified bodies issue CE certificates there. The closest thing to SaMD certification in this market is CE marking under EU MDR, issued by a notified body. Both routes are covered below.

Read more on medical device integration

Does my health app qualify as SaMD?

Ask whether the software does a medical job on its own. If you’re building software as a medical device, this is the first fork. That starts with intended use and indications for use.

Intended use is the purpose you claim: what the product is for. Indications for use are the conditions, populations, and situations it addresses. Write both down early. They decide the device class and the pathway, and FDA reviewers read them first.

A quick yes/no pass:

• Does the software diagnose, treat, prevent, mitigate, or monitor a disease? If yes, it’s likely a device.
• Does it run on general-purpose platforms, outside the hardware? If yes, it’s SaMD. If it lives in the device, it’s SiMD.
• Is its only claim general wellness, like tracking steps or encouraging healthy habits? If yes, it’s probably not a device at all.

Work through these before you write a line of code; each answer changes which file the FDA reads.

The answer to “is my app a medical device?” comes down to that first question. Answer it honestly: it sets the class, the pathway, and the budget. The SaMD regulatory approval process starts with that answer.

SaMD vs. SiMD vs. non-device software

SiMD, software in a medical device, is embedded. It runs the hardware. Take a skin lesion scanner whose AI runs on-device: remove the software and the scanner is a paperweight. That’s SiMD, and it rides inside the device’s regulatory path, without a separate software review.

Nail the SaMD vs SiMD distinction early; it decides which regulatory file your software belongs in. The line between software as a medical device and non-device software is set by FDA policy. Non-device software is everything else: EHRs used for administration, practice management tools, and apps with no medical claims. The FDA’s general wellness and clinical decision support policies draw that line, and they moved in 2026.

SiMD still faces software requirements; it just rides inside the device’s submission.

SaMD examples: what FDA regulates and what it doesn’t

Examples of software as a medical device the FDA regulates:

• a digital therapeutics app that coaches patients through exercise plans
• a light-therapy app that works with red and infrared LEDs
• software that analyzes a scan and suggests a diagnosis

Software the FDA leaves alone includes products that look like software as a medical device but claim nothing medical:

• a step tracker with no medical claims
• a meditation or sleep-hygiene app
• an app that stores and displays lab results without interpreting them

Some of the regulated examples are companion apps, paired with hardware but reviewed as their own device. Whether a medical device companion app counts as an accessory or as standalone SaMD is a classification call to settle before you build.

Also Read: A Complete Guide to EHR Integration

When software is not a device: general wellness and CDS exemptions after the 2026 guidances

Two FDA policies keep software out of device territory. The general wellness policy covers products with low risk to safety: fitness, sleep, weight management, and similar claims, as long as they don’t treat or diagnose a specific disease. FDA refreshed that guidance on February 11, 2026.

The clinical decision support policy covers software that helps clinicians while leaving the decision to them. The final CDS guidance, issued March 11, 2026, sets four criteria a software function must meet to stay a non-device. Two matter most in practice: the software can’t analyze medical images or signals, and the clinician has to be able to check the reasoning behind any recommendation.

If your app falls under either policy, you may not need FDA clearance at all, and the SaMD certification question answers itself. Get that question answered before you build, because reworking an app around a device determination is the expensive order of operations.

How the FDA classifies SaMD

The U.S. Food and Drug Administration (FDA) regulates the development and marketing of SaMD products, and software can be a medical device: the question is where yours falls. Bookmark the FDA’s Software as a Medical Device (SaMD) hub page; it’s the source for the guidance documents named throughout this post.

FDA SaMD guidance is the roadmap for different types of software as a medical device. How the FDA classifies software as a medical device decides which guidance applies to you, and these documents tell you what evidence your app needs, and the FDA coordinates them with international bodies like the International Medical Device Regulators Forum (IMDRF) to keep rules consistent worldwide.

Related: FDA has issued no binding rules specific to generative models. See the compliance section in generative AI in healthcare.

FDA device classes I, II, and III (with correct examples)

SaMD classification follows risk. Class I is lowest risk, Class III highest, and the class decides how much evidence your submission needs.

• Class I: low risk, general controls, and most Class I software is exempt from premarket review. Real examples: software that archives medical images without analysis, or a device data system that only moves data around.
• Class II: moderate risk, general plus special controls, usually a 510(k). Examples: a glucose monitoring app paired with a Class II sensor, or software that calculates an insulin dose.
• Class III: high risk, supports or sustains life, PMA required. Example: software that controls delivery of a life-sustaining therapy, like a closed-loop insulin dosing algorithm.

Pick the class from intended use and risk, then let it drive your testing plan.

Note what’s missing from that list: fitness trackers and wellness apps. They generally sit outside device regulation entirely, in FDA’s enforcement-discretion bucket for general wellness products, and that’s a different thing from a class. Each class carries different regulatory controls and premarket review pathways, so correct SaMD classification decides the requirements you’ll meet. For software as a medical device, the class picks the controls.

IMDRF SaMD risk categories

The FDA coordinates with the International Medical Device Regulators Forum (IMDRF), which categorizes software as a medical device by two questions: how serious the healthcare situation is, and how much the software’s output drives the decision.

• Category IV: information to treat or diagnose in critical situations, like a stroke detection alert
• Category III: information to treat or diagnose in serious situations, or to drive clinical management in critical ones
• Category II: information to drive clinical management in serious situations, or to treat or diagnose in non-serious ones
• Category I: information to inform clinical management in serious situations, or to drive or inform it in non-serious ones

Check the categories against local rules, especially EU MDR, when you plan a multi-market rollout. The IMDRF map is the common language regulators use when they talk to each other. Use it early in your SaMD certification planning.

Choosing your FDA regulatory pathway

FDA software as a medical device submissions fall into three routes: 510(k), De Novo, or PMA. Your SaMD regulatory pathway depends on two things: whether a predicate device exists, and how risky your software is.

510(k) premarket notification

A 510(k) shows your software is substantially equivalent to a predicate device already on the market. No new safety questions, no new intended use. Most SaMD goes this way, because most software improves on software that exists. Most SaMD certification files are 510(k)s.

A software as a medical device 510(k) compares your device against the predicate: intended use, technological characteristics, and performance data. FDA’s review goal is 90 days, though holds for additional information push real timelines past that.

De Novo classification request

No predicate? The De Novo classification request is the route for novel software as a medical device at low to moderate risk. FDA grants it when general controls, or general and special controls, assure safety without the clinical weight of a PMA.

Two ways in: submit a 510(k) and get a not substantially equivalent (NSE) finding, or go straight to De Novo when you know no predicate exists. A granted De Novo classifies your device as Class I or II, and your device becomes the predicate future products compare against. FDA’s review goal is 150 days. The FY2026 fee is $173,782, or $43,446 for small businesses.

Premarket approval (PMA)

PMA is for Class III software as a medical device that supports or sustains life, or poses unreasonable risk. It demands clinical data showing safety and effectiveness, the heaviest evidence bar in device regulation. Review goals run 180 days and the FY2026 fee is $579,272, or $144,818 for small businesses.

PMA is the route when your software makes the call in a critical situation. If that describes your product, the clinical program belongs in the plan from day one.

Pre-submission (Q-Sub) meetings

Before you commit to a pathway, ask. The Q-Submission (Pre-Sub) program is a free meeting with FDA reviewers where you lay out your software as a medical device, your proposed pathway, and the questions you need answered.

Pre-Sub feedback is the cheapest step in the SaMD certification process and the cheapest regulatory insurance available. FDA writes back with its read on your classification, your predicate, and your test plan. Founders who skip it usually pay for the skip later in a surprise hold.

Pathway comparison: evidence, review time, and FY2026 user fees

Review goals exclude time on hold answering FDA questions. Real calendars run longer, and we budget for that in the timeline section below.

The SaMD regulatory approval process, step by step

The SaMD regulatory approval process has eight steps. Here’s how a software as a medical device FDA submission comes together, from the first regulatory question of the SaMD certification process to the file the FDA reviews.

Step 1: laying the regulatory groundwork before development

The software as a medical device approval process starts before development does. Building software as a medical device means designing for review. Design for the submission from the first sprint. Retrofitting a built app into compliance is the most expensive order of operations in SaMD, because design controls have to exist for the whole build history. Learn more about healthcare app development cost before you commit.

Start with the FDA SaMD guidance for your software type, figure out the class and pathway, and stand up the quality system early. Since February 2, 2026, that means QMSR, the FDA quality rule built on ISO 13485:2016. Pick your provider of healthcare app development services with the submission in mind.

Step 2: Define intended use and indications for use

Before classification, write the intended use statement. It names the purpose: what the software does, for whom, and in what setting. Indications for use add the clinical scope: which conditions, which populations, and which decisions the software supports.

This pair does more regulatory work than any other two sentences you’ll write. FDA reviewers read intended use first, and it fixes your class, your pathway, and your evidence requirements. If you’re unsure how to classify the product, run the statement past a regulatory expert or FDA’s Pre-Sub program before building, because the software as a medical device approval path bends around these sentences. The SaMD regulatory approval process starts with that statement, so get it right before the build.

Step 3: Developing a regulatory strategy

With the class and pathway set, the strategy picks the standards and the evidence plan. The standards for software as a medical device overlap, and you pick the subset your class demands. For SaMD that usually means:

• QMSR and ISO 13485: the quality system rule, effective February 2, 2026
• IEC 62304: software lifecycle processes, from requirements to maintenance
• ISO 14971: risk management for medical devices
• IEC 62366-1: usability engineering
• ISO 27001: information security management for products handling health data

IMDRF publishes a quality management system guide for SaMD worth reading alongside these. You won’t need all of them at once, and each one adds documentation work to the software as a medical device approval process. Build your strategy on the standards your class actually demands, and record the mapping; auditors love a traceable standards list. The SaMD regulatory approval process is a documentation marathon, and this mapping is the training plan.

Step 4: Testing and validation: ensuring safety, effectiveness, and usability

For software as a medical device, testing proves the product does what the intended use claims, safely. Plan for:

• Usability testing: how users interact with the software, per IEC 62366-1, catching interface risks before they become adverse events
• Performance testing: speed, accuracy, and stability against the claims
• Validation testing: functional and non-functional requirements, including the documentation that ships with the product

Then the clinical piece. FDA’s clinical evaluation of SaMD guidance walks through assembling the clinical data behind the claims. Some products validate on bench data and published literature; higher-risk software needs a real clinical study. That’s the line between a lean 510(k) and a PMA program. The software as a medical device approval process depends on that evidence file.

Also Read: Mobile App User Testing: Tools and Best Practices

Step 5: Build the submission documentation (basic vs. enhanced level)

FDA’s June 2023 guidance, Content of Premarket Submissions for Device Software Functions, sorts software as a medical device into two documentation levels. Basic level fits software whose failure can’t cause serious harm; Enhanced level fits everything above it.

• Basic: device description, risk-based documentation, and testing that supports the level
• Enhanced: the full lifecycle file: software requirements, architecture, design, verification, unresolved anomalies, traceability, and change history, with the IEC 62304 lifecycle artifacts front and center

Expect 10 to 20 documents across the whole submission, depending on class. The software as a medical device approval file has no single template; the level sets its shape. Records of every design change, test result, and risk decision are what the FDA reviews, and what your SaMD clinical evaluation draws on. Those records feed post-market surveillance later.

Step 6: Meet FDA cybersecurity requirements (Section 524B)

Since March 2023, Section 524B of the FD&C Act requires cybersecurity information in premarket submissions for cyber devices, and that covers most software as a medical device: anything that connects to a network, runs software updates, or otherwise opens a digital attack surface.

Section 524B cybersecurity submissions need a security plan, a software bill of materials (SBOM), and testing that shows the controls work. FDA’s September 2023 final guidance, Cybersecurity in Medical Devices, spells out what reviewers check. Build security into design controls early; retrofitting it reads badly in review and costs more. Cybersecurity is part of the SaMD regulatory approval process from the first file, and the software as a medical device approval package includes all three.

Step 7: Submit through eSTAR and respond to FDA questions

A quick word on terminology. Establishment registration and device listing are annual obligations once you market a device, separate from the premarket submission. The software as a medical device approval process ends at eSTAR: the submission itself is the 510(k), De Novo, or PMA.

The eSTAR program makes premarket submissions electronic and checks the form’s completeness before FDA starts review. After submission, expect questions: FDA issues requests for additional information, the clock stops, and your answers restart it. Budget review time as goal plus one to two hold cycles.

Step 8: Post-market surveillance and managing software changes

Approval opens the post-market phase. Post-market surveillance runs as long as the product does: monitoring feedback, complaint handling, and real-world performance.

For software as a medical device, updates are regulatory events. Software changes reopen the question. FDA’s guidance, Deciding When to Submit a 510(k) for a Change to an Existing Device, draws the line between changes you document internally and changes that need a new submission. A modification that affects safety, effectiveness, or intended use lands on the submission side. A predetermined change control plan, covered below, can settle planned updates at review time, before they become a surprise. Software as a medical device approval is a status you maintain, not a certificate you frame.

SaMD approval timeline and cost

Typical timelines by pathway

FDA goals set the floor. Real calendars:

• 510(k): 90-day goal; with preparation and one hold cycle, plan 4 to 6 months
• De Novo: 150-day goal; real files land in 6 to 12 months
• PMA: 180-day goal, and the clinical program ahead of filing is usually the long pole

Budget the preparation months first; the review clock is the shorter half of the story.

The software as a medical device approval timeline includes the preparation most teams forget: 3 to 6 months of documentation for a 510(k), and a year or more before a PMA is ready to file.

What drives the budget

FDA SaMD clearance costs fall into two buckets: the user fee and the work. Fees are the visible slice: $26,067 to $579,272 in FY2026, a quarter of that for small businesses with an FDA Small Business Determination. Documentation, testing, and clinical work cost several times the fee. A summative usability study alone runs $100,000 to $300,000+, and that’s before software testing and regulatory support.

The full breakdown lives in our medical device development costs article. Plan post-market surveillance into the same SaMD certification budget, then commit the regulatory spend.

Selling SaMD outside the U.S.: EU MDR and CE marking

In the EU, software as a medical device goes through the Medical Device Regulation (MDR 2017/745), and the result is a CE mark from a notified body. That’s the SaMD certification in this page’s title: the EU process issues a certificate, while the FDA process clears or approves. CE marking is the EU equivalent of the software as a medical device approval process.

Build the evidence once against both sets of standards; only the packaging differs.

Rule 11 classification for software

EU MDR Rule 11 classifies software by what the output does:

• software that drives diagnosis or therapy decisions: Class IIa or higher, climbing with risk
• software that monitors physiological processes: Class IIa or higher
• everything else: Class I

Most clinical SaMD lands at Class IIa or above under Rule 11, which means a notified body reviews it. Plan for that review the same way you plan an FDA submission.

Notified body review and the CE certificate

A notified body audits your quality system and technical documentation, then issues the CE certificate that lets the product carry the mark. The technical file is the European cousin of the FDA submission: same standards (IEC 62304, ISO 14971, IEC 62366-1), different format and reviewer.

Lead times at notified bodies run long, and MDR audits are thorough. Start the engagement early; switching notified bodies mid-project costs months.

UK MHRA and other markets

The UK runs its own system through the MHRA. CE-marked devices are still accepted in Great Britain while the government weighs making that recognition indefinite, with UKCA as the eventual domestic mark. Other markets each add their own registration layer, so sequence them: FDA or CE first, then the rest. The SaMD regulatory approval process has an EU twin, and the two files overlap more than the two fee schedules do.

Challenges in SaMD certification: common roadblocks and how to overcome them

Most SaMD teams hit the same handful of roadblocks on the way to SaMD certification. Here they are, with the fix for each.

Implementing SaMD standards from the start

Do you think it’s easier to build a house from scratch or retrofit an old one to modern standards? The same logic applies to SaMD development. Upgrading existing software to meet SaMD compliance standards is slow and messy, and implementing the standards from the start is the cheaper order of operations.

Complying with HIPAA regulations

If your software touches protected health information, HIPAA applies alongside your device obligations. The two programs share safeguards: access controls, audit logging, and breach procedures. Build them once, then document them for both. See our guide to HIPAA-compliant app development.

Managing software updates

Updates improve your software, and they split your install base across versions. Push users to update when an old version is detected, and track which versions are in the field so a safety issue can reach the right devices.

Considering costs for small businesses

Good news for small businesses: you pay a quarter of the standard fee for 510(k) submissions, and similar discounts apply to De Novo and PMA. That cuts the journey to SaMD certification down to a budget a startup can defend.

Fix these four early and the rest of the program is mostly execution.

SaMD case study: what a real submission looked like

Case studies in SaMD marketing usually stop at “and then they got cleared.” A file in progress teaches more, so here’s the shape of one we have taken through the process, with the client’s details left out.

The pathway question comes first. When no predicate device exists for what the software measures, the route is a De Novo classification request, and the classification has to be argued from scratch. That one answer sets the test plan, the documentation, and the review timeline.

A Pre-Sub meeting is where the plan gets tested. Bring the questions you are least sure about, like how a model change shifts outputs and whether measurements stay comparable across versions. FDA’s answer tells you what to de-risk before filing. In this file, the answer reshaped the roadmap: retire the unused framework and dead code, validate the replacement, then reprocess historical data once the swap is proven. Changing the measurement engine after clearance turns into a reviewer conversation.

Documentation and security decide the schedule. Design history, risk files, test protocols, and traceability take months, and a pre-submission security review belongs in that same window, because every finding has to be closed before the file goes in. De-identification and PHI handling come up in nearly every design conversation once patient data is in scope.

Two patterns hold across the files we build. The pathway decision and the model-change strategy get made before a single document is written, and teams that start their records on day one spend their time answering reviewers instead of reconstructing history.

Lessons from successful SaMD certifications

• Start the quality system and design controls on day one.
• Treat intended use as a contract: every claim needs a test behind it.
• Budget for documentation the way you budget for engineering.
• Bring regulatory review into the roadmap, so a change never surprises it.

We can’t publish the details of a submission while it is under review. When a file clears, it earns its own write-up.

AI-enabled SaMD: what the FDA expects in 2026

AI-enabled devices are a settled category now. FDA’s list shows 1,451 AI/ML-enabled device authorizations through the end of 2025, 295 of them new last year. The open question is how the agency keeps up as models change after clearance.

Predetermined change control plans (PCCP)

A Predetermined Change Control Plan (PCCP) is a plan filed with your submission that says, up front, what changes the device will make after clearance and how you’ll control the risk of each one. FDA finalized the PCCP guidance in December 2024. Roughly 26 of the 1,451 cleared AI devices have an authorized PCCP so far, which tells you the bar is real.

AI-enabled device software functions guidance

FDA’s draft guidance, AI-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations, published in January 2025, describes what the agency wants across the whole model lifecycle: data management, training, validation, and monitoring. It’s still in draft, and the final will set the practical bar for AI-enabled SaMD certification. Build to the draft now and the final won’t surprise you.

Good machine learning practice

FDA, Health Canada, and the UK’s MHRA publish joint Good machine learning practice principles for medical devices. The list reads like applied rigor: good data, separation of train and test, independent validation, and production monitoring. FDA guidance points to GMLP for SaMD development, and IEC 62304 lifecycle discipline applies to model code the same as to any other software as a medical device. The operational read is ours: model monitoring is where cleared products drift into trouble, and post-market surveillance is what catches it.

Regulatory frameworks for software keep adapting. The process they govern is stable: classify early, pick the pathway, build the file, and submit through eSTAR. If your health app is heading toward FDA, reach out and we’ll map your SaMD regulatory pathway before the build starts, so the submission isn’t a retrofit.

Related Articles:

1. SaMD app development
2. SaMD clinical evaluation
3. Medical device software development
4. Medical device development costs
5. Health AI medical device FDA clearance

[Reviewed October 2026. Regulatory reviewed by Pamela Schmidt, SaMD expert at Topflight Apps. Originally published on December 18, 2023]