SaMD Cybersecurity FDA Requirements: 2024 Compliance Guide

Master SaMD cybersecurity FDA requirements. Learn premarket submission needs, SBOM standards, and postmarket monitoring for SaMD under Section 524B.

This guide is written for medical device manufacturers navigating SaMD cybersecurity FDA requirements. It is built from real submissions, FDA correspondence, and the standards reviewers actually cite. Use it as a working reference: read straight through, jump to the section that matches your current gap, or hand it to your engineering and regulatory leads as a checklist.

Understanding SaMD in the Eyes of the FDA

Software as a Medical Device is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device, and the FDA regulates it under the same statutory framework as any other device, including Section 524B where applicable. Because SaMD often ships as a mobile app, cloud service, or standalone algorithm, its attack surface looks different from an embedded device: API endpoints, cloud infrastructure, third-party authentication, and update mechanisms all matter more than physical interfaces. The IMDRF risk categorization framework (state of the patient condition versus significance of information provided) shapes how much rigor the FDA expects in your cybersecurity documentation, with higher-risk categories drawing the same scrutiny as a Class II or III hardware device.

SaMD vs. SiMD: Regulatory Distinction

Software in a Medical Device (SiMD) is embedded in or controls a piece of hardware, while SaMD performs its medical function independently of any specific hardware platform, often running on general-purpose computing devices like smartphones or servers. This distinction matters for cybersecurity because SiMD threat models typically include physical access and hardware tampering vectors, while SaMD threat models need to focus more heavily on network-based attacks, cloud misconfigurations, and the security posture of the general-purpose platform it runs on, which the manufacturer does not fully control. Reviewers expect your risk assessment to reflect this difference rather than reusing a hardware-centric threat model template for a purely software product.

Section 524B and the 'Cybersecurity Device' Definition

Section 524B defines a cyber device as one that includes software, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats, and most SaMD products meet all three criteria by definition. This means SaMD manufacturers cannot argue their way out of 524B obligations by pointing to the absence of physical hardware; the SBOM, SPDF, and postmarket vulnerability management requirements apply in full. The FDA has been explicit that software-only products face identical premarket cybersecurity content expectations to hardware-containing devices, so SaMD submissions should not be scoped as a lighter-weight cybersecurity review.

Core Premarket Cybersecurity Requirements for SaMD

The premarket package for SaMD needs to demonstrate that security was built into the development process from the start, not bolted on before submission. Reviewers look for evidence that the SPDF, threat modeling, and SBOM are all internally consistent and reflect the actual architecture of the software, including any cloud or third-party dependencies.

The Secure Product Development Framework (SPDF)

An SPDF describes the processes your organization uses to develop, maintain, and support software securely across its lifecycle, and for SaMD this typically means documenting secure coding standards, code review practices, dependency management, and how security requirements are integrated into your existing IEC 62304 software development lifecycle. The FDA does not mandate a specific framework by name but expects your SPDF to align in substance with recognized approaches such as NIST's Secure Software Development Framework (SSDF). For cloud-hosted SaMD, your SPDF documentation should also address how infrastructure-as-code, CI/CD pipeline security, and cloud configuration management fit into the broader framework, since these are areas hardware-focused SPDF templates often omit.

Threat Modeling Requirements for Software Applications

Threat modeling for SaMD should map the actual data flow through the application, including any APIs, third-party SDKs, authentication mechanisms, and cloud services, using a structured methodology such as STRIDE. Because SaMD frequently integrates with EHR systems, mobile operating systems, and cloud identity providers, the threat model needs to account for risks introduced by these integrations even though the manufacturer does not control the underlying platform's security. Reviewers pay particular attention to how the threat model addresses authentication and authorization boundaries, since improperly scoped access controls are a common root cause of clinical data exposure in software-only products.

Third-Party Software and SBOM Documentation

Most SaMD products rely heavily on open-source libraries, cloud SDKs, and third-party frameworks, which makes the SBOM arguably more consequential for software-only products than for embedded devices with a smaller software footprint. The SBOM must be machine-readable, cover both direct and transitive dependencies, and be paired with a documented process for monitoring newly disclosed vulnerabilities in those components after release. Manufacturers should also track license obligations and end-of-support timelines for third-party components, since an unsupported library still represents a live cybersecurity risk even if no vulnerability has been publicly disclosed yet.

Cybersecurity Testing Mandates for Software Applications

Testing expectations for SaMD extend beyond functional verification to include security-specific testing that demonstrates resistance to realistic attack scenarios, particularly for products with network connectivity or cloud backends.

Vulnerability Communications and Disclosure Plans

A coordinated vulnerability disclosure plan for SaMD should specify how security researchers can report findings, expected response and remediation timelines, and how patches will be delivered given that most SaMD updates happen through app stores or automatic cloud deployment rather than manual firmware updates. Because SaMD update mechanisms are often faster than hardware device updates, your plan should also describe how you validate patches before pushing them to production, since a rushed security fix that breaks clinical functionality creates its own patient safety risk. Aligning the plan with ISO/IEC 29147 and 30111 gives reviewers a recognizable structure to evaluate against.

