Software as a Medical Device: Definition, Risk, and Rules

Reviewed September 17, 2026

A diagnostic algorithm running on a hospital server, a mobile app that calculates insulin dosing, and a cloud platform that flags arrhythmias in ECG data all raise the same question for the people building them: is this a medical device, and if so, what rules apply? Getting the answer wrong has real consequences. Manufacturers who misclassify their software risk marketing an unapproved device, missing the cybersecurity documentation the FDA now expects in every submission, or over-building compliance for a product that actually falls outside the regulated category altogether. This article works through the IMDRF definition, how SaMD differs from software in a medical device and from exempt clinical decision support, the four IMDRF risk categories, the FDA pathways that apply, the IEC 62304 safety classification that governs the build process, and the cybersecurity obligations that attach once the software qualifies as a cyber device.

Why This Matters

Misclassifying SaMD, or treating it as a lower-risk product than the IMDRF category and FDA pathway actually require, creates downstream problems that are expensive to fix after development is underway. A device built assuming IEC 62304 Class A rigor, then found during review to function at Class C risk, faces a redo of unit and integration testing that a correct classification at the design stage would have avoided. The FDA's Cybersecurity in Medical Devices final guidance, dated February 3, 2026, makes cybersecurity documentation a Refuse to Accept criterion for devices that meet the Section 524B cyber device definition, and most connected SaMD does. Manufacturers who treat cybersecurity as an afterthought risk a stalled submission rather than a straightforward review. Getting the classification and the security posture right from the start of development is far less costly than retrofitting them after a submission comes back with deficiencies.

What Is the IMDRF Definition of SaMD?

The International Medical Device Regulators Forum defines SaMD as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. This definition, published in IMDRF's 2013 framework document and still the reference point used by the FDA, the EMA, and other national regulators, hinges on two things: the software's intended medical purpose and its independence from a specific piece of hardware. A blood glucose meter's onboard firmware is not SaMD because it is embedded in and inseparable from the hardware. A mobile app that receives glucose readings from that meter and calculates an insulin dose recommendation is SaMD, because the calculation function stands on its own regardless of which meter or phone runs it.

The medical purpose element matters as much as the independence element. Software only qualifies as SaMD if its intended use, as described by the manufacturer, is to treat, diagnose, cure, mitigate, or prevent disease, or to inform clinical management. General wellness software, scheduling tools, and administrative systems fall outside SaMD even when they run in a healthcare setting, because they lack that intended medical purpose.

SaMD vs SiMD vs Wellness Software vs Exempt Clinical Decision Support

These four categories look similar from the outside but are treated very differently under FDA regulation, and confusing them is one of the most common classification mistakes manufacturers make.

Software in a Medical Device (SiMD) is embedded software that is part of a hardware device and cannot function independently of it. An infusion pump's dosing firmware, a pacemaker's programming logic, and an imaging system's acquisition software are all SiMD. SiMD is regulated as part of the hardware device under the same 510(k) or PMA submission, and it does not carry its own separate SaMD classification.

General wellness software is excluded from FDA device regulation under the agency's general wellness policy when it only relates to maintaining or encouraging a general state of health, such as fitness trackers or sleep coaching apps, and does not make disease-specific claims. The moment a wellness app claims to diagnose, treat, or mitigate a specific disease, it moves out of the wellness exemption and into SaMD territory.

Clinical decision support (CDS) software occupies its own carved-out space created by the 21st Century Cures Act. CDS software is exempt from FDA regulation as a device if it meets all four criteria in Section 520(o)(1)(E): it does not acquire, process, or analyze a medical image or signal; it displays, analyzes, or prints medical information; it is intended to support a healthcare professional in making a recommendation; and it allows that professional to independently review the basis for the recommendation rather than relying on it exclusively. CDS that fails any one of these four criteria, most often because it processes an image or signal directly, or because it does not let the clinician see the underlying basis for its output, is regulated as SaMD.

[KEY REQUIREMENT] Document the intended use statement precisely before development begins. The exact wording of the intended use, not the underlying technology, is what determines whether software is SaMD, exempt CDS, or general wellness software, and it drives every downstream classification and submission decision.

