SaMD Regulatory Requirements: What FDA Expects from Software as a Medical Device

Why SaMD Regulation Has Become More Demanding

Software as a Medical Device is no longer a niche category. AI-powered diagnostics, clinical decision support systems, remote patient monitoring platforms, and algorithm-driven treatment recommendations are now mainstream product categories — and FDA has spent the last several years building a comprehensive regulatory framework to match.

The core challenge with SaMD is that software fails differently than hardware. A physical device degrades predictably. Software can change its behavior suddenly, learn from data in ways its developers did not anticipate, and interact with other software systems in complex ways. These characteristics require a different regulatory approach.

For manufacturers of software-enabled devices, understanding what FDA actually expects — and where the regulatory requirements have hardened in the last three years — is essential before your next submission.

SaMD Classification: IEC 62304 + FDA Guidance

FDA does not classify SaMD in isolation. It intersects two frameworks: the device classification system (Class I, II, III under 21 CFR) and the software safety classification system defined in IEC 62304.

IEC 62304 assigns software a safety class based on the severity of harm that could result from a software failure. Class A software, where a failure cannot contribute to a hazardous situation, carries the lightest development process requirements. Class B software, where a failure can result in non-serious injury, requires more rigorous processes. Class C software, where a failure can result in serious injury or death, carries the most demanding development lifecycle requirements.

FDA's 2019 software guidance and its 2023 draft guidance on Predetermined Change Control Plans both reference IEC 62304 as the expected development standard. Your submission must demonstrate that your software safety classification is correctly assigned — based on hazard analysis, not on convenience — and that your software development lifecycle follows processes appropriate for that classification.

For AI/ML-based SaMD, the classification question becomes more complex. Machine learning models that evolve post-market may shift in their safety class as their intended use is refined. FDA expects manufacturers to address this explicitly in their classification rationale.

SOUP Management Obligations

Software of Unknown Provenance (SOUP) — open-source libraries, commercial off-the-shelf software components, third-party frameworks — represents one of the most consistently underaddressed areas in SaMD submissions.

IEC 62304 §8.1.2 requires manufacturers to identify all SOUP components, evaluate their fitness for use in the medical software context, and document the known anomalies. FDA reviewers look for this in software documentation submissions and expect to see:

A complete SOUP inventory that lists every third-party component used in the software build. Not just major libraries, but all dependencies, including transitive dependencies that your primary libraries rely on.

A risk assessment for each SOUP component that evaluates the potential impact of a SOUP anomaly on device safety. Components that directly affect clinical functions carry a different risk profile than logging libraries.

A monitoring process for SOUP updates, security advisories, and disclosed vulnerabilities. FDA's 2023 cybersecurity guidance specifically requires manufacturers to monitor and respond to vulnerabilities in their software components throughout the device lifecycle — this obligation directly intersects with SOUP management.

Manufacturers who treat SOUP management as a static documentation exercise — filling out a table once during development and never updating it — create significant liability. SOUP vulnerability monitoring must be an ongoing process.

PCCP for AI/ML Devices: FDA's 2023 Guidance

The Predetermined Change Control Plan (PCCP) is FDA's answer to a genuine regulatory challenge: AI and machine learning algorithms improve over time through training updates, and requiring a new submission for every performance improvement would be both unworkable and contrary to patient safety.

FDA finalized guidance on PCCPs for AI/ML-enabled devices in 2023. A PCCP allows manufacturers to define, in their initial submission, a specific set of algorithm modifications that can be made post-clearance without requiring a new 510(k) or PMA supplement. The modifications must be precisely defined, within specified performance bounds, and subject to validation protocols described in the PCCP.

The structure FDA expects in a PCCP includes a description of modifications — the specific types of changes that will be made, defined in enough detail that FDA can evaluate whether the proposed change scope is appropriate. Performance goals — quantitative bounds on algorithm performance, specified in advance, that must be met before any PCCP modification can be deployed. Methodology — how training, testing, and validation will be conducted for each type of modification. Update procedures — how the manufacturer will assess whether a proposed modification exceeds the PCCP scope and requires a new submission.

The PCCP does not reduce the safety bar for AI/ML devices. It creates a transparent, pre-approved pathway for specific, bounded improvements. Modifications that exceed the PCCP scope still require a new submission.

For manufacturers building AI-powered SaMD, a well-constructed PCCP is a competitive advantage: it enables faster iteration and continuous improvement while maintaining regulatory compliance.

Cybersecurity Submission Requirements Post-2023

The Consolidated Appropriations Act of 2023 gave FDA explicit authority to require cybersecurity information in premarket submissions — codifying what had previously been guidance. For any SaMD submitted after March 2023, cybersecurity documentation is a mandatory submission element, not optional best practice.

What FDA requires in premarket cybersecurity submissions includes a Software Bill of Materials (SBOM) listing all software components, including third-party and open-source components. A cybersecurity risk assessment identifying threats, vulnerabilities, and controls. A Security Architecture diagram showing the device's interfaces, data flows, and trust boundaries. A plan to monitor, identify, and address cybersecurity vulnerabilities post-market.

For connected devices and AI/ML SaMD, the threat surface is particularly broad. Submission reviewers expect to see evidence that threat modeling was conducted (STRIDE or similar methodology), that security controls are designed into the architecture rather than bolted on, and that the manufacturer has a defined vulnerability disclosure and response process.

The SBOM requirement intersects directly with SOUP management. Manufacturers who have a mature SOUP identification and tracking process will find SBOM generation largely automated. Those starting from scratch will need to build the inventory from scratch — a significant effort for complex software architectures.

When a 510(k) Is Required for SaMD

Not all SaMD requires FDA premarket review. The first question is always whether the software meets the definition of a medical device under section 201(h) of the FD&C Act — and whether it falls outside the categories excluded from device definition under the 21st Century Cures Act.

FDA's 2019 guidance on Clinical Decision Support Software provides the key framework. Software is excluded from device definition if it displays, analyzes, or prints medical information without changing it, or if it supports administrative functions. Software that meets a higher threshold — providing specific treatment recommendations or diagnoses based on patient-specific data — will typically require premarket review.

For SaMD that does require premarket review, the pathway depends on the risk level. Most SaMD is Class II and eligible for 510(k) clearance. A 510(k) for SaMD requires all standard elements plus software documentation following FDA's software guidance: level of concern determination, software description, architecture design, hazard analysis, design specifications, traceability matrix, and V&V documentation.

If no predicate device exists for a novel SaMD function, De Novo classification may be the appropriate pathway. De Novo is more resource-intensive than 510(k) but establishes a new device classification that subsequent manufacturers can use as a predicate.

The SaMD Regulatory Toolkit at samd-regulatory-toolkit.vercel.app packages all six critical templates — SaMD classification rationale, SOUP management documentation, PCCP framework, cybersecurity risk assessment, 510(k) software documentation checklist, and post-market monitoring plan — into a single download for $247. It is the starting point every SaMD manufacturer needs before writing a single line of submission documentation.