Medical Device Cybersecurity: FDA Guidance, SBOMs, and Threat Modeling

Medical device cybersecurity is no longer a checkbox in a premarket submission. Since the PATCH Act added Section 524B to the Federal Food, Drug, and Cosmetic Act, the FDA can refuse to accept any cyber device submission that lacks a threat model, an SBOM, and a vulnerability management plan. They started issuing those refusal letters in October 2023. After October 2025, the RTA policy expanded to cover incomplete SBOMs specifically.

For ContourCompanion, a Class II AI SaMD processing DICOM CT data on AWS, the cybersecurity package was the second-largest section of the 510(k) submission after the risk management file. The threat model was one of the largest individual documents in the package. The SBOM listed hundreds of dependencies down to transitive packages, in machine-readable CycloneDX format, with known CVEs assessed and dispositioned.

This post covers how we structured the cybersecurity documentation that FDA reviewers expect, the specific tools and standards behind it, and where teams building cloud-deployed SaMD get tripped up.

FDA Cybersecurity Guidance and Section 524B

The FDA's cybersecurity guidance for medical devices has gone through three major revisions. The original 2014 guidance was seven pages. The current version, finalized in June 2025 as "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions", runs to over 50 pages and supersedes both the 2023 final and the March 2024 "Select Updates" draft.

The 2025 guidance eliminates a common misconception: if a device contains software or is itself software, it is a "cyber device." There is no exemption for devices that are not network-connected. SaMD is always a cyber device.

Section 524B defines a cyber device as one that (1) includes software validated, installed, or authorized by the sponsor, (2) has the ability to connect to the internet, and (3) contains technological characteristics vulnerable to cybersecurity threats. Every cloud-deployed SaMD meets all three criteria.

The required cybersecurity documentation for a premarket submission:

Document	What FDA Expects
Threat model	Threats, attack vectors, threat actors, likelihood, mapped to device architecture
Security architecture	Data flow diagrams with protocols, encryption methods, authentication mechanisms
SBOM	Machine-readable, per NTIA minimum elements, all components with known vulnerabilities
Vulnerability assessment	CVE analysis of every SBOM component with planned mitigations
Penetration testing	Security testing results against identified attack surfaces
Patch/update plan	Post-market vulnerability response, update mechanism, end-of-support timeline
Security risk management	Cybersecurity risks integrated into the device risk management process

Missing any of these triggers an RTA. The FDA is not bluffing: making it a "prohibited act" to fail to comply with Section 524B means the government can pursue criminal prosecution or injunctive relief against non-compliant companies.

The transition from discretionary to statutory is the key change. Before the PATCH Act, cybersecurity was guidance. Now it is law. The FDA's RTA checklist treats cybersecurity documentation the same as predicate device comparison or biocompatibility data: if it is missing, the submission does not enter substantive review.

IEC 81001-5-1: The Cybersecurity Lifecycle Standard

IEC 81001-5-1:2021 is the cybersecurity lifecycle standard tailored for health software. The FDA added it to its recognized consensus standards list in late 2022, and it serves as an accepted Secure Product Development Framework (SPDF) per the FDA cybersecurity guidance.

The standard defines 64 cybersecurity requirements across six domains: quality management, security risk management, secure development, maintenance, configuration management, and issue resolution. It is adapted from IEC 62443-4-1 (the industrial control system secure development lifecycle standard) with health software specifics added.

For ContourCompanion, IEC 81001-5-1 provided the framework that tied everything together. The IEC 62304 software lifecycle defined what we built and how. IEC 81001-5-1 defined how we secured it. The two standards share vocabulary and lifecycle phases, which made integration straightforward: security requirements traced alongside functional requirements, security testing ran alongside functional testing, and vulnerability management plugged into the existing change control process.

Global adoption is accelerating. Japan made IEC 81001-5-1 mandatory in April 2024. The EU planned harmonization under MDR but postponed to May 2028. Notified Bodies already advise implementing it as "state of the art" regardless. If you are building SaMD for international markets, IEC 81001-5-1 compliance is effectively required everywhere, just on different timelines.

Threat Modeling with STRIDE for Medical Devices

The FDA recommends STRIDE as the methodology for structured threat identification. STRIDE maps six categories of threats to specific attack patterns:

Category	Threat	SaMD Example
Spoofing	Impersonating a user or system	Forged clinician credentials accessing diagnostic output
Tampering	Unauthorized data modification	Altering DICOM inputs or algorithm parameters
Repudiation	Denying an action occurred	Untracked modifications to patient contour data
Information Disclosure	Exposing protected data	PHI leakage through API responses or logs
Denial of Service	Disrupting availability	Overloading the contouring inference pipeline
Elevation of Privilege	Gaining unauthorized access	Exploiting an admin endpoint to modify OAR configurations

The threat model must cover three levels of depth: system level (overall architecture, trust boundaries), subsystem level (individual services, APIs, communication interfaces), and component level (specific libraries, container images, firmware).