Software Penetration Testing Expectations

Penetration testing for SaMD should cover the full application stack: client-side application security, API security, authentication and session management, and cloud infrastructure configuration, not just the user-facing interface. Because SaMD often shares infrastructure across multiple product lines or customers, testers should also evaluate tenant isolation and data segregation where the product uses multi-tenant cloud architecture. Findings should be documented with clear severity ratings and remediation evidence, since reviewers increasingly ask to see that identified vulnerabilities were actually fixed and retested, not just logged.

Postmarket Requirements: Maintaining SaMD Compliance

Because SaMD can be updated far more frequently than hardware-based devices, postmarket cybersecurity management is a continuous, near-real-time obligation rather than a periodic review cycle.

Coordinated Vulnerability Disclosure (CVD) Programs

A mature CVD program for SaMD includes a published security contact, a documented intake and triage process, and defined service-level targets for acknowledging and resolving reports based on severity. Given how quickly software vulnerabilities can be weaponized, SaMD manufacturers should have a faster triage timeline than what might be acceptable for a device with a longer field-update cycle, and that expectation should be reflected explicitly in your CVD documentation.

Monitoring and Patch Management for Cloud-Based SaMD

Cloud-based SaMD requires continuous monitoring of the underlying infrastructure, container images, and third-party dependencies for newly disclosed vulnerabilities, paired with a patch management process that can distinguish between changes requiring FDA notification and routine maintenance patches that do not. Manufacturers should maintain change control records that clearly document the rationale for each classification decision, since this is an area where the FDA has issued guidance specifically to help manufacturers make defensible determinations about which updates require a new submission.

Common FDA Submission Pitfalls for SaMD Developers

The most common pitfalls include submitting an SBOM that only covers top-level application dependencies and misses transitive dependencies pulled in by third-party SDKs, treating cloud infrastructure security as outside the scope of the cybersecurity submission, applying a hardware-centric threat model template that does not reflect the software's actual architecture, and underestimating how quickly postmarket vulnerability monitoring needs to operate given how fast SaMD update cycles typically move. Developers coming from a pure software background sometimes also underestimate the documentation rigor the FDA expects compared to typical commercial software release practices, leading to gaps between what engineering teams consider "done" and what a regulatory submission requires.

How Blue Goat Cyber Approaches SaMD cybersecurity FDA requirements

We treat SaMD cybersecurity FDA requirements as a regulated engineering workstream, not a one-time document drop. Every engagement is led by senior medical-device security engineers who have shipped 250+ FDA cybersecurity submissions across 510(k), De Novo, PMA, and EU MDR pathways. Here is how we run it end to end:

• Scoping against your device profile. We baseline connectivity, interfaces, data flows, and intended use before we touch a template - because reviewer expectations for a Class II wearable are not the same as a networked hospital platform.
• Standards mapping in writing. Every deliverable is traced to the February 2026 FDA premarket cybersecurity guidance, AAMI SW96, AAMI TIR57 / TIR97, IEC 81001-5-1, and ISO 14971 - with the citation in the artifact itself so reviewers do not have to guess.
• Evidence generated inside your QMS. Threat models, SBOMs, security risk assessments, and test reports are versioned under design controls so the traceability from requirement → test → residual risk holds up under audit.
• Independent testing where it counts. Penetration testing and vulnerability analysis are executed by a testing team that does not also write the design - the separation FDA reviewers increasingly expect on cyber devices.
• Deficiency-ready posture. We anticipate the RTA, AI-letter, and Major deficiency patterns FDA has issued over the past 24 months and pre-empt them in the initial submission, cutting the odds of a second review cycle.
• Postmarket handoff, not abandonment. Every premarket package leaves you with a working postmarket monitoring plan, CVD process, and update cadence so the evidence you shipped stays defensible after clearance.

If you want that treatment applied to your SaMD cybersecurity FDA requirements package, our FDA Premarket Cybersecurity Services and FDA Cybersecurity Deficiency Response engagements are the two most common entry points.

Frequently asked questions

What are the FDA cybersecurity requirements for SaMD?

SaMD is subject to the same Section 524B requirements as any other cyber device: a Secure Product Development Framework, a machine-readable SBOM, a vulnerability disclosure and postmarket management plan, and evidence of security testing including threat modeling and penetration testing. Because SaMD is software-only, the specific content of these artifacts needs to reflect the software's actual architecture, including cloud infrastructure, APIs, and third-party dependencies, rather than a template built for embedded hardware devices. Reviewers also expect the SBOM to include transitive dependencies pulled in through SDKs and libraries, since SaMD products often have a larger and more complex dependency tree than comparable hardware devices. Manufacturers should scope their cybersecurity documentation around the actual attack surface of the software, not assume a lighter review because there is no physical device.