For a deeper comparison of SaMD and SiMD specifically, including how the two are documented differently in a submission, see our companion article, SaMD vs SiMD: What Medical Device Manufacturers Need to Know.

How Does the IMDRF Risk Categorization Work?

IMDRF sorts SaMD into four risk categories based on two factors: the significance of the information the software provides to a healthcare decision, and the state of the healthcare situation or condition it addresses. The framework treats these as a matrix rather than a single scale, and the resulting category informs how much clinical evidence and quality rigor a regulator expects.

Category I represents the lowest combined risk and Category IV the highest. A single piece of software is not locked into one category forever. If a manufacturer expands the same software's intended use from informing a non-serious condition to diagnosing a critical one, the IMDRF category and the corresponding regulatory expectations move with it.

What FDA Pathways Apply to SaMD?

Most SaMD reaches the market through the 510(k) pathway by demonstrating substantial equivalence to a legally marketed predicate device, but a growing share of novel SaMD, particularly software using adaptive machine learning or addressing a use case with no existing predicate, goes through De Novo classification instead. The FDA does not have a pathway called "SaMD clearance." Instead, SaMD is evaluated using the same device classification framework, Class I, II, or III, applied to any other medical device, with the IMDRF risk category informing but not directly dictating the FDA class.

De Novo requests are common for first-of-kind SaMD because no predicate exists to compare against, and a successful De Novo grant then becomes the predicate that later 510(k) submissions in the same category can reference. Class III SaMD, which is rare but does occur for software making life-sustaining or life-supporting claims, requires a Premarket Approval (PMA) application with full clinical evidence rather than a substantial equivalence argument. Regardless of pathway, the eSTAR submission template's single Cybersecurity attachment area is where the manufacturer's Section 524B documentation, threat model, and SBOM are expected to live.

What Software Safety Classification Does IEC 62304 Require?

IEC 62304 assigns every software system, including SaMD, one of three safety classes, A, B, or C, based on the severity of harm that could result if the software fails, and that classification determines how much documentation and testing rigor the development process must produce. Class A applies where no injury or damage to health is possible. Class B applies where non-serious injury is possible. Class C applies where death or serious injury is possible. Unlike the IMDRF risk category, which is about the clinical significance of the information the software provides, the IEC 62304 class is about engineering process rigor: what level of unit testing, architecture documentation, and risk control verification the development team must demonstrate.

See also: MQTT Vulnerabilities in Connected, CAN Bus Vulnerabilities in Medical Devices, and NeuroTech Cybersecurity Risks.

A SaMD product's IMDRF category and its IEC 62304 class are related but not identical, since IEC 62304 looks specifically at software failure modes rather than at the overall clinical use case. A Category III SaMD product, for example, will typically carry an IEC 62304 Class C classification for the components whose failure could directly cause serious harm, while lower-risk supporting modules within the same product might be classified separately at Class A or B.

When Is SaMD a Cyber Device Under Section 524B?

SaMD is a cyber device under FDA Section 524B when it includes software validated, installed, or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats, and the vast majority of networked or cloud-hosted SaMD meets all three conditions. Because Section 524B applies at the point of premarket submission, meeting the cyber device definition means the manufacturer must submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities, a process to provide reasonable assurance the device is cybersecure, an SBOM, and documentation of coordinated vulnerability disclosure processes.

The FDA's Cybersecurity in Medical Devices final guidance, dated February 3, 2026, describes what reviewers expect within each of these elements, including threat modeling, security risk assessment tied to ISO 14971, and evidence of a documented CISA 2026 SBOM Minimum Elements compliant SBOM. Since Section 524B refuse-to-accept enforcement began on October 1, 2023, submissions lacking this documentation for a qualifying cyber device have been returned rather than reviewed, so the classification question of whether SaMD meets the cyber device definition needs to be answered early in development, not at submission time.

Who Is Responsible for Cloud and Mobile Platform Security?

The SaMD manufacturer remains responsible for the security of its software regardless of whether it runs on a cloud platform, a mobile operating system, or a hospital-managed server, because the FDA's expectations attach to the manufacturer of record, not to the infrastructure provider. This means the manufacturer must document a clear division of responsibility with each platform: which party patches the operating system, which party manages identity and access controls, which party owns tenant isolation in a multi-tenant cloud deployment, and which party is responsible for monitoring and responding to a vulnerability once it is disclosed.

