FDA Cybersecurity Requirements: Section 524B Explained

Direct Answer

What are the FDA Section 524B cybersecurity requirements for medical devices?

Section 524B of the FD&C Act requires cyber device submissions to include a postmarket vulnerability monitoring plan, evidence of processes and procedures providing reasonable assurance of cybersecurity, including updates and patches, and an SBOM. The February 3, 2026 FDA premarket cybersecurity guidance explains how to demonstrate each obligation, though no 524B(b)(4) rulemaking has made it formally binding as of mid-2026.

New to the topic? Start with our overview of medical device cybersecurity.

Section 524B in plain language

What it is: A U.S. law, in effect since March 29, 2023, that sets cybersecurity rules for new FDA submissions of connected medical devices.
Who it covers: Any "cyber device": a device with software that can connect to the internet and could be vulnerable to attack.
What it asks for: A plan to find and fix vulnerabilities after launch, proof that the device was designed and built securely, and a software bill of materials (SBOM).
What happens if you miss it: The FDA can refuse to accept the submission or send a deficiency letter.

Manufacturers rarely get tripped up by 524B because they disagree with it. They get tripped up because they treat it as a paperwork exercise bolted onto the end of design, rather than as three interlocking engineering obligations that have to be built into the device and documented from day one. This guide walks through the statute, the definitions that decide whether it applies to you, and the specific artifacts reviewers expect to see for each requirement.

Section 524B checklist: the four requirements for a cyber device, each matched to the document that proves it.

Share this graphic: view the full infographic and text version.

Understanding Section 524B of the FD&C Act

Section 524B is the binding statute: it states what you must do. The FDA cybersecurity guidance is the operative interpretation reviewers apply on top of it, describing how you demonstrate compliance. Every obligation below pairs the statutory requirement with the guidance-defined evidence that satisfies it.

Section 524B became law on December 29, 2022, as part of the Consolidated Appropriations Act, 2023 (the FDORA amendments), and took effect 90 days later, on March 29, 2023. The FDA began issuing refuse-to-accept (RTA) decisions on 524B grounds starting October 1, 2023. It is codified at 21 U.S.C. 360n-2, and formal correspondence with the FDA should cite both the FD&C Act section and the U.S. Code reference.

The full text of Section 524B

The statute is short. Here it is in full, as codified at 21 U.S.C. 360n-2 (cross-references shown as U.S. Code sections).

(a) In general. A person who submits an application or submission under section 360(k), 360c, 360e(c), 360e(f), or 360j(m) of this title for a device that meets the definition of a cyber device under this section shall include such information as the Secretary may require to ensure that such cyber device meets the cybersecurity requirements under subsection (b).

(b) Cybersecurity requirements. The sponsor of an application or submission described in subsection (a) shall—

(1) submit to the Secretary a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures;

(2) design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems to address— (A) on a reasonably justified regular cycle, known unacceptable vulnerabilities; and (B) as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks;

(3) provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components; and

(4) comply with such other requirements as the Secretary may require through regulation to demonstrate reasonable assurance that the device and related systems are cybersecure.

(c) Definition. In this section, the term "cyber device" means a device that— (1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

(d) Exemption. The Secretary may identify devices, or categories or types of devices, that are exempt from meeting the cybersecurity requirements established by this section and regulations promulgated pursuant to this section. The Secretary shall publish in the Federal Register, and update, as appropriate, a list of the devices, or categories or types of devices, so identified by the Secretary.

In plain terms: (a) ties the rule to 510(k), De Novo, PMA, PDP, and HDE submissions; (b) sets the obligations; (c) defines who is covered; and (d) lets the FDA exempt device types by publishing a list in the Federal Register.

Who counts as a "cyber device"

Under 524B(c), a device is a cyber device if it meets all three prongs: it includes software validated, installed, or authorized by the sponsor; it has the ability to connect to the internet; and it contains technological characteristics that could be vulnerable to cybersecurity threats. All three have to be true at once, but the connectivity prong is interpreted broadly. Wi-Fi, Bluetooth, NFC, a USB service port used for data transfer, a companion mobile app, or a gateway that relays data to a cloud service can all satisfy it, even when the device itself has no persistent network connection.

The statute does not distinguish by device class. A Class II blood glucose meter with Bluetooth pairing and a Class III implantable neurostimulator with an RF programmer are both evaluated against the same three-prong test. If your device has any software and any path to a network, treat 524B applicability as the default assumption and build your rationale for exclusion carefully, because reviewers will ask for it either way.

The three statutory requirements

524B(a) attaches the requirements to marketing submissions filed under 510(k), De Novo (513(f)), PMA (515(c)), PDP, and HDE pathways. IDE submissions under 520(g) are not explicitly enumerated in the statute, though the February 2026 guidance still sets cybersecurity expectations for investigational devices that meet the cyber device definition. Within that scope, 524B(b) creates three concrete obligations.

524B(b)(1): Postmarket vulnerability monitoring plan

You must submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and timely patch release. This has to be an operational plan at the time of clearance, not a placeholder promising future process. Reviewers expect:

A vulnerability monitoring procedure naming specific data sources (NVD, CISA KEV, vendor advisories, your SBOM-driven CVE feed) and a stated review cadence.
A coordinated vulnerability disclosure (CVD) policy published at a stable URL, with a security contact, an intake channel, and a stated safe harbor for good-faith researchers.
A triage service-level agreement defining how quickly you assess and score a report, typically using CVSS v3.1 or v4.0.
A remediation SLA that distinguishes routine patch cadence from an out-of-cycle response to a critical, actively exploited vulnerability.
A customer communication plan covering field notices and advisories; CSAF or VEX may optionally support downstream communication.

See our postmarket cybersecurity readiness plan guide and VDP/CVD workflows guide for the underlying process design.

524B(b)(2): Processes, updates, and patchability

You must design and maintain processes providing reasonable assurance that the device and related systems are cybersecure, and you must make patches and updates available on a reasonably justified regular cycle and, out-of-cycle, for critical vulnerabilities. This is the Secure Product Development Framework (SPDF) requirement expressed in statutory language, and it is where most submission effort concentrates. The evidence set typically includes:

An SPDF policy mapped to ANSI/AAMI SW96:2023, IEC 81001-5-1, or ISO/IEC 27034.
A security risk management file under IEC 81001-5-1, cross-referenced to the ISO 14971 safety risk file so security and safety risk are not analyzed in silos.
A threat model, typically STRIDE or an equivalent method, covering every trust boundary with mitigations traced back to design controls.
Architecture views: global system view, multi-patient harm view, updateability view, and security use-case view.
A penetration test report covering vulnerability chaining, boundary analysis, closed-box testing, and manually verified exploitation, not just an automated scan output.
A cybersecurity testing summary documenting unit-, integration-, and system-level security verification.
Updateability and patchability evidence: signed updates, rollback protection, a secure boot chain, and a demonstrated update mechanism on the actual device, not a description of one.
Cybersecurity labeling for end users covering security features, recommended network configurations, and decommissioning guidance.

524B(b)(3): Software Bill of Materials

You must provide an SBOM covering commercial, open-source, and off-the-shelf software components, including the versions of those components. The February 2026 guidance recommends the SBOM to be machine-readable, in CycloneDX or SPDX format, and accompanied by a monitoring plan for known vulnerabilities in those components. In practice, reviewers expect:

A machine-readable SBOM in CycloneDX 1.5+ or SPDX 2.3+ covering firmware, OS, middleware, application code, and third-party libraries.
Component identifiers, including PURL and CPE wherever both exist, because CVE matching depends on them.
Cryptographic hashes per component to support integrity verification.
Supplier and license metadata per component.
A documented SBOM generation procedure stating whether the SBOM is derived from source, build, or binary analysis, and how often it is regenerated.
A known-vulnerability summary at the time of submission, with an exploitability assessment for known vulnerabilities; VEX is an optional way to communicate that assessment. See our SBOM vulnerability management guide and VEX documents guide.

524B(b)(4): Additional requirements by regulation

524B(b)(4) authorizes the FDA to add cybersecurity requirements through formal rulemaking, not through guidance. As of mid-2026, no (b)(4) regulation has been issued. The February 2026 guidance is nonbinding and interprets the existing (b)(1) through (b)(3) obligations; it is not the rulemaking contemplated in (b)(4). That distinction matters procedurally, but it does not change practical exposure: reviewers use the guidance as the working standard for what "reasonable assurance" looks like, and deviating from it without a documented rationale is a common source of deficiency letters.

A compliance checklist in statutory order

Work through the requirements in the order the statute presents them, because gaps compound. A weak SBOM undermines your vulnerability monitoring claim, since you cannot monitor components you have not correctly identified, and a weak vulnerability plan undermines the postmarket narrative that ties the whole submission together.

Requirement	Core artifacts	Common gap
524B(b)(1) postmarket plan	CVD policy, triage SLA, remediation SLA, monitoring sources	Plan describes a future process rather than an operating one
524B(b)(2) SPDF	Threat model, security risk file, pen test report, update mechanism evidence	Threat model exists but is not traced to design controls or test evidence
524B(b)(3) SBOM	SBOM; the guidance recommends machine readability and component identifiers, while VEX is optional	SBOM delivered as PDF or spreadsheet, or missing identifiers

Item-by-item checklist

Use this list to check your submission before it goes in. Each item names the part of the statute it supports. The detail behind each item comes from the February 3, 2026 FDA premarket cybersecurity guidance, which is nonbinding but is what reviewers work from.

Applicability, 524B(a) and (c)

Written rationale stating whether the device is a cyber device, covering all three prongs (sponsor software, ability to connect to the internet, characteristics that could be vulnerable)
Every connection path listed, including Bluetooth, USB service ports, companion apps, gateways, and cloud services
Submission type confirmed as one 524B covers: 510(k), De Novo, PMA, PDP, or HDE

Postmarket plan, 524B(b)(1)

Postmarket vulnerability monitoring plan naming the sources you watch (for example CISA KEV, NVD, supplier advisories)
Coordinated vulnerability disclosure policy that is published and has a working contact
Defined timelines for triage, risk assessment, customer communication, and remediation
Named owners for each step of the process

Secure development and patching, 524B(b)(2)

Secure product development framework (SPDF) procedures, mapped to a recognized standard such as IEC 81001-5-1 or ANSI/AAMI SW96
Threat model covering the whole system, traced to security controls and test evidence (threat modeling)
Security risk management report kept separate from, but linked to, the ISO 14971 safety risk file
Security architecture views: global system, multi-patient harm, updatability and patchability, and security use cases (architecture views guide)
Penetration test report from testers independent of the development team (medical device penetration testing)
Description of how updates and patches reach the device, with a justified regular update cycle
Out-of-cycle process for critical vulnerabilities that could cause uncontrolled risks
Assessment of unresolved anomalies and residual security risk

SBOM, 524B(b)(3)

Machine-readable SBOM (SPDX or CycloneDX) covering commercial, open-source, and off-the-shelf components
Each component listed with supplier, version, and support status, including end-of-support dates
Known vulnerabilities in listed components assessed, with the reason each one is or is not a risk to the device (SBOM guide)

Filing

All of the above placed in the cybersecurity section of the eSTAR (eSTAR 7.1 checklist)
Cross-check against the full list of cybersecurity documents in the 18-deliverables map

Pathway differences that affect scope

The core 524B obligations are identical across 510(k), De Novo, and PMA, but the depth of evidence reviewers expect scales with pathway. A PMA submission for a Class III device typically requires a more exhaustive security risk management file and a broader penetration test scope than a straightforward Class II 510(k) for a similar architecture. See our pathway-by-pathway cybersecurity differences guide for the specific deltas, and our SPDF playbook for how to build the underlying process once and scale the evidence package to the pathway.

Real examples: the problems 524B is meant to prevent

These three cases are not 524B enforcement actions. Two came before the law, and none was a premarket review. Each shows a gap that one of the three 524B requirements now covers.

Medtronic MiniMed insulin pumps (2019). The FDA announced a recall of certain MiniMed 508 and Paradigm pumps because someone nearby could connect wirelessly and change insulin delivery. The pumps couldn't be patched, so patients had to switch to newer models (CISA advisory ICSMA-19-178-01). The 524B link: 524B(b)(2) requires processes that keep a device updatable and patchable.

Illumina sequencing instruments (2023). The FDA warned that software on several Illumina sequencers could let an unauthorized user take control remotely and alter results. CISA rated the main flaw 10.0, and Illumina shipped a patch (FDA letter, CISA advisory ICSMA-23-117-01). The 524B link: 524B(b)(1) requires a plan to monitor, find, and fix vulnerabilities after launch.

Contec CMS8000 patient monitors (2025). The FDA warned that these monitors, also sold as Epsimed MN-120, could be controlled remotely and send patient data to an outside address. CISA found hidden functionality with a hard-coded IP address in the firmware (FDA safety communication, CISA alert). The 524B link: 524B(b)(3) requires an SBOM, which shows what is really inside the firmware.

Free tools for each 524B requirement

524B question	Free tool
Is my device a cyber device?	Section 524B Applicability Checker
524B(b)(2): Where do I start my threat model?	Threat Model Starter
524B(b)(2): How severe is this vulnerability?	CVSS v4.0 calculator
524B(b)(3): Is my SBOM ready?	SBOM Readiness Check
524B(b)(1): Do I have a disclosure policy?	CVD Policy Generator
524B(b)(2): How often should I patch?	Postmarket Cadence Calculator
I got an FDA deficiency letter.	Deficiency Letter Triage

How Blue Goat Cyber approaches 524B compliance

We build 524B compliance into the device development lifecycle rather than assembling it retroactively before submission. For a new engagement, we start by determining cyber device applicability with a documented rationale, then stand up the SPDF artifacts (threat model, security risk management file, architecture views) in parallel with SBOM generation from the build pipeline, so the vulnerability monitoring plan is grounded in a component inventory that is actually correct. Penetration testing is scheduled once the architecture is stable but early enough that findings can still change the design, not just the documentation. We deliver the postmarket vulnerability plan as a working process, with the CVD policy live and the monitoring feed connected, before the submission goes in. Our FDA Premarket Cybersecurity Services and FDA Cybersecurity Deficiency Response engagements cover this end to end, from initial gap assessment through response to any deficiency letter the FDA issues.

FAQ

Does 524B apply to a device with no wireless connectivity?

Possibly. The connectivity prong of the cyber device definition covers any ability to connect to the internet, which includes a USB port used for data transfer, a service laptop connection used to pull logs, or an intermediary gateway that relays data even when the device itself never touches the internet directly. Absence of Wi-Fi or Bluetooth does not settle the question on its own; document the actual data paths and evaluate each one against the three-prong test.

What happens if I omit the SBOM from a 524B submission?

The FDA can issue a refuse-to-accept decision or a deficiency letter citing the missing 524B(b)(3) requirement. Since RTA screening for 524B began October 1, 2023, SBOM omission is one of the most common and most avoidable causes of a hold, because the requirement is unambiguous and the artifact is generative from your build process rather than something you have to reconstruct after the fact.

Is the February 2026 guidance legally binding?

No. It is nonbinding guidance that interprets the binding statutory requirements in 524B(b)(1) through (b)(3). No 524B(b)(4) regulation has been issued as of this writing. In practice, reviewers use the guidance as the working definition of "reasonable assurance," so departing from its recommendations without a documented, defensible rationale carries the same practical risk as noncompliance with a binding rule.

Does 524B apply differently to legacy devices already on the market?

524B applies to new marketing submissions, including certain modifications to legacy devices that require a new submission. A device cleared before 524B took effect is not retroactively subject to it unless you file a new submission that triggers 524B(a) applicability, such as a significant design change. See our guide on legacy medical device cybersecurity for how the postmarket expectations still apply outside the premarket statute.

How does 524B interact with ISO 14971 safety risk management?

524B does not replace ISO 14971; it requires a parallel security risk management process, most commonly built under IEC 81001-5-1, that is cross-referenced to your existing safety risk file. A vulnerability that could cause patient harm needs to appear in both files with a traceable link between them, because reviewers check whether the security risk assessment actually informed the safety risk assessment and not the other way only.

Where to go next

Cybersecurity for IVD Devices - 524B applied to in vitro diagnostic platforms.
Section 524B Applicability Checker - confirm whether Section 524B applies to your device.

FDA Cybersecurity Requirements for Medical Devices (524B)

Key Takeaways

Section 524B in plain language