For ContourCompanion's HIPAA-compliant AWS architecture, the threat model mapped every data flow from DICOM ingestion through inference to RT Structure Set delivery. Each trust boundary crossing (VPC boundaries, service-to-service calls, external API endpoints) was a potential attack surface. The same infrastructure decisions, VPC endpoints, private subnets, KMS encryption, CloudTrail logging, served double duty as STRIDE mitigations. Encryption in transit covers Information Disclosure. IAM role-based access covers Elevation of Privilege. Immutable audit logging covers Repudiation. The cybersecurity submission reframed existing infrastructure controls as threat mitigations, with traceability from each STRIDE category to the specific AWS resource enforcing it.

The FDA requires two separate but linked risk assessments:

1. Safety risk assessment: patient harm focus, aligned with ISO 14971
2. Security risk assessment: cybersecurity threat focus, aligned with NIST CSF and IEC 62443

Security risks that could lead to patient safety hazards transfer into the ISO 14971 risk management file. A tampering attack that alters contouring algorithm inputs is a security risk. The resulting incorrect radiation therapy contour is a safety hazard. Both must be documented, traced, and controlled. AAMI TIR57:2016 provides the framework for maintaining this dual-track approach.

SBOM Requirements for FDA Medical Device Submission

The SBOM requirement is where most teams underestimate the scope. Section 524B mandates a Software Bill of Materials for every cyber device submission. "Software Bill of Materials" sounds like a dependency list, and teams assume npm list or pip freeze is sufficient. It is not.

FDA-compliant SBOMs must follow the NTIA Minimum Elements standard and be provided in a machine-readable format: CycloneDX or SPDX, in JSON or XML. A text file listing package names does not qualify.

The required SBOM scope goes well beyond a typical dependency manifest:

• All first-party and third-party components
• Commercial, open-source, and off-the-shelf software
• Software level of support and end-of-support dates for each component
• Linked to every build release
• Integrated into change control processes

For a cloud-deployed SaMD, the SBOM extends to the container image layer: OS packages, system libraries, and transitive dependencies that never appear in your application's package manager. ContourCompanion's SBOM included the Python runtime, NumPy, PyTorch, CUDA libraries, the base OS packages in the container image, and dozens of transitive dependencies. It also included a UPenn graphics library from the original research codebase, a dependency that no vulnerability database tracks. That is exactly the kind of component that trips up teams relying on automated scanning alone: if it is not in NVD, your tooling will not flag it, but the FDA still expects it listed with a supplier, version, and support status.

The FDA accepts SBOMs in CycloneDX or SPDX format. Both must be machine-readable (JSON or XML). Tools like Syft generate either format from container images and filesystems.

SBOM Vulnerability Management Workflow

Generating the SBOM is step one. The ongoing vulnerability management workflow is where the real operational cost lives:

1. Generate at build time: SBOM produced as a CI artifact on every build, capturing all direct and transitive dependencies
2. Scan against vulnerability databases: NVD, OSV, GitHub Advisory Database. We used Amazon ECR image scanning and Amazon Inspector for automated scanning on every image push and on a continuous schedule
3. Score each vulnerability: CVSS v3.1 or v4.0 severity bands (Critical 9.0-10.0, High 7.0-8.9, Medium 4.0-6.9, Low 0.1-3.9)
4. Assess exploitability in your product context: is the vulnerable function called? Is the attack vector accessible? Are mitigating controls present?
5. Document in VEX: publish status for each assessed vulnerability with justification for "Not Affected" determinations
6. Remediate: patch, update, apply compensating controls, or document risk acceptance with justification
7. Monitor continuously: automated alerts when new CVEs affect SBOM components, re-assess and update VEX documents

This workflow ran continuously post-clearance. New CVEs against PyTorch or CUDA dependencies triggered automated alerts. CISA, NVD, and MITRE feeds were monitored for anything touching the SBOM. Each alert followed the same assess-document-remediate cycle.

Medical Device Security Testing

The FDA expects a multi-layered testing approach. A single penetration test report is not sufficient. The guidance calls for four distinct methodologies:

SAST (Static Application Security Testing) analyzes source code for vulnerabilities without executing the application: injection flaws, hardcoded credentials, insecure cryptographic usage. Runs in CI on every commit.

DAST (Dynamic Application Security Testing) tests the running application from an external perspective: authentication flaws, session management issues, server configuration errors. Complements SAST by finding vulnerabilities that only manifest during execution.

SCA (Software Composition Analysis) identifies known vulnerabilities in third-party and open-source components. Directly supports SBOM maintenance. The FDA expects SCA alongside SAST in premarket submissions.

Penetration testing simulates real-world attack scenarios against identified attack surfaces. Validates that the security controls from the threat model actually work under adversarial conditions.

For ContourCompanion, SAST and SCA ran in the CI pipeline on every pull request. DAST ran against the staging environment on every deployment. Penetration testing was performed against the production-equivalent environment before the 510(k) submission and repeated annually.