Cloud and mobile deployment does not create a gap in accountability, but it does create a gap in visibility if the manufacturer does not actively track the shared responsibility model. A manufacturer that assumes a cloud provider's general security certifications cover its own SaMD's specific threat model is likely to find that assumption tested during an FDA review or, worse, during an actual security incident.

What Postmarket Obligations Apply After Launch?

Once SaMD is on the market, the manufacturer must maintain the postmarket cybersecurity processes described in its premarket submission, including monitoring for new vulnerabilities in the software and its third-party components, issuing patches within the timelines the manufacturer committed to, and updating the SBOM as components change. Section 524B requires manufacturers to have a way to make patches and updates available on a reasonably justified regular cycle, and to have a coordinated vulnerability disclosure process that allows outside researchers to report issues.

For SaMD specifically, postmarket obligations extend to the deployment environment as well. If the software's intended use changes, if a new operating system version breaks compatibility, or if a cloud platform migration introduces a new attack surface, the manufacturer needs a documented change control process, tied back to its IEC 62304 lifecycle records, to evaluate whether the change requires a new risk assessment or a new regulatory submission.

How Blue Goat Cyber Approaches This

Blue Goat Cyber works with SaMD manufacturers from early architecture decisions through FDA submission and into postmarket monitoring. We help teams determine the correct IMDRF risk category and IEC 62304 safety class before development locks in an architecture that is expensive to change later. Our threat modeling work maps the manufacturer-versus-platform responsibility split for cloud and mobile deployments so that Section 524B documentation reflects how the software actually runs in production, not a generic template. We also build and maintain SBOMs aligned to the CISA 2026 SBOM Minimum Elements and support the vulnerability disclosure processes the FDA expects to see referenced in a submission. To see how this fits into a full premarket cybersecurity engagement, visit our medical device penetration testing services page.

Frequently Asked Questions

Is a mobile health app always SaMD?

No. A mobile health app is SaMD only if its intended use is a medical purpose, such as diagnosis or treatment, and it functions independently of specific hardware. An app that only tracks steps or sleep for general wellness purposes, without disease-specific claims, typically falls outside the SaMD definition and FDA jurisdiction.

Does SaMD need a 510(k)?

Most SaMD needs either a 510(k) or a De Novo submission, depending on whether a predicate device already exists. Class I SaMD is sometimes exempt from premarket submission, but the majority of Class II SaMD requires a 510(k), and novel Class II or III software without a predicate typically goes through De Novo or PMA.

What is the difference between SaMD and a medical device with embedded software?

SaMD functions independently of any specific hardware and is itself the regulated product. Embedded software, referred to as SiMD, is part of a hardware device and is regulated together with that hardware under a single submission rather than separately.

Do wellness apps need FDA clearance?

General wellness apps that only support a general state of health, without making disease-specific diagnostic or treatment claims, are excluded from FDA device regulation under the agency's general wellness policy. Once an app claims to diagnose or treat a specific disease, it typically needs to be evaluated as SaMD.

How does IEC 62304 relate to SaMD cybersecurity?

IEC 62304 governs the software development lifecycle and assigns a safety class based on potential harm from failure, which shapes engineering rigor but does not by itself cover cybersecurity. Cybersecurity requirements come from Section 524B and the FDA's February 3, 2026 final guidance, and are typically implemented alongside IEC 62304 controls rather than as a substitute for them.

What documentation does a SaMD cybersecurity submission need?

A SaMD cybersecurity submission typically needs a cybersecurity management plan, a threat model, a security risk assessment tied to ISO 14971, an SBOM, and evidence of a coordinated vulnerability disclosure process. Our companion guide, SaMD Cybersecurity Requirements: FDA, IEC 82304-1 and EU MDR, walks through each element in detail.

CTA

If you are developing SaMD and need help determining its IMDRF risk category, IEC 62304 safety class, or Section 524B cyber device status before you submit, Blue Goat Cyber can help you build the right documentation the first time. Contact us today to talk through your product's classification and cybersecurity requirements with our team.