SaMD Cybersecurity FDA Requirements: A Compliance Guide

Software as a Medical Device (SaMD) has no hardware perimeter. This guide is the SaMD-specific cybersecurity playbook — what changes when your "device" is a cloud service or a mobile app, how Section 524B applies to software-only products, and how IEC 82304-1 and EU MDR Rule 11 fit alongside FDA expectations.

Most cybersecurity guidance is written for connected hardware. SaMD breaks those assumptions: there is no enclosure to harden, no firmware to sign, no service technician with a USB debug port. The threat surface lives in your cloud tenancy, your CI/CD pipeline, your mobile app store distribution, and the third-party APIs you depend on. This guide focuses only on what is different for SaMD — for shared SPDF, SBOM, and submission mechanics, see the linked pillars.

What Counts as SaMD (and Why It Matters for Cybersecurity)

IMDRF defines SaMD as software intended for medical purposes that performs those purposes without being part of a hardware medical device. That includes cloud-hosted diagnostic algorithms, mobile apps that interpret physiologic data, and AI/ML triage tools.

Cyber implication: the FDA Section 524B definition of a "cyber device" turns on whether the device contains software validated, installed, or authorized by the sponsor and is capable of connecting to the internet. Almost every modern SaMD qualifies. Your premarket submission therefore requires the full Section 524B package — SBOM, vulnerability management plan, secure design documentation, and patchability evidence — even though no hardware is shipped.

SaMD vs. SiMD: The Cybersecurity Delta

The SaMD/SiMD split is not a marketing label — it changes the trust boundary and the patch cadence reviewers expect, which together drive every other deliverable in your submission.

Dimension	SiMD (software in a device)	SaMD (software-only)
Trust boundary	Device enclosure + firmware signing	Cloud tenancy + identity provider + app store binary
Update mechanism	Signed firmware over BLE/USB/cellular	CI/CD pipeline → container registry / app store
Patch cadence reviewers expect	Quarterly or per release	Continuous, with documented change control
Pen test scope	Hardware + RF + firmware + companion app	Web app + API + mobile + cloud config + IAM
Primary safety risk	Therapy alteration, alarm suppression	Misclassification, delayed diagnosis, fleet-wide algorithm drift

Who Owns What: SaMD Responsibility Split

Reviewers increasingly ask SaMD sponsors to name the responsible party for every control. Cloud and app-store dependencies do not transfer accountability — they transfer execution. Use this split as your starting RACI; it is the single most common gap we see in SaMD submissions.

Responsibility	Manufacturer (you)	Cloud / platform provider	Operating organization (hospital, clinic, patient)
Secure design, threat model, SBOM	Owns end-to-end	Provides shared-responsibility matrix only	None
Identity, authn/authz, session management	Owns app-layer config and federation	Provides IdP primitives	Manages user provisioning and MFA enforcement
Tenancy isolation and data segregation	Owns logical isolation (RLS, key separation)	Provides physical/network isolation	None
Patch and CVE remediation SLA	Owns SLA, deployment, and evidence	Patches underlying platform	Accepts continuous updates per labeling
Logging, monitoring, incident detection	Owns app + audit telemetry	Provides infra logs	Forwards relevant SIEM events if integrated
Operating environment assumptions (per IEC 82304-1)	Defines and labels	None	Maintains browser, OS, network controls as labeled
Coordinated Vulnerability Disclosure intake	Owns intake, triage, and notification	None	Reports findings via your CVD channel
AI/ML model integrity and drift monitoring	Owns under PCCP	Provides MLOps primitives only	None

Why this matters in the submission: every row above must map to a specific document in your DHF — architecture diagram, security risk file, labeling, or postmarket plan. "AWS handles it" is a deficiency, not a control.

The Standards Stack You Actually Need

FDA reviewers expect SaMD sponsors to map evidence to a specific set of standards. Several differ from the SiMD stack:

• IEC 82304-1 — Health software — Part 1: General requirements for product safety. The SaMD-specific equivalent of IEC 60601 for hardware. Reviewers cite it for software-only products to establish that you considered the operating environment, intended use, and accompanying documentation as part of the safe product.
• IEC 62304 — Software lifecycle. Still applies. Your SOUP analysis becomes the backbone of your SBOM narrative.
• AAMI SW96 / AAMI TIR57 — Security risk management. Required regardless of hardware.
• IEC 81001-5-1 — Health software security activities across the lifecycle. Particularly important for SaMD because it explicitly covers cloud and update infrastructure.
• NIST SP 800-218 (SSDF) — Secure software development. FDA increasingly cites SSDF practices as evidence of a real SPDF.
• OWASP ASVS / MASVS — Use these to scope the pen test and to give reviewers a concrete control catalog. SiMD pen tests rarely cite ASVS; SaMD pen tests should.

EU MDR Rule 11: The European SaMD Trap

If your SaMD is also CE-marked, Rule 11 of MDR Annex VIII will likely push it from Class I (under the old MDD) up to Class IIa, IIb, or III. Class IIb and III SaMD require Notified Body review, and the Notified Body will look for cybersecurity evidence aligned to MDCG 2019-16, which references IEC 81001-5-1 and IEC TR 60601-4-5. The same SBOM and security risk file that satisfies FDA Section 524B will satisfy MDCG 2019-16 with minor formatting adjustments. Build the evidence once, label it for both jurisdictions.

