Article
SaMD Cybersecurity: A 2026 Practitioner Guide
Key takeaways
- SaMD is pure software with a medical purpose; there is no hardware boundary to hide behind, so the entire attack surface is code, dependencies, and the environment the software runs in.
- FDA's 2025 premarket cybersecurity guidance applies to SaMD in full, and CDRH reviewers treat SaMD as higher-scrutiny for supply chain (SBOM), cloud/hosting posture, and update mechanisms.
- Every SaMD threat model has to include the runtime: browser, mobile OS, cloud provider, container image, and any AI/ML inference stack. Omissions here are the most common cybersecurity deficiency.
- Postmarket vulnerability management is not optional for SaMD; the update path is your safety mechanism, and reviewers expect a documented cadence tied to CISA KEV and NVD monitoring.
- Teams that write the Security Risk Assessment alongside the ISO 14971 hazard analysis clear faster than teams that produce a standalone cybersecurity document at the end.
Why this matters
SaMD is the fastest-growing category of medical device, and it is the category where cybersecurity failures translate most directly into patient harm. There is no case housing, no hardware interlock, no physical air gap. Every safety-relevant behavior is enforced in code, and every code path the software depends on, including the operating system, the container runtime, and the AI model weights, is part of the device.
Across the 250+ premarket cybersecurity packages my team at Blue Goat Cyber has supported, the SaMD submissions that clear on first review share a pattern: the cybersecurity documentation is built into the design record, not bolted on. The Security Risk Assessment shares a table with the ISO 14971 hazard analysis. The SBOM is generated by the same CI pipeline that ships the release. The threat model is regenerated whenever the architecture diagram changes. When those artifacts are consistent, the reviewer's job is easy; when they contradict each other, deficiencies follow.
What is Software as a Medical Device (SaMD)?
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 definition comes from IMDRF and is adopted by FDA. Examples include a mobile app that analyzes ECG traces uploaded from a wearable, a web application that segments MRI images for surgical planning, and an AI inference service that flags diabetic retinopathy from fundus photos.
Software embedded inside a hardware medical device (firmware for an insulin pump, for example) is Software in a Medical Device (SiMD), not SaMD, and follows the hardware device's premarket pathway. SaMD is regulated on its own, typically through 510(k), De Novo, or PMA, with cybersecurity documentation submitted under FDA's premarket cybersecurity guidance.
What does the FDA expect in a SaMD cybersecurity submission?
The 2025 FDA premarket cybersecurity guidance applies to SaMD in full. In practice, a SaMD submission has to include: a Security Risk Assessment that ties each threat to a patient harm and to a mitigation in the design, a threat model that covers the software architecture and its runtime environment, an SBOM in an FDA-acceptable format (SPDX or CycloneDX) with a documented monitoring plan, evidence of secure development practices under IEC 62443-4-1 or an equivalent framework, verification results that include cybersecurity testing (vulnerability scanning, penetration testing, and where warranted, fuzz testing), and a postmarket cybersecurity plan.
SaMD gets extra reviewer attention on two axes. First, supply chain: pure-software devices pull in far more third-party code than embedded devices, and the SBOM has to reflect the full transitive dependency graph, including base container images and language runtimes. Second, update path: because there is no hardware component to recall, the software update mechanism is the safety mitigation, and reviewers want to see it documented, verified, and tied to the postmarket plan.
How do you threat model a pure-software device?
A SaMD threat model has to include the software architecture and the runtime environment as first-class citizens. The architecture layer covers the application's own components: authentication, session management, data storage, external integrations, model inference (for AI/ML SaMD), and any user-facing interfaces. The runtime layer covers everything the software depends on to execute: the operating system, the browser or mobile OS, the container image, the orchestration platform, the cloud provider, and the network path between them.
STRIDE remains the workhorse decomposition. Applied to SaMD, the most productive categories are usually Tampering (of input data, model weights, or configuration), Information Disclosure (of PHI in logs, telemetry, or error messages), and Elevation of Privilege (through the cloud identity plane, not just the app). Denial of Service deserves specific attention for SaMD whose intended use is time-sensitive; a segmentation service that returns results five minutes late may be functionally unavailable for the clinical workflow it supports.
Related guide: Threat modeling connected medical devices covers the decomposition method in depth.
What goes in a SaMD SBOM, and how do you keep it clean?
The SaMD SBOM has to enumerate every third-party component the software depends on to execute in its production environment. That includes application dependencies (npm, pip, Maven, NuGet), the language runtime (Node.js, Python, JVM), the container base image and every package layered on top, any sidecar containers, and where the SaMD is delivered as a hosted service, the managed services it depends on for safety-relevant behavior.
The cleanest way to produce a defensible SBOM is to generate it from the build pipeline that produces the release artifact. Trivy, Syft, and cdxgen each emit CycloneDX or SPDX from a container image or source tree. The output has to be regenerated on every release, stored with the release artifact, and monitored against CISA KEV and NVD for the life of the deployed version.
Related guide: SBOM hygiene for medical devices covers format selection, generation, and postmarket monitoring in detail.
How does postmarket vulnerability management work for SaMD?
SaMD postmarket vulnerability management is where the theory of continuous security meets the reality of a regulated device. The plan has to describe: how vulnerability intelligence is ingested (CISA KEV, NVD, GitHub advisories, vendor advisories for the runtime and cloud provider), how it is triaged against the current SBOM, how the exploitability and patient-safety impact are assessed, how patches are validated, and how updates are deployed to the field.
For hosted SaMD, deployment can be nearly continuous, but the change still has to flow through the design control system that governs the device. For patient-side SaMD (a mobile app, a desktop tool), the update path depends on the user or their IT staff, and the postmarket plan has to describe how you drive adoption of security updates, including the timeline after which an unpatched deployment is considered out of specification.
Related guide: Postmarket vulnerability management for connected medical devices covers the operating cadence.
How does AI/ML SaMD change the picture?
AI/ML-enabled SaMD adds three attack surfaces the classical SaMD threat model does not have: the training data pipeline, the model weights, and the inference-time inputs. Poisoned training data can install a persistent misclassification. Tampered model weights can change device behavior without any code change. Adversarial inputs at inference time can cause targeted misclassification without touching the software at all.
AI/ML SaMD also frequently ships with a Predetermined Change Control Plan (PCCP) so the model can be retrained without a new submission. The PCCP has to describe how cybersecurity verification is re-performed for each retraining event, and the SBOM has to include the training and inference stacks (PyTorch, TensorFlow, ONNX runtime, CUDA, and any model-serving framework).
Related guide: FDA Predetermined Change Control Plans (PCCP) covers the PCCP structure and cybersecurity integration.
How do you tie SaMD cybersecurity to the safety case?
The pattern that clears fastest is treating each cybersecurity threat as a hazard in the ISO 14971 risk analysis. The Security Risk Assessment and the hazard analysis share a table: for each threat, the same row names the harm to the patient, the pre-mitigation risk, the mitigation implemented in the design, and the post-mitigation residual risk. When the reviewer opens the safety file, cybersecurity is already there; when they open the cybersecurity file, the safety linkage is already there.
This is the difference between a submission where the reviewer has to reconstruct the connection between a CVE score and a patient impact, and a submission where the manufacturer has already done that work. The first path draws deficiency letters. The second clears.
How Christian approaches this
At Blue Goat Cyber we treat SaMD cybersecurity as an extension of the safety file, not a parallel deliverable. The Security Risk Assessment is a view over the same risk register that drives the ISO 14971 hazard analysis; the SBOM is generated by the release pipeline; the threat model is versioned with the architecture diagram. When the FDA reviewer opens the submission, the cybersecurity story reads as an integrated part of the design, because it is.
The approach is documented across the SaMD chapter of my 2026 book, Medical Device Cybersecurity: An In-Depth Guide. Product leaders return most often to the section that maps each STRIDE category to a concrete SaMD example and a concrete mitigation, because it is the shortest path from framework to submission.
Related guides: What the FDA actually wants in a 2026 premarket cybersecurity submission, SBOM hygiene for medical devices, Threat modeling connected medical devices, Postmarket vulnerability management, and FDA Predetermined Change Control Plans (PCCP).