Does SaMD require a Software Bill of Materials (SBOM)?

Yes, and for SaMD the SBOM is often more consequential than for hardware devices because software-only products typically depend on a larger number of open-source libraries, cloud SDKs, and third-party frameworks. The SBOM must be machine-readable, in a format such as SPDX or CycloneDX, and must cover transitive dependencies in addition to direct ones. Manufacturers also need a documented process for monitoring newly disclosed vulnerabilities in these components after release, since a static SBOM produced only at submission time does not satisfy the ongoing monitoring expectation. License and end-of-support tracking for third-party components is also good practice, since an unsupported library represents an ongoing risk even without a currently known vulnerability.

How does FDA Section 524B affect software-only medical devices?

Section 524B applies in full to SaMD because most software-only products meet the statutory definition of a cyber device: they include software, can connect to the internet, and have characteristics that could be vulnerable to cybersecurity threats. This means SaMD manufacturers must produce an SBOM, demonstrate an SPDF, and maintain a postmarket vulnerability management plan just like any hardware-containing device. The practical difference is in how these obligations get implemented, since SaMD update mechanisms (app store releases, cloud deployments) move faster than hardware firmware updates, and your postmarket plan should reflect that faster cadence. The FDA has been clear that software-only status does not reduce cybersecurity documentation expectations.

Is penetration testing required for SaMD FDA clearance?

Yes, penetration testing is expected for SaMD products with network connectivity, and the scope should cover the full application stack, including client-side application security, API security, authentication and session management, and cloud infrastructure configuration. For multi-tenant cloud architectures, testing should also evaluate tenant isolation and data segregation, since a breach of one customer's data boundary in a shared cloud environment has broader consequences than a single-device compromise. Findings need to be documented with severity ratings and remediation evidence, since reviewers increasingly expect to see that vulnerabilities were fixed and retested, not just identified. Testing should be performed by testers independent of the development team to avoid blind spots from familiarity with the codebase.

How do I document threat modeling for a software medical device?

Start by mapping the actual data flow through your application, including every API endpoint, third-party SDK, authentication mechanism, and cloud service, using a structured methodology such as STRIDE. Document trust boundaries explicitly, particularly around integrations with EHR systems, mobile operating systems, or cloud identity providers where you do not control the underlying platform's security posture. For each identified threat, record the mitigation implemented, the residual risk remaining, and how that mitigation was verified during testing, so the whole document reads as a traceable chain from threat to test. Avoid reusing a hardware-centric threat model template, since SaMD's attack surface (network-based attacks, cloud misconfiguration, platform dependencies) looks meaningfully different from an embedded device's.

What is the difference between premarket and postmarket SaMD cyber requirements?

Premarket requirements focus on demonstrating that your SPDF, threat model, SBOM, and testing evidence support a reasonable assurance of safety and effectiveness at the time of submission. Postmarket requirements are ongoing and require continuous vulnerability monitoring, a functioning coordinated vulnerability disclosure program, and a patch management process that can distinguish updates requiring a new FDA submission from routine maintenance changes. For SaMD specifically, the postmarket obligation is more demanding in practice because update cycles are faster than hardware devices, so your monitoring and triage timelines need to be correspondingly quick to keep pace with how rapidly software vulnerabilities can be discovered and exploited. Both phases need to be linked through consistent documentation, since postmarket monitoring is only meaningful if it references the same SBOM and threat model established premarket.

Where this fits in the cluster

This page sits downstream of our pillar resources on SaMD cybersecurity FDA requirements. If you arrived here from a different starting point, these are the most useful adjacent pages:

• FDA Premarket Cybersecurity Services
• AI ML Medical Device Security
• The SPDF Playbook for FDA-Ready Medical Devices
• 12 Reasons the FDA Rejects Medical Device Cybersecurity Submissions
• The MedTech Cybersecurity Standards Decoder

Related from Blue Goat Cyber

• FDA Postmarket Cybersecurity Services
• Medical Device Penetration Testing
• Medical Device Threat Modeling
• FDA-Compliant SBOM Services
• FDA Cybersecurity Deficiency Response
• FDA Cybersecurity Deficiency Letter Response Checklist

Sources & primary references

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. FDA.gov
• Postmarket Management of Cybersecurity in Medical Devices. FDA.gov
• Software as a Medical Device (SaMD): Key Definitions and Framework. IMDRF
• Framework for Improving Critical Infrastructure Cybersecurity (NIST CSF). NIST.gov

Talk to a regulatory cybersecurity team

If you are working through SaMD cybersecurity FDA requirements and want a second pair of eyes on your submission package, we ship cybersecurity deliverables for medical device manufacturers across 510(k), De Novo, PMA, and EU MDR pathways. Book a discovery session and we will walk your evidence with you.