Software as a Medical Device:
Regulatory Pathways, Security,
and Deliverables Guide

Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. The term was coined by the IMDRF and adopted by both the FDA and the European Commission as the working definition across their regulatory frameworks.

A medical purpose includes diagnosis, treatment, prevention, monitoring, or prediction of disease or physiological conditions. Software that only provides administrative support, wellness tracking without a medical claim, or electronic health record management is generally not SaMD.

Confusing the two leads to incorrect classification and pathway selection — one of the most common and costly early-stage regulatory mistakes.

The FDA classifies SaMD into its standard three-tier system based on risk to the patient if the software fails or provides incorrect output:

Classification is determined by the software's intended use and the risk to the patient. The FDA's product code database and Policy for Device Software Functions and Mobile Medical Applications (2022) provide classification guidance specific to software functions.

Under Regulation (EU) 2017/745 (MDR), Rule 11 of Annex VIII governs software classification. Rule 11 represented a major upclassification from the former MDD — under MDD, most standalone software was Class I. Under MDR, virtually all diagnostic or therapeutic SaMD is Class IIa or higher.

MDCG 2019-11 provides a step-by-step decision flowchart for classifying software under MDR, including boundary cases between medical devices and general-purpose software.

• 510(k) Premarket Notification. The primary pathway for Class II SaMD. The manufacturer demonstrates substantial equivalence to a legally marketed predicate device. Requires intended use, predicate comparison, software documentation, and performance/validation data.
• De Novo Classification. Used when no predicate exists and the SaMD presents low-to-moderate risk. The manufacturer proposes a new device type with special controls. A successful De Novo creates a classification regulation and product code that future applicants can reference as a 510(k) predicate.
• Premarket Approval (PMA). Required for Class III SaMD. Demands valid scientific evidence — typically clinical investigations — demonstrating safety and effectiveness. The most resource-intensive pathway.

The FDA's Guidance for the Content of Premarket Submissions for Device Software Functions (2023) defines the documentation expected for each risk tier:

As of February 2, 2026, the FDA finalized the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 by reference, replacing the former 21 CFR Part 820. This harmonizes U.S. requirements with international standards. Key elements:

• Design Controls: Mandatory for Class II and III devices. Requires documented design input, output, review, verification, validation, and transfer. The Design History File (DHF) remains the accumulated record proving compliance.
• Risk-Based Approach: Risk management throughout the device lifecycle, aligned with ISO 14971.
• CAPA: Corrective and Preventive Action processes for addressing nonconformities.
• Complaint Files: All complaints documented, investigated, and dispositioned.
• Precedence: FDA definitions for medical devices take precedence where they conflict with ISO definitions.

The FDA guidance Deciding When to Submit a 510(k) for a Software Change (2023) provides a three-question decision framework: Does the change affect intended use? Does it introduce new risks or alter existing controls? Could it affect safety or effectiveness? Every change must be documented through change control regardless of whether a new submission is required, including rationale, risk assessment, verification/validation evidence, and approval.

All SaMD on the EU market must bear CE marking under Regulation (EU) 2017/745. The route depends on classification:

• Class I: Self-declaration of conformity (Annex II & III). No Notified Body involvement. QMS still mandatory.
• Class IIa: Notified Body assessment via Annex IX (QMS) or Annex XI (product conformity verification).
• Class IIb: Full Annex IX assessment. Technical documentation scrutinized on a representative basis.
• Class III: Full Annex IX assessment including design dossier examination. Clinical investigations typically required.

• Section 17.1: Software must be developed in accordance with the state of the art, including development lifecycle, risk management, information security, verification, and validation.
• Section 17.2: Software for mobile platforms must account for screen size, touch controls, connectivity, lighting, and noise conditions.
• Section 17.3: Manufacturers must specify minimum hardware, network, and IT security requirements for the software to run as intended.
• Section 17.4: Fault tolerance and reliable, repeatable behavior under intended conditions.

Article 61 and Annex XIV require a clinical evaluation for all device classes. MDCG 2020-1 recommends a three-stage approach for SaMD: valid clinical association, analytical validation, and clinical validation. Equivalence-based evaluations require contractual access to the comparator device's technical documentation — a bar that is difficult to clear in practice. For Class III, clinical investigations are the default expectation.

MDCG 2020-3 outlines how to assess whether a software change constitutes a "significant change" affecting conformity. Changes to intended purpose, algorithm logic, or clinical performance thresholds are likely significant. All changes must be documented through the QMS; significant changes may trigger supplemental Notified Body review.

Cybersecurity is no longer a best practice — it is a regulatory requirement in both jurisdictions. SaMD that connects to networks, processes patient data, or operates in clinical IT environments must meet explicit security expectations at the design, submission, and postmarket stages.

The FDA's final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026) supersedes prior versions and addresses requirements under section 524B of the FD&C Act for cyber devices. Key premarket deliverables:

• Threat model. Identify assets, threat actors, attack vectors, and potential impact on patient safety.
• Security architecture. Document authentication, authorization, encryption, and communication protocols. Describe protections against unauthorized access, data tampering, and denial of service.
• Software Bill of Materials (SBOM). A complete, machine-readable inventory of all software components including open-source libraries, third-party modules, and their versions. Required for all premarket submissions.
• Security testing evidence. Vulnerability scanning, static analysis, fuzz testing, and penetration testing results. Document identified vulnerabilities and disposition.
• Security risk assessment. Integrated with the risk management file. Covers exploitability, severity of patient harm, and compensating controls.
• Patch and update plan. Documented process for delivering security patches throughout the total product lifecycle, including end-of-support planning.
• Cybersecurity labeling. IFU must include security information, recommended configurations, and user responsibilities.