Threats That Are Specific to SaMD

Generic threat lists miss the SaMD-specific scenarios reviewers want addressed:

1. Cloud tenancy compromise — IAM misconfiguration, leaked service-account keys, or supply-chain attack on a CI/CD plugin.
2. Algorithm drift / adversarial inputs — particularly relevant under FDA's PCCP framework for AI/ML SaMD.
3. Mobile app side-loading and tampering — repackaged binaries with the same name and icon. Address with code signing, integrity checks, and certificate pinning.
4. Multi-tenant data leakage — row-level security failures that expose one customer's PHI to another. Reviewers want segmentation evidence, not "we use AWS."
5. Dependency confusion / typosquatting — malicious packages published under a name similar to one in your SBOM. CycloneDX VEX statements should explicitly cover this.
6. OAuth / SSO redirection abuse — particularly relevant when your SaMD federates with EHR identity providers.

Premarket Submission: What's Different for SaMD

The Section 524B package is the same in structure, but several deliverables need a SaMD-specific framing:

• Architecture views — include the cloud reference architecture (VPC, subnets, IAM boundaries, KMS, logging) as a first-class diagram. Reviewers will not accept "hosted on AWS" as architecture documentation.
• SBOM — include both the application SBOM and the container base image SBOM. Document build provenance (SLSA level if you can claim it).
• Patchability — describe your CI/CD pipeline, change control, and the maximum time from CVE disclosure to deployed patch. SaMD reviewers expect days-to-weeks, not the months SiMD can justify.
• Pen test — scope must include web app, API, mobile (if applicable), and cloud configuration review. A SiMD-style network/RF test is not sufficient and will draw a deficiency.
• Operating environment assumptions — per IEC 82304-1, document the user organization's responsibilities (browser version, OS patch level, network controls). These become labeling requirements.

Postmarket: Continuous Monitoring Is the Default

For SiMD, postmarket monitoring often means a quarterly vulnerability review. For SaMD, the FDA expects continuous monitoring because you control the production environment:

• Runtime application self-protection (RASP) or equivalent telemetry
• Cloud security posture management (CSPM) drift alerts
• Dependency monitoring tied to your SBOM
• A documented SLA from CVE disclosure to deployed patch
• Coordinated Vulnerability Disclosure intake (see our CVD page)

If your SaMD includes AI/ML, your PCCP (Predetermined Change Control Plan) must explicitly cover security-relevant model updates, not just performance changes.

Frequently asked questions

Does SaMD require an SBOM under FDA Section 524B?

Yes. If your SaMD connects to the internet (almost all do) and you authorize, install, or maintain the software, it is a cyber device under Section 524B. SBOM is mandatory in the premarket submission and must be maintained postmarket.

Is IEC 82304-1 required by the FDA?

It is not formally recognized by the FDA the way IEC 62304 is, but reviewers cite it as best practice for SaMD-specific topics (operating environment, accompanying documentation, decommissioning). Mapping evidence to IEC 82304-1 strengthens the submission and is required for EU MDR.

How does Section 524B treat a mobile app that is SaMD?

Identically to a cloud-hosted SaMD. The mobile binary is part of the device; you owe SBOM, threat model, and pen test coverage of the mobile app, plus its backend APIs.

Is penetration testing required for SaMD FDA clearance?

For any internet-connected SaMD, yes — and it must cover web/API/mobile and cloud configuration. A network-only or RF-only test (the SiMD default) will draw a deficiency.

What scope of pen test do reviewers expect for cloud-hosted SaMD?

Authenticated and unauthenticated testing of all production-equivalent endpoints, mobile binary analysis if applicable, IAM and cloud configuration review, and a tenancy isolation test if multi-tenant. Map findings to OWASP ASVS / MASVS and the SBOM.

How does EU MDR Rule 11 change my SaMD cybersecurity evidence?

Classification typically rises (often to IIa or IIb), triggering Notified Body review against MDCG 2019-16. The technical evidence overlaps heavily with FDA Section 524B; build once, file twice with appropriate cover documents.

Where this fits in the cluster

• The SPDF Playbook for FDA-Ready Medical Devices
• FDA 524B Cybersecurity Requirements Explained
• The MedTech Cybersecurity Standards Decoder
• SBOM Vulnerability Management for Medical Devices
• STRIDE Threat Modeling for Medical Devices

Related from Blue Goat Cyber

• AI/ML Medical Device Security
• FDA Premarket Cybersecurity Services
• Medical Device Penetration Testing
• FDA-Compliant SBOM Services

Sources & primary references

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions — FDA
• Software as a Medical Device (SaMD): Key Definitions and Framework — IMDRF
• IEC 82304-1: Health software — General requirements for product safety — IEC
• MDCG 2019-16: Guidance on Cybersecurity for medical devices — European Commission MDCG
• NIST SP 800-218 Secure Software Development Framework — NIST

Talk to a SaMD cybersecurity team

We ship FDA-ready cybersecurity packages for cloud-hosted, mobile, and AI/ML SaMD across 510(k), De Novo, and EU MDR. Book a discovery session and we will walk your architecture and evidence with you.