Container images were scanned automatically by Amazon ECR image scanning, which checks for CVEs in OS packages and application dependencies on every push to the registry. ECR's enhanced scanning, powered by Amazon Inspector, provided continuous monitoring of deployed images, catching newly published CVEs against images already in production. ClamAV scanned container images for malware as an additional layer. These scans fed directly into the SBOM vulnerability management workflow: a critical CVE flagged by ECR or Inspector triggered the same assess-document-remediate cycle as any other vulnerability source.

Security testing documentation must demonstrate traceability between test results, identified vulnerabilities, risk mitigations, and design controls. Findings trace back to the threat model. Remediations trace forward to verified controls in the risk management file. The documentation standards align with ISO 13485 (quality management) and ISO/IEC/IEEE 29119-3 (test documentation).

Cloud Infrastructure as Attack Surface

Cloud-deployed SaMD introduces attack surfaces that traditional on-premise medical device software does not have. The threat model must account for the shared responsibility model: AWS secures the infrastructure, you secure everything you deploy on it.

The infrastructure as code approach directly supports the cybersecurity submission. Every security control is codified, tested, and auditable. When the FDA asks "how do you enforce encryption at rest," the answer is a CDK construct with a cdk-nag HIPAA rule that prevents deployment without it. When they ask "how do you detect unauthorized configuration changes," the answer is AWS Config rules with automated drift detection.

Specific cloud security controls the FDA expects to see documented:

• Network isolation: VPC architecture, security groups, network ACLs, private subnets for PHI-processing services
• Encryption: KMS-managed keys for data at rest, TLS 1.2+ for data in transit, certificate management
• Access control: IAM policies, role-based access, MFA enforcement, session duration limits
• Audit logging: CloudTrail with integrity validation, VPC Flow Logs, application-level audit trails
• Incident response: break-glass procedures, automated alerting, documented escalation paths

These overlap heavily with HIPAA technical safeguards. A well-architected HIPAA-compliant infrastructure handles most of the cybersecurity requirements simultaneously. The difference is framing: HIPAA documentation describes controls in terms of PHI protection, while the cybersecurity submission describes the same controls as attack surface mitigations, referencing the threat model and STRIDE categories.

The practical consequence: if you architect for HIPAA first (as we did for ContourCompanion), the cybersecurity submission is largely a re-documentation exercise rather than new engineering work. The controls already exist. The submission maps them to threats instead of to HIPAA safeguards. Teams that skip HIPAA architecture and try to bolt on cybersecurity controls at submission time face a much harder problem.

Frequently Asked Questions

What is Section 524B of the FD&C Act?

Section 524B, added by the PATCH Act (Section 3305 of the Consolidated Appropriations Act, 2023), requires manufacturers of "cyber devices" to submit cybersecurity documentation with premarket submissions, including a threat model, SBOM, vulnerability management plan, and patch/update procedures. It became effective March 29, 2023, with FDA RTA enforcement beginning October 2023. Non-compliance is a prohibited act under the FD&C Act.

What SBOM format does FDA require?

The FDA accepts SBOMs in CycloneDX, SPDX, or SWID tag formats. The SBOM must be machine-readable (JSON or XML), follow the NTIA Minimum Elements standard, and include all software components (commercial, open-source, off-the-shelf) with version numbers, supplier information, dependency relationships, and known vulnerabilities. CycloneDX offers native VEX integration for vulnerability disposition documentation.

Is IEC 81001-5-1 required by the FDA?

IEC 81001-5-1 is not strictly required, but the FDA recognizes it as a consensus standard and accepts it as a Secure Product Development Framework (SPDF) per the cybersecurity guidance. Using IEC 81001-5-1 streamlines the submission because reviewers understand the framework. Japan made it mandatory in April 2024, and EU harmonization is planned for May 2028.

What are the FDA cybersecurity requirements for medical devices?

The FDA expects SAST (static code analysis), DAST (dynamic testing of running applications), SCA (software composition analysis for third-party vulnerabilities), and penetration testing. Results must be traceable to the threat model: each test addresses specific identified threats, and each finding maps to a risk mitigation. Testing documentation should align with ISO 13485 and ISO/IEC/IEEE 29119-3.

References

• FDA Cybersecurity in Medical Devices Guidance (2025)
• Section 524B — Consolidated Appropriations Act, 2023
• IEC 81001-5-1:2021 — Health Software Security
• NTIA Minimum Elements for SBOM
• AAMI TIR57:2016 — Medical Device Security Risk Management
• CycloneDX SBOM Standard
• SPDX SBOM Standard
• Amazon ECR Image Scanning
• Amazon Inspector
• Syft — SBOM Generator
• NIST SP 800-30 — Guide for Conducting Risk Assessments
• FDA Recognized Consensus Standards
• Black Duck: Understanding FDA Section 524B
• SBOMify: FDA Medical Device SBOM Requirements