FDA §524B: the cybersecurity plan without which your submission will be refused

If you target the US market with connected medical software, cybersecurity is no longer a chapter of your file: it is a legal condition of admissibility. Since 2023, the FDA can refuse (“Refuse to Accept”) a submission that does not include the elements required by section 524B of the FD&C Act. Here is what the law says, what the FDA concretely expects, and how to prepare when you come from the European framework.

What is section 524B?

Definition: section 524B of the FD&C Act, introduced in 2023 by the Consolidated Appropriations Act, requires manufacturers of “cyber devices” to demonstrate, from the premarket submission onwards, that they ensure the device’s cybersecurity across its entire life cycle. Unlike FDA guidances, which express recommendations, 524B is a legal requirement: its absence justifies a refusal of the file before the scientific review even begins.

Is your product a “cyber device”?

The law sets three cumulative criteria. A cyber device is any device that:

1. includes software validated, installed or authorised by the manufacturer as a device or in a device;
2. has the ability to connect to the internet;
3. contains technological characteristics that could be vulnerable to cybersecurity threats.

In practice, every modern SaMD ticks all three boxes: a mobile app with a backend, a device with remote maintenance, an algorithm served by API. The question is not “am I concerned?” but “what do I have to produce?”.

What are the 4 legal requirements?

524B imposes four obligations, to be documented in the submission:

1. A plan to monitor and address vulnerabilities: how you monitor, identify and address post-market vulnerabilities and exploits, including coordinated vulnerability disclosure (CVD) and the associated procedures.
2. Processes providing reasonable assurance that the device and its systems are secure, with post-market updates and patches: on a regular cycle for known vulnerabilities, and out of cycle, as soon as possible, for critical vulnerabilities being actively exploited.
3. An SBOM (Software Bill of Materials) covering commercial, open-source and off-the-shelf components — the CycloneDX format is a common, well-tooled choice.
4. Compliance with any other requirement the FDA imposes by regulation to demonstrate reasonable cybersecurity assurance.

524B does not ask for an invulnerable product. It asks for proof that you will know how to react when a vulnerability appears — because it will appear.

What does the FDA premarket guidance ask for?

The guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions”, published in September 2023 and then updated in 2025, details the expected content of the file. The structuring blocks:

• A Secure Product Development Framework (SPDF): security built into design, development and maintenance — the spirit is very close to IEC 81001-5-1.
• A documented threat model covering the device and its system (app, backend, updates, interfaces).
• A cybersecurity risk analysis distinct from the patient-safety risk analysis, with the link between the two.
• Security testing: static and dynamic analysis, robustness/fuzz testing, penetration testing, with reports.
• The SBOM accompanied by each component’s support level and end of life.
• Security architecture views: data-flow diagrams, interfaces, authentication and encryption mechanisms.
• A post-market vulnerability management plan aligned with the four legal obligations.

What differences with the European approach?

If you are already compliant with MDR + IEC 81001-5-1, you have a solid base, but not an equivalence:

The structuring point: one and the same technical base — threat model, SBOM, vulnerability management, security testing — feeds both files. What diverges is the documentary packaging and the level of detail required on the post-market side. Build the base once, adapt it per market.

An 8-point preparation checklist

1. Formally rule on the “cyber device” qualification of your product, in writing, criterion by criterion.
2. Generate an automated SBOM (CycloneDX) on every build, including transitive dependencies and embedded infrastructure components.
3. Document a threat model covering the complete device: app, API, cloud, update mechanism.
4. Formalise your vulnerability management process: monitoring, triage with deadlines, criticality criteria, in-cycle or out-of-cycle patch decision.
5. Publish a coordinated vulnerability disclosure policy (point of contact, handling commitment).
6. Compile your security testing evidence: SAST, SCA, interface fuzzing, third-party pentest, and the handling of findings.
7. Describe the security architecture: flow diagrams, segmentation, authentication, encryption at rest and in transit.
8. Align the post-market: integrate cybersecurity monitoring into your existing post-market surveillance procedures, with named roles.

If you start from scratch, budget a quarter to compile a credible 524B file on an existing product — less if your IEC 81001-5-1 catch-up is already done, since most of the artifacts are shared. The worst scenario remains discovering 524B in the FDA’s refusal letter: at that point, it is your US market-access timeline that becomes the main vulnerability.