FDA 524B Cybersecurity

What documentation does FDA Section 524B actually require in a premarket submission?

Phillip Stephens 1 June 2026 6 min read

If your device runs software, connects to a network, and could be exposed to cyber threats, Section 524B applies — and an incomplete submission can be refused before review even starts. The FDA's June 2025 final guidance expects five documentation elements: a secure development framework, a threat model and risk assessment, security architecture views, a machine-readable SBOM, and cybersecurity testing evidence.

If your device includes software, can connect to a network, and has characteristics that could expose it to cybersecurity threats, FDA Section 524B applies — and an incomplete cybersecurity package can have your submission refused before substantive review even begins. The FDA’s June 2025 final guidance expects five documentation elements: a secure product development framework, a threat model and cybersecurity risk assessment, security architecture views, a machine-readable software bill of materials, and cybersecurity testing evidence. Each is its own body of work.

Which devices does 524B apply to?

Section 524B of the Food, Drug, and Cosmetic Act applies to a “cyber device.” The statute defines that as a device that includes software validated, installed, or authorised by the sponsor; has the ability to connect to the internet; and contains technological characteristics that could be vulnerable to cybersecurity threats.

The three conditions are cumulative. A device that runs firmware but never connects to a network may fall outside the definition; a connected device with any exploitable surface falls inside it. In practice the connectivity condition catches most modern devices — anything with Bluetooth, Wi-Fi, a cellular module, a USB data path, or a hospital-network interface tends to qualify. The default working assumption for any software-driven connected device is that 524B applies until you have documented why it does not.

The requirement was added to the FD&C Act through the Consolidated Appropriations Act of 2023 and took effect 29 March 2023. It reaches across submission pathways — 510(k), PMA, De Novo, HDE, and PDP submissions for cyber devices all carry the obligation.

What are the documentation elements?

The FDA’s expectations are set out in its guidance Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, finalised 27 June 2025. The guidance is non-binding, but the underlying statutory requirement is not, and reviewers work directly from it. It organises around five things your submission needs to demonstrate:

Secure Product Development Framework — evidence that security is built into your development lifecycle rather than bolted on afterward. This is the plans-and-procedures layer: how you identify, communicate, track, and remediate vulnerabilities, and how that work feeds your corrective and preventive action process after the device is on the market.
Threat model and cybersecurity risk assessment — a structured analysis of how the device could be attacked and what the consequences would be. The guidance points to recognised methods such as STRIDE, attack trees, and MITRE-informed approaches. Cyber risk analysis is distinct from the safety risk analysis you already run under [[ISO-14971-2019-5-4]], though the two should reference each other.
Security architecture views — diagrams and descriptions of the device’s security design from several angles. The guidance describes a global system view, a multi-patient harm view, an updateability and patchability view, and a security use case view.
Software bill of materials — a machine-readable inventory of every software component, covered in detail below.
Cybersecurity testing evidence — the results that show your controls work, including security requirements verification, threat mitigation testing, vulnerability testing, and penetration testing.

Sitting alongside these is a coordinated vulnerability disclosure process and a postmarket vulnerability management plan. Under the 2025 guidance, coordinated disclosure is not treated as optional — manufacturers are expected to document how identified threats are communicated to healthcare providers and researchers, what the timelines for patch development are, and how fixes are rolled out.

What does the SBOM requirement actually involve?

Section 524B(b)(3) requires a machine-readable software bill of materials listing all commercial, open-source, and off-the-shelf software components in the device. This is the single most common point of friction, because it cannot be hand-assembled at submission time — it has to be generated from your actual build.

The FDA accepts the two established formats, SPDX and CycloneDX, in JSON or XML, and expects a human-readable companion document alongside the machine-readable file. Each component entry needs two things: identity (supplier name, component name, version) and traceability (a unique identifier such as a purl or CPE, plus dependency relationships).

The traceability requirement is what trips teams up. Listing your components is the easy half. Mapping each one to a known-vulnerability identifier, keeping that mapping current as components update, and showing the dependency tree is ongoing work that has to survive every build — not a document you write once.

What is the Refuse to Accept policy and when does it bite?

A Refuse to Accept decision means the FDA declines to review your submission at all, because it is missing required content. For cyber devices, the agency’s RTA policy has applied since 1 October 2023 — before that date the FDA worked with sponsors collaboratively through the review process; from that date it could refuse submissions outright for missing 524B content. The FDA Section 524B deadline tracker lays out the statutory and guidance dates behind the policy.

This is what makes the cybersecurity package different from a deficiency you can fix mid-review. A 510(k) with a weak human-factors section gets a deficiency letter and a chance to respond. A cyber device submission with no SBOM, or no threat model, can be bounced at the door — restarting the clock you were trying to protect. The cybersecurity documentation is a gate, not a graded section.

How do you assemble this without a six-figure consultancy bill?

The honest answer is that most teams buy it. A specialist cybersecurity consultancy will threat-model your device, draft the architecture views, and assemble the package — and the knowledge leaves when the engagement ends, so the next submission starts again. The recurring problem is that none of this is a one-time artifact. The SBOM changes every build. The threat model changes when you add a connectivity feature. The architecture views drift as the design evolves.

That is the case for treating the cybersecurity package as something generated from your product rather than authored beside it. If your software bill of materials comes straight from your build, your threat model is linked to your actual architecture, and your cyber risk analysis references the same risk file you already maintain under ISO 14971, the submission package becomes an export of work you are already doing — not a separate project you fund at six figures each time. That is the gap ForgeComply is built to close: mapping the standards’ content requirements onto your product context so evidence assembly takes days instead of quarters.

The same evidence-assembly-under-deadline pattern shows up across regimes — it is exactly the pressure behind the EU Cyber Resilience Act’s September 2026 reporting obligations, where the clock is even tighter.

Key takeaways

Scope is broad — if your device runs software, connects to a network, and has an exploitable surface, treat 524B as applying until you have documented otherwise.
Five documentation elements — secure development framework, threat model and risk assessment, security architecture views, a machine-readable SBOM, and cybersecurity testing evidence.
The SBOM is build-derived — it needs identity and traceability for every component in SPDX or CycloneDX, plus a human-readable companion, and it changes with every release.
Refuse to Accept is a gate — since 1 October 2023 the FDA can decline to review a cyber device submission that is missing required cybersecurity content, rather than issuing a fixable deficiency.
The package is living, not one-time — every artifact drifts as the design evolves, which is why generating it from product context beats re-authoring it for each submission.