On this page
Key Takeaways
- SaMD meets the Section 524B cyber device definition whenever it has connectivity or the technical capability to connect, which covers nearly every commercially relevant Software as a Medical Device product today.
- Because SaMD has no hardware boundary, its SBOM has to include cloud infrastructure dependencies, containerized components, and third-party APIs, not just application-level libraries.
- SaMD release cadence is typically much faster than hardware devices, which means the threat model, SBOM, and risk management file need to be built for continuous update rather than a single point-in-time submission.
- The FDA's Predetermined Change Control Plan (PCCP) framework is especially relevant to SaMD with adaptive or frequently updated algorithms, letting manufacturers pre-authorize a defined range of changes without a new submission.
- Postmarket monitoring for SaMD needs to account for the full deployment environment, including the operating system, container runtime, and cloud provider, since vulnerabilities in that stack are the manufacturer's responsibility to track even though they did not write that code.
Software as a Medical Device is subject to the same Section 524B cybersecurity requirements as any hardware device, an SBOM, threat model, security risk management report, and postmarket vulnerability management plan, but SaMD's lack of a hardware boundary and its faster release cadence change how each of those artifacts has to be built. Under the February 3, 2026 FDA premarket cybersecurity guidance, SaMD manufacturers need an SBOM that covers cloud and container dependencies, a threat model built for continuous deployment, and, where the algorithm updates frequently, a Predetermined Change Control Plan to avoid resubmitting for every change.
Software as a Medical Device, software intended for a medical purpose that runs independently of a hardware medical device, is squarely inside the FDA's cyber device definition whenever it has connectivity or the mere technical capability to connect, which in practice describes nearly all commercially viable SaMD. A standalone diagnostic algorithm that never touches a network in its intended use but ships with network stack code it does not disable still meets the statutory bar. Manufacturers who assume "we're just software, this doesn't apply to us" are consistently wrong about that assumption.
Why SaMD cybersecurity requirements look different in practice
The core artifacts required under Section 524B, SBOM, threat model, security risk management report, and postmarket plan, apply to SaMD exactly as they apply to embedded hardware devices. What changes is the shape of the underlying technical reality. A hardware device has a defined firmware boundary; SaMD's boundary is fuzzier, extending into cloud infrastructure, container orchestration, third-party APIs, and the operating environment it is deployed on, none of which the manufacturer necessarily controls end to end but all of which the manufacturer is responsible for accounting for in the security documentation.
SaMD also typically ships far more frequently than hardware. A connected infusion pump might see a firmware update twice a year; a SaMD diagnostic platform might deploy weekly. Cybersecurity documentation built as a one-time submission exercise breaks down quickly against that cadence, which is why the FDA's guidance leans so heavily on building these artifacts into an ongoing Secure Product Development Framework rather than a point-in-time deliverable.
The SaMD-specific SBOM problem
A SBOM for embedded firmware is largely a matter of cataloging compiled libraries and their versions. A SaMD SBOM has more layers to account for:
- Application-level dependencies, the libraries and frameworks the application code imports directly.
- Container base images, since most SaMD ships in containers, and the base image itself carries its own dependency tree and vulnerability history.
- Cloud infrastructure components, including managed database services, serverless functions, and message queues that are part of the device's function even though they are not "shipped" in the traditional sense.
- Third-party APIs, particularly any external inference, authentication, or data processing service the SaMD calls, which should be documented with its own security posture even if you cannot get a full SBOM from the provider.
Reviewers increasingly ask SaMD manufacturers to account for all four layers, and a submission that only covers application-level dependencies while ignoring the container and cloud layer draws deficiencies. Identifiers matter here too: without PURLs or CPEs tied to container images and cloud service versions, automated CVE matching for the full stack is not possible.
Threat modeling for SaMD
Threat modeling for SaMD needs to account for the distributed nature of the architecture. Attack surfaces to consider explicitly include the application programming interface layer, authentication and authorization boundaries between the SaMD and any connected EHR or clinical system, the multi-tenancy model if the SaMD is cloud-hosted and serves multiple customers from shared infrastructure, and the software supply chain for any machine learning model or dataset the SaMD depends on if it uses adaptive algorithms.
A common gap is treating the threat model as complete once it covers the application code, without extending the analysis to the identity and access management layer that governs who can reach the SaMD's clinical data and functions. For cloud-hosted SaMD, misconfigured access controls are a more realistic attack path than a novel application-layer exploit, and the threat model should reflect that reality.
Predetermined Change Control Plans for adaptive SaMD
SaMD with algorithms that update frequently, particularly machine learning-based SaMD, can use a Predetermined Change Control Plan (PCCP) to pre-authorize a defined range of future modifications without triggering a new submission for each one. A PCCP needs to explicitly address the cybersecurity implications of the anticipated changes, including how each change type will be evaluated against the existing threat model and whether it affects the SBOM. Building the PCCP's cybersecurity section in coordination with the algorithm change protocol, rather than as an afterthought, is what makes a PCCP defensible on review.
Postmarket monitoring for a boundary you do not fully control
SaMD postmarket monitoring has to track vulnerabilities across layers the manufacturer does not directly control: the container base image, the cloud provider's infrastructure, and any third-party API dependency. This does not remove the manufacturer's responsibility. A CVE affecting your base image or cloud provider is still your problem to triage and, if it affects your device's risk profile, to remediate or accept with documented rationale, even though you did not write the vulnerable code.
An effective postmarket program for SaMD combines automated SBOM-to-CVE matching across all four dependency layers, a defined SLA for triage once a new vulnerability is identified, and a coordinated vulnerability disclosure process that accounts for the faster patch cycle SaMD generally supports compared to embedded firmware.
SaMD versus embedded device cybersecurity requirements
| Dimension | Embedded hardware device | SaMD |
|---|---|---|
| SBOM scope | Firmware, compiled libraries | Application code, container images, cloud services, third-party APIs |
| Update cadence | Periodic, often infrequent | Frequent, sometimes continuous |
| Attack surface boundary | Defined by hardware and firmware | Extends into cloud and identity infrastructure |
| Change management tool | Design change process | PCCP well suited for adaptive algorithms |
| Postmarket monitoring dependencies | Component CVEs | Component, container, cloud provider, and API CVEs |
| Multi-tenancy risk | Rarely applicable | Common consideration for cloud-hosted SaMD |
Common pitfalls in SaMD cybersecurity submissions
The most frequent gap is an SBOM that stops at the application layer and ignores the container and cloud infrastructure the SaMD actually runs on. The second is a threat model that treats identity and access management as an IT concern rather than a medical device security concern, despite access control misconfiguration being one of the more realistic attack paths for cloud-hosted clinical software. The third is a postmarket monitoring plan that assumes a hardware-device patch cadence, describing quarterly reviews for a product that actually deploys weekly, which understates the manufacturer's own operational capability and can create a documentation-versus-practice mismatch that reviewers notice.
How Blue Goat Cyber approaches SaMD cybersecurity requirements
We build the SBOM to cover all four dependency layers, application code, container images, cloud infrastructure, and third-party APIs, so the postmarket monitoring plan actually has complete data to work from. Our threat modeling for SaMD explicitly includes the identity and access management boundary and any multi-tenancy considerations for cloud-hosted products, not just the application programming interface surface. Where a SaMD's algorithm updates frequently, we help build the cybersecurity section of a Predetermined Change Control Plan so the manufacturer is not resubmitting for every model refresh. Ongoing monitoring across the full stack is available through FDA Postmarket Cybersecurity Services, and the premarket package, including SBOM generation, threat modeling, and testing, is delivered through FDA Premarket Cybersecurity Services.
FAQ
Does SaMD need an SBOM if it has no hardware component?
Yes. The SBOM requirement under Section 524B is not tied to hardware; it applies to any cyber device, and SaMD qualifies whenever it has connectivity or the technical capability to connect. The SBOM needs to cover application dependencies, container base images, cloud infrastructure components, and third-party API dependencies.
Is cloud-hosted SaMD held to the same cybersecurity standard as embedded devices?
Yes, the statutory requirement under Section 524B is the same. What differs is the technical scope of the documentation, since a cloud-hosted SaMD's attack surface extends into infrastructure the manufacturer may not fully control, including the cloud provider's services and any third-party APIs, all of which need to be accounted for in the SBOM and threat model.
Can I use a Predetermined Change Control Plan for a machine learning-based SaMD?
Yes, and it is one of the primary use cases the FDA's PCCP framework was designed for. A PCCP that clearly defines the anticipated range of algorithm modifications, along with how each change type will be evaluated against the existing threat model and SBOM, can let you implement pre-authorized updates without a new submission for each change.
How often does the SBOM need to be updated for SaMD?
The SBOM should be regenerated on every build that reaches production, which for actively developed SaMD may mean weekly or more frequently. Postmarket monitoring should match components against CVE feeds on a similarly frequent cadence, since the value of an SBOM depends on it reflecting the software actually deployed.
Do third-party cloud services need to be included in a SaMD SBOM?
Yes, where those services are part of the device's function, such as managed databases, serverless compute, message queues, or external inference APIs. You may not be able to get a full component-level SBOM from every provider, but you should document the dependency, its role, and available security information about the service.
Where this fits in the cluster
- Section 524B Cybersecurity Requirements Explained
- FDA PCCP Change Control Plans
- SBOM for Medical Devices
- SBOM Vulnerability Management for Medical Devices
- Cybersecurity for IVD Devices - how 524B applies to clinical analyzers and point-of-care platforms.
- GMLP Controls Crosswalk for Medical Devices - for machine learning-enabled SaMD.
- EU AI Act vs FDA AI/ML Cybersecurity - for AI-enabled SaMD sold in both markets.
Related from Blue Goat Cyber
- FDA Premarket Cybersecurity Services
- FDA Postmarket Cybersecurity Services
- FDA-Compliant SBOM Services for MedTech
Sources & primary references
- Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
- Software as a Medical Device (SaMD) (FDA)
- Section 524B of the FD&C Act
- The Minimum Elements For a Software Bill of Materials (NTIA)
- ANSI/AAMI SW96:2023, Medical Device Security
- Predetermined Change Control Plans for Machine Learning-Enabled Device Software Functions (FDA)
If your SaMD's SBOM, threat model, or change control plan needs to catch up with how fast you actually ship, our team can build the full package to match your real deployment cadence. Talk to Blue Goat Cyber about your SaMD cybersecurity requirements.
Sources & references
Primary sources cited in this article. Links open in a new tab.
