FDA Premarket Cybersecurity for Medical Devices: Section 524B, SBOM, and Threat Modeling

Scope of this page: Section 524B of the FD&C Act (21 U.S.C. §360n-2, “Ensuring Cybersecurity of Devices”) and what it actually requires in a premarket submission — the cyber device test, the secure product development framework (SPDF), the software bill of materials (SBOM), the postmarket vulnerability-monitoring/disclosure plan, and how cybersecurity risk analysis diverges from the ISO 14971 risk file you’re already building. This is not a general cybersecurity explainer; it assumes you already know you’re submitting a device and need to know what FDA’s premarket reviewers will actually check.

The three-part “cyber device” test that decides whether 524B applies to you

Section 524B doesn’t apply to every device — it applies to a statutorily defined cyber device. Under 21 U.S.C. §360n-2(c), a device is a cyber device if it meets all three of the following:

• It includes software validated, installed, or authorized by the sponsor;
• It has the ability to connect to the internet; and
• It contains any technological characteristics that could be vulnerable to cybersecurity threats.

That third prong is broad by design — FDA reads it to cover most network-connected devices, not just devices that transmit patient data. If your device has firmware that can be updated over a network connection, or exposes any interface (Bluetooth, Wi-Fi, USB-to-network bridge) that a threat actor could reach, treat it as in-scope until you have a documented reason otherwise. The statute lets FDA exempt specific devices or device categories by Federal Register notice, but absent a published exemption, the default is inclusion.

Section 524B was added by the Consolidated Appropriations Act, 2023 (incorporating the PATCH Act language) and took effect 90 days after the December 29, 2022 enactment date — so any 510(k), De Novo, or PMA submission since roughly late March 2023 for a device meeting the cyber device test has been subject to it. This isn’t a new or pending requirement; it’s been the baseline for premarket review for years now, and FDA can refuse to accept (RTA) a submission that omits the required elements.

What Section 524B actually requires you to submit

Strip away the surrounding guidance language and the statute itself imposes four concrete obligations on a cyber device sponsor:

1. A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits — including a plan for coordinated vulnerability disclosure, and for issuing timely patches and updates as vulnerabilities are identified.
2. Documented processes and procedures that provide reasonable assurance the device and related systems are cybersecure, and that the sponsor will make patches/updates available on a reasonably justified regular cycle, and out-of-cycle for critical vulnerabilities that could cause uncontrolled risk.
3. A software bill of materials (SBOM), including commercial, open-source, and off-the-shelf software components used in the device.
4. Whatever else FDA reasonably requires to demonstrate cybersecurity assurance — the statute deliberately leaves this open, and FDA’s premarket cybersecurity guidance (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions) is where that discretion gets filled in with specifics: a secure product development framework description, a risk assessment, architecture views, and a labeling review.

Items 1–3 are statutory floors — you cannot negotiate them away in a pre-submission meeting. Item 4 is where most of the actual document volume in a real submission lives, because it’s where FDA’s guidance translates a three-sentence statute into an expected submission package.

The Secure Product Development Framework (SPDF): documentation, not aspiration

FDA’s guidance expects sponsors to describe an SPDF — the security-equivalent of the software development lifecycle process you’re already documenting for IEC 62304 — covering how security is built in during design, not bolted on before submission. A reviewer is checking for evidence, not a policy statement, of:

• Threat modeling performed against the device’s actual architecture (data flows, interfaces, trust boundaries) — not a generic template. FDA’s guidance points to threat-modeling methodologies (e.g., STRIDE-style approaches) as an acceptable basis, but expects the output tied to your specific device, not a boilerplate diagram.
• A security risk assessment distinct from your general safety risk assessment (see the next section for why these can’t just be the same document with a new cover page).
• Security architecture views — global system view, multi-patient harm view, and update/patch architecture view are the three FDA guidance specifically calls for.
• Security testing evidence — static/dynamic analysis, vulnerability scanning, penetration testing, and boundary/fuzz testing scaled to the device’s risk profile.

If your device also carries software safety classification obligations, the SPDF and your IEC 62304 lifecycle records overlap substantially — particularly the SOUP (software of unknown provenance) documentation, which is functionally the same underlying component inventory your SBOM formalizes for the cybersecurity submission. Build the two together rather than as separate exercises against the same codebase.

Building an SBOM that actually satisfies the requirement

The statute’s SBOM language is short; what reviewers check against it is not. In practice, an SBOM that will hold up needs:

• A machine-readable format — FDA’s guidance references the two formats the wider software-supply-chain ecosystem has converged on: SPDX (an ISO/IEC 5962:2021 standard) and CycloneDX. Either is acceptable; an unstructured spreadsheet of package names is not what reviewers expect for a component inventory of this kind.
• Coverage of transitive dependencies, not just top-level libraries you directly imported. A vulnerability three layers deep in a dependency tree is still a vulnerability in the device.
• Support/end-of-life status per component — whether the component is still actively maintained upstream, and what your plan is for components that reach end-of-life while the device is still on the market. A component already unsupported at the time of submission is a question FDA’s reviewers are specifically trained to ask about.
• A live link into your vulnerability-monitoring process — the SBOM isn’t a one-time artifact filed with the submission and forgotten. It’s the input list your postmarket monitoring plan (requirement #1 above) has to actually watch against new CVE disclosures for the life of the device.

Depth here is where sponsors most often underscope: a top-level dependency list satisfies the letter of “bill of materials” but not what a reviewer is actually trying to verify, which is whether you can answer “is this device affected” the next time a widely used library discloses a critical CVE.

Why cybersecurity risk analysis is not just your ISO 14971 file with a new section

This is the point sponsors most often get wrong, and it’s explicit in FDA’s own guidance: the probabilistic risk model in ISO 14971 — risk as the combination of probability of occurrence of harm and severity of that harm — does not map cleanly onto cybersecurity risk. FDA’s guidance states this directly and substitutes exploitability as the operative basis for estimating cybersecurity risk, in place of a probability-of-occurrence estimate that doesn’t have a meaningful analog for an adversarial, human-driven threat rather than a random failure mode.

Practically, this means your security risk assessment needs its own methodology — scoring exploitability (attack complexity, required privileges, public availability of exploit code, and similar factors, the same family of inputs CVSS-style scoring uses) rather than trying to force a security finding into the same probability bucket you’d use for a mechanical failure mode. You can cross-reference the two risk files against each other where a security exploit’s consequence is a genuine patient-safety harm, but they are not interchangeable documents, and a reviewer who sees cybersecurity risk scored purely on the ISO 14971 probability/severity matrix will treat that as a gap, not a shortcut.

Coordinated vulnerability disclosure and the postmarket patching obligation

The statutory vulnerability-monitoring plan (requirement #1 above) has to specifically address coordinated vulnerability disclosure — a documented process for receiving vulnerability reports from external researchers, triaging them, and disclosing fixed vulnerabilities on a responsible timeline rather than either ignoring reports or publishing details before a patch exists. The ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes) standards are the reference framework most sponsors build this process against, though the statute itself doesn’t mandate a specific standard by name.

On the patching side, the statute’s language — patches and updates on a “reasonably justified regular cycle,” plus out-of-cycle patches for vulnerabilities that could cause uncontrolled risk — means your plan needs two documented cadences, not one: a routine maintenance cycle and a defined trigger (tied back to the exploitability scoring above) for when a finding is severe enough to break that cycle. Reviewers expect to see the criteria for that second cadence spelled out, not just asserted.

Where this fits in the actual submission package

Section 524B cybersecurity documentation doesn’t replace your standard submission architecture — it’s an added, parallel section within whichever pathway you’re using. If you’re filing a 510(k), the cybersecurity documentation sits alongside your predicate comparison and performance data; the pathway choice itself (510(k), De Novo, or PMA — see the classification and pathway guide) doesn’t change what 524B requires, only how it’s packaged. It also doesn’t substitute for your general Quality System Regulation obligations under 21 CFR Part 820, your SaMD classification analysis if the device is software-only, or your postmarket field safety corrective action process if a deployed vulnerability later requires one. Treat cybersecurity as one more parallel workstream feeding the same submission, built from the same underlying design-control records, not a bolt-on security appendix assembled at the end.

Frequently asked questions

Does Section 524B apply to a device that isn’t internet-connected?

Not under the statutory cyber device test — internet connectivity is one of the three required prongs. A fully offline device with no network interface at all falls outside 524B’s mandatory requirements, though FDA’s general premarket guidance still expects a cybersecurity risk discussion for any device with embedded software, just not the SBOM/vulnerability-monitoring-plan package specifically.

Can FDA refuse to accept a submission over missing cybersecurity documentation?

Yes. Because the SBOM, the vulnerability-monitoring/disclosure plan, and the documented secure-development processes are statutory requirements for a cyber device, their absence is a refuse-to-accept (RTA) ground, not a deficiency that gets worked out after acceptance.

Does an SBOM need to be made public?

No — the SBOM is submitted to FDA as part of the premarket file. Some purchasers (particularly hospital systems following their own procurement security policies) separately request an SBOM directly from manufacturers, which is a contractual/commercial expectation distinct from the regulatory submission requirement.

Is a legacy device already on the market subject to 524B?

524B’s premarket documentation requirements attach at the point of a premarket submission (510(k), De Novo, PMA, or a submission for a significant change to an already-cleared device). A device with no new submission pending isn’t retroactively required to file 524B documentation, but FDA has separately signaled expectations around postmarket cybersecurity management for legacy devices through other guidance and enforcement discretion channels — don’t treat an already-cleared device as permanently out of scope for cybersecurity obligations generally.

How does this interact with the EU’s cybersecurity requirements for devices?

The EU imposes its own device cybersecurity expectations through the Medical Device Regulation’s general safety and performance requirements (Annex I) plus the EU Cyber Resilience Act’s product-security baseline for connected products generally. The two regimes aren’t identical in required artifacts, but an SBOM and a documented vulnerability-handling process built to satisfy Section 524B will cover most of the same substantive ground the EU side expects — verify the specific documentation format each submission requires rather than assuming one filing satisfies both.

This page reflects the statutory text of 21 U.S.C. §360n-2 and FDA’s published premarket cybersecurity guidance as of this writing. FDA guidance in this area is updated periodically; verify against the current guidance document on fda.gov before a live submission.