Postmarket cybersecurity management requires ongoing vulnerability monitoring (CISA ICS-CERT, CVE databases), timely risk assessment and remediation, a coordinated vulnerability disclosure policy, and defined criteria for when a vulnerability constitutes a reportable event.

Annex I, Section 17.1 mandates development in accordance with the state of the art, explicitly naming information security and protection against unauthorized access. Section 17.3 requires specification of minimum IT security measures for the operating environment. Annex I, §14.2(d) requires protection against unauthorized modification of data used by the device.

MDCG 2019-16 Rev. 1 provides implementation details: security risk management integrated with ISO 14971, secure design principles (defense in depth, least privilege, fail-safe defaults), verification of security controls, incident response planning, and lifecycle maintenance. The EU Cyber Resilience Act (CRA) will impose additional requirements on connected products — SBOM obligations, mandatory coordinated vulnerability disclosure, and vulnerability handling processes.

IEC 62304:2006+AMD1:2015 is the foundational standard for medical device software development. Harmonized under EU MDR and recognized by the FDA as a consensus standard. It assigns software to one of three safety classes based on the severity of potential harm:

• Class A: No injury or damage to health possible.
• Class B: Non-serious injury possible.
• Class C: Death or serious injury possible.

The safety class determines the depth of required processes and documentation. Class C demands the most comprehensive evidence.

Traceability is the documented ability to trace every requirement forward to design, implementation, and verification — and backward from test evidence to the originating requirement. Gaps in traceability are a top finding in both FDA inspections and Notified Body audits. What must be traceable:

• System requirements → Software requirements. Each system-level requirement with a software implementation links to one or more software requirements.
• Software requirements → Architecture / Design. Each software requirement links to the architectural element or detailed design that implements it.
• Software requirements → Verification / Validation. Each software requirement links to test cases and results demonstrating it has been met.
• Risk controls → Requirements → Verification. Every risk control in the risk management file traces to a requirement implementing it and to test evidence confirming effectiveness.

IEC 62304 requires a Software Configuration Management Plan covering identification of all configuration items (source code, documents, tools, build scripts, test data), version control for every deliverable, change control with evaluation and approval before release, and build reproducibility — the ability to recreate any released version from its configuration items.

Core deliverables for SaMD regulatory submissions and lifecycle management. Use this as a gap assessment against your current documentation state:

SaMD regulatory submissions fail for predictable reasons: missing or incomplete documentation, traceability gaps, cybersecurity deliverables that don't meet current guidance, and QMS processes that weren't built for a regulated product from day one. GovaGuard exists specifically to close those gaps for bootstrapped and growth-stage healthtech companies — the teams building real clinical software without a 20-person regulatory department behind them.

We bring three capabilities that matter here:

• Fractional CISO with SaMD-specific experience. HIPAA, FDA cybersecurity guidance, and SBOM requirements are distinct from general security work. We've built the documentation, walked through FDA reviews, and know what a 510(k) submission looks like when the cybersecurity section is done properly versus when it creates a deficiency letter.
• Documentation and traceability infrastructure. We build the SRS, risk management file, traceability matrix, and design history file in a format that survives Notified Body and FDA scrutiny — not templates to fill in, but working documents integrated with your actual development process.
• Regulatory strategy, not just compliance checklists. Classification decisions, predicate selection for 510(k), equivalence strategy for EU MDR, De Novo vs. 510(k) tradeoffs — these are judgment calls that determine how long and how expensive your path to market is. We help you make them early, before the wrong answer is baked in.

• SaMD is software that performs a medical purpose independently of hardware. Classification under FDA (Class I–III) and EU MDR (Rule 11, Class IIa–III) determines every downstream requirement. Getting this wrong early cascades into pathway misselection and documentation gaps that are expensive to correct.
• FDA offers three pathways — 510(k), De Novo, and PMA — with escalating evidence demands. EU MDR requires CE marking via Notified Body for Class IIa and above. Most SaMD teams underestimate the documentation depth required even for 510(k).
• IEC 62304 is the backbone of SaMD development. Safety class (A, B, C) drives documentation depth. Class C demands full unit-level design and verification evidence. Build this into your development process, not as a retroactive documentation effort.
• Traceability is non-negotiable. Bi-directional tracing from requirements through design, implementation, testing, and risk controls is the top finding in FDA inspections and Notified Body audits. Invest in a working traceability matrix from day one — it is the single highest-value regulatory artifact you can maintain.
• Cybersecurity is a regulatory requirement, not optional. Both FDA and EU MDR mandate threat modeling, security architecture, SBOM, and vulnerability management. The 2026 FDA guidance and the EU Cyber Resilience Act add further obligations. A missing or weak SBOM alone can generate a deficiency letter.
• Post-market obligations are continuous. PMS plans, PSURs, PMCF, CAPA, complaint handling, and vigilance reporting run for the device's entire market lifetime. Budget and process for them before launch, not after.
• Start with a QMS. ISO 13485:2016 compliance is a prerequisite under the 2026 QMSR. Build documentation, traceability, and change control into development from day one — retrofitting a QMS onto a shipping product is one of the most expensive corrections in healthtech.