FDA Cybersecurity Guide: SBOM, Threat Models and Submission Evidence

Section 524B defines a cyber device using three criteria: the device includes software authorized by the sponsor; can connect to the internet; and contains technological characteristics that could be vulnerable to cybersecurity threats. FDA’s guidance interprets internet connectivity broadly enough to require careful review of direct, indirect, temporary and configurable connections.

Document the released architecture, deployment variants, cloud services, mobile applications, update mechanisms, maintenance ports and third-party dependencies. A marketing statement that a device is “offline” does not resolve a Wi-Fi service mode, USB update path or connected companion application.

Even when section 524B does not apply, cybersecurity can remain relevant to the reasonable assurance of safety and effectiveness. The security work should be proportionate to exploitability, clinical consequences, exposure, recoverability and lifecycle support—not reduced to a binary statutory label.

Create a system-context view and data-flow diagrams showing external entities, interfaces, protocols, assets, trust boundaries, privilege changes and security-relevant data stores. Identify assumptions such as hospital-network controls or user authentication and state whether the device verifies those assumptions.

Then apply a structured method—such as STRIDE, attack trees or misuse cases—to each attack surface. Record threat scenario, preconditions, affected asset, potential security and patient harm, existing controls, residual risk and verification evidence. Method labels matter less than systematic coverage and traceability.

Connect security risk to safety risk where compromise can create a hazardous situation, while preserving security properties that may not map neatly to physical harm. Confidentiality, integrity and availability should all be addressed. Document exploitability assumptions rather than treating likelihood as unknowable or automatically remote.

FDA recommends an SBOM covering commercial, open-source and off-the-shelf components. For cyber devices, section 524B requires an SBOM including commercial, open-source and off-the-shelf software components. The inventory should use stable component identity and version information, identify support status and enable matching against vulnerability sources.

Scanner output is not a finished SBOM. Normalize duplicates, resolve package aliases, account for statically linked and transitive components, verify the shipped build and define how firmware, containers, cloud services and mobile clients are represented. Preserve the relationship between the SBOM and the exact device release.

For known vulnerabilities, record applicability, exploitability, compensating controls, patient impact and disposition. A high severity score does not automatically mean unacceptable device risk, and “not affected” needs technical rationale. Unsupported components require an explicit replacement, isolation or monitoring strategy.

Design controls around secure authentication, authorization, least privilege, cryptography and key management, integrity, secure update, logging, resilience, recovery and secure defaults. Describe control allocation across the device, cloud, user and deployment environment, especially where safety depends on an external control.

Verification should combine requirements-based tests, code and configuration analysis, vulnerability scanning, abuse-case testing, fuzzing where appropriate and independent penetration testing. Define test scope, build, environment, tester competence, findings, remediation and retest. Explain residual anomalies rather than presenting a clean executive summary without evidence.

Trace each material threat to one or more controls and each control to implementation and verification. This lets an FDA reviewer distinguish an accepted residual risk from an accidentally untested security requirement.

Section 524B requires plans to monitor, identify and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure, plus processes and procedures to provide reasonable assurance that the device and related systems are cybersecure and to make postmarket updates and patches available.

Describe intake channels, triage, vulnerability intelligence, impact assessment, escalation, remediation targets, disclosure coordination, customer communication, update delivery and effectiveness monitoring. Define support periods and how users are informed when components or devices approach end of support.

The submission should align with quality-system procedures and design records. A polished plan that engineering cannot execute is weak evidence. Demonstrate the process with current component monitoring, representative patch testing and clear ownership across product security, safety, quality and regulatory functions.