FDA Cybersecurity Premarket (Section 524B)

Section 524B amends the FD&C Act to require that any premarket submission for a 'cyber device' include cybersecurity information. It is not a guidance; it is a statute, and a submission missing the required cybersecurity content is refused-to-accept (RTA) by FDA at the door.

A 'cyber device' is defined as a device that (1) includes software validated, installed or authorised by the sponsor, (2) has the ability to connect to the internet, and (3) contains technological characteristics validated, installed or authorised by the sponsor that could be vulnerable to cybersecurity threats. The definition is broad — most devices with embedded software and any network interface (wired Ethernet, Wi-Fi, Bluetooth, cellular) are in scope.

1. A plan to monitor, identify and address (in a reasonable time) post-market cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure.
2. Design, develop and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure — the Secure Product Development Framework (SPDF).
3. Software Bill of Materials (SBOM) — including commercial, open-source and off-the-shelf components.
4. Comply with such other requirements as FDA may require through regulation.

FDA's September 2023 guidance ('Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions') expands each of these into concrete documentation expectations.

The SPDF is the cybersecurity equivalent of the software development lifecycle in IEC 62304. It requires the manufacturer to integrate cybersecurity activities throughout the entire product lifecycle — concept, design, development, verification, validation, release, deployment, maintenance and end-of-life — rather than bolt them on at the end.

• Cybersecurity risk management (linked to ISO 14971 and AAMI TIR57)
• Threat modelling (STRIDE, attack trees, abuse cases)
• Cybersecurity requirements (CIA — confidentiality, integrity, availability — plus authentication, authorisation, auditability)
• Secure design and architecture (defence-in-depth, least privilege, secure-by-default)
• Secure coding and component selection
• Cybersecurity testing (static analysis, dynamic analysis, fuzzing, penetration testing, vulnerability scanning)
• Vulnerability management and patching (SBOM-driven monitoring, coordinated disclosure, patch deployment)
• Secure transfer to manufacturing and secure provisioning

The SBOM is a machine-readable list of every software component in the device — commercial libraries, open-source libraries, operating systems, firmware, drivers — with name, version, supplier and a unique identifier. FDA accepts SPDX or CycloneDX formats. The SBOM must be sufficient to enable the operator (hospital, MSO, end user) to identify vulnerabilities affecting the components.

The SBOM is not a one-shot deliverable. It must be maintained — when a component is updated, the SBOM is updated. Post-market vulnerability management uses the SBOM to triage new CVEs as they are published.

The submission must describe how the manufacturer will monitor for new vulnerabilities (CISA KEV, NVD, vendor advisories, SBOM-driven triage), how it will assess them against the device (exploitability, patient impact), how it will communicate (coordinated vulnerability disclosure per ISO 29147 / 30111), and how it will patch (release cadence, emergency patches, validation of patches).

FDA expects vulnerabilities to be addressed in a 'reasonable time' — generally weeks for critical-severity exploited vulnerabilities, months for medium-severity, and prompt for known-exploited (KEV) entries. The plan must be specific enough to be assessed.

FDA's Predetermined Change Control Plan framework lets manufacturers pre-authorise specified changes that would otherwise require a new submission. For cyber devices, a PCCP can pre-authorise the patching pathway — meaning a cybersecurity patch released within the PCCP's pre-authorised parameters does not require a new 510(k) every time. This is an essential lever for keeping pace with the vulnerability landscape.

FDA began applying the RTA policy on 1 October 2023. A submission for a cyber device that does not contain the four 524B elements (post-market plan, SPDF processes, SBOM, reasonable assurance of cybersecurity) is rejected at the acceptance review and the user-fee clock stops until the submission is corrected. This is a significant disruption — sponsors plan around the RTA bar.

While 524B applies to premarket submissions, FDA's accompanying guidance makes clear that existing marketed cyber devices are subject to post-market vulnerability management expectations under the Quality System Regulation (and the incoming QMSR). Manufacturers cannot ignore CVEs affecting marketed devices on the grounds that 524B only applies to new submissions.

• SBOM produced once and never updated.
• Penetration test treated as the whole cybersecurity package — testing without an SPDF behind it.
• Post-market plan written generically with no commitments on timelines or coordinated disclosure mechanics.
• Open-source components inherited without licence and vulnerability assessment.
• Reliance on hospital network controls as the primary mitigation — FDA expects the device itself to be defensible.
• No PCCP, so every patch becomes a new 510(k).