Published: June 18, 2026
FDA Section 524B is the cyber device statute of the FD&C Act, added by the Consolidated Appropriations Act, 2023. Every subsection is a cybersecurity requirement. 524B(a) sets applicability, 524B(b)(1) requires a postmarket vulnerability management plan, 524B(b)(2) requires processes and updates/patches, 524B(b)(3) requires a software bill of materials, 524B(b)(4) authorizes future FDA regulation, and 524B(c) defines "cyber device." A clean submission addresses each subsection with a specific artifact and traces deficiency risk back to the specific subsection it lands under.
Section 524B of the Federal Food, Drug, and Cosmetic Act is short, dense, and entirely about cybersecurity. There are no "non-cyber" provisions to carve out. The FDA's February 3, 2026 final premarket cybersecurity guidance is the operational manual that tells manufacturers what artifacts satisfy each subsection. Most deficiency letters can be traced to a specific subsection that the submission addressed weakly or not at all. This post walks the statute subsection by subsection, names the artifact that satisfies each, and flags the deficiency patterns that recur for each one.
Key Takeaways
- All of Section 524B is cybersecurity. There are no non-cyber subsections to carve out.
- 524B(c) is the definition subsection: if your device meets the "cyber device" test, every other subsection attaches.
- 524B(b)(1) requires a postmarket plan, (b)(2) requires processes plus an update/patch cadence, (b)(3) requires an SBOM.
- 524B(b)(4) is the open-ended hook for future FDA cybersecurity regulation; track it but do not file against it yet.
- Most deficiencies map cleanly to one subsection. Knowing which subsection a deficiency falls under tells you what evidence to add.
Table of Contents
- Where Section 524B Came From
- 524B(a): Applicability
- 524B(b)(1): Postmarket Vulnerability Management Plan
- 524B(b)(2): Processes, Updates, and Patches
- 524B(b)(3): Software Bill of Materials
- 524B(b)(4): Other Requirements by Regulation
- 524B(c): The "Cyber Device" Definition
- How Blue Goat Approaches a 524B Submission
- FAQ
Why this matters
Section 524B took effect when the FDA gained authority on March 29, 2023 to refuse to accept (RTA) any premarket submission for a cyber device that does not meet its requirements. The agency held off on issuing RTAs based solely on Section 524B until October 1, 2023, which is the operative enforcement date. Section 524B is binding statute; the agency's February 3, 2026 final premarket cybersecurity guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," is nonbinding by design ("Contains Nonbinding Recommendations" appears on every page) but it is the operative interpretation the FDA uses when reviewing a submission against 524B. Deficiency letters in 2025 and 2026 consistently cite 524B subsections by number, and the FDA's own cybersecurity submission examples organize evidence subsection by subsection. Manufacturers that submit a generic "cybersecurity section" without mapping each artifact to the specific subsection it satisfies draw avoidable deficiencies. Manufacturers that misread 524B(c) and conclude their device is not a cyber device when it is draw the worst outcome of all: an RTA after months of submission preparation.
Where Section 524B Came From
Section 524B was added to the FD&C Act by Section 3305 of the Consolidated Appropriations Act, 2023 (Pub. L. 117-328). The statute is short by design and leaves the operational detail to FDA guidance.
Key dates:
- December 29, 2022 - 524B became law, signed as part of the Consolidated Appropriations Act, 2023 (Pub. L. 117-328), the FDORA provisions, Section 3305.
- March 29, 2023 - The law took effect, 90 days later, per the effective-date clause in Section 3305(c) of Pub. L. 117-328. The FDA's refuse-to-accept authority attached on this date.
- October 1, 2023 - The FDA actually began issuing refuse-to-accept decisions based on 524B, per the FDA "Refuse to Accept Policy for Cyber Devices" guidance (March 30, 2023), which stated the agency would not issue RTAs based solely on 524B before October 1, 2023. This is the real start-of-rejections date.
The February 3, 2026 final guidance supersedes the June 2025 final, which itself superseded the September 2023 final. Earlier 2018 and 2014 documents preceded that chain. Any current submission is built against the February 2026 guidance.
524B(a): Applicability
What the Statute Says
524B(a) attaches the section's requirements to any person who submits an application or submission described in section 510(k), 513, 515(c), 515(f), or 520(m). In plain language: 510(k), De Novo, PMA, PMA supplement, PDP, and Humanitarian Device Exemption submissions for cyber devices. IDE submissions (520(g)) are not enumerated in 524B(a), but cybersecurity expectations still apply to IDEs under the February 3, 2026 final premarket guidance. BLA and IND submissions are outside 524B entirely (the statute is device-only), but the guidance still applies to the device constituent of a combination product - see combination products: when device cybersecurity content lands in a BLA or IND.
What Satisfies It
Applicability is not an artifact requirement. The reviewer determines whether 524B attaches based on the device description and the 524B(c) definition. The submission's job at this subsection is to make the applicability determination unambiguous: state explicitly that the device is or is not a cyber device under 524B(c) and justify the determination.
Deficiency Pattern
Submissions that quietly assume non-applicability without addressing 524B(c) draw a clarification request at best and an RTA at worst.
524B(b)(1): Postmarket Vulnerability Management Plan
What the Statute Says
524B(b)(1) requires the manufacturer to submit 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.
What Satisfies It
A written postmarket cybersecurity plan covering vulnerability monitoring sources, triage rules, severity thresholds, response timelines, CAPA linkage, coordinated vulnerability disclosure (CVD) policy with a public intake address, and customer communication channels. The plan references the QMSR procedures it plugs into rather than running as a standalone security workflow.
Deficiency Pattern
Plans that describe what the manufacturer "will do" without naming the procedure, the role responsible, or the timeline. Plans that omit CVD or list an intake address that does not resolve. Plans that have no link to CAPA.
524B(b)(2): Processes, Updates, and Patches
What the Statute Says
524B(b)(2) has two parts. 524B(b)(2)(A) requires the manufacturer to design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure. 524B(b)(2)(B) requires making available postmarket updates and patches to the device and related systems on a reasonably justified regular cycle and, for critical vulnerabilities that could cause uncontrolled risks, as soon as possible out of cycle.
What Satisfies (b)(2)(A)
Evidence of secure development lifecycle practices: a documented SDLC aligned to IEC 81001-5-1 and AAMI SW96, secure design and threat modeling artifacts, security risk management per AAMI TIR57 and SW96, security architecture views (system, multi-patient harm, updateability, security use case), and security verification and validation including penetration testing.
What Satisfies (b)(2)(B)
A documented update and patch cadence (the "regular cycle"), an expedited out-of-cycle process for critical vulnerabilities, the technical mechanism for delivering updates (signed packages, verified boot, rollback), and customer-facing communication of the cadence and the channel.
Deficiency Pattern
(b)(2)(A) deficiencies hit the threat model and architecture views most often: missing trust boundaries, missing data flows, no security use case view. (b)(2)(B) deficiencies hit the update mechanism: no signature verification on the package, no rollback path, no documented expedited cadence.
524B(b)(2)(B) requires both a regular update cycle and an out-of-cycle expedited process for critical vulnerabilities. A submission that names only one of the two draws a deficiency.
524B(b)(3): Software Bill of Materials
What the Statute Says
See also: Does FDA Section 524B Apply to Legacy Devices?, SBOM End-of-Support, EOL, and Level of Support, and Documenting Update Cadence for an FDA §524B Submission.
524B(b)(3) requires the manufacturer to provide a software bill of materials, including commercial, open-source, and off-the-shelf software components.
What Satisfies It
A machine-readable SBOM in CycloneDX or SPDX format covering every commercial, open-source, and off-the-shelf component, generated from the actual build (not hand-curated), accompanied by a VEX statement set that classifies known vulnerabilities by exploitability in the device's deployed configuration. The SBOM regenerates on every release and feeds the postmarket vulnerability monitoring described in (b)(1).
Deficiency Pattern
Hand-curated SBOMs that omit transitive dependencies. SBOMs in PDF or spreadsheet form that are not machine-readable. SBOMs with no accompanying VEX, leaving the reviewer to assume every listed CVE is exploitable. SBOMs that do not match the binaries the manufacturer is submitting.
524B(b)(4): Other Requirements by Regulation
What the Statute Says
524B(b)(4) authorizes the FDA to require, by regulation, such other information as may be necessary to demonstrate reasonable assurance that the device and related systems are cybersecure.
What Satisfies It
Nothing yet. 524B(b)(4) is an open-ended hook for future FDA rulemaking. There are no regulations issued under (b)(4) at the time of writing. Manufacturers should track Federal Register activity for proposed rulemaking but do not need to file evidence against (b)(4) today.
Deficiency Pattern
None at present. Watch for proposed rulemaking; the FDA has discussed using (b)(4) to formalize SBOM format, VEX, and update transparency requirements that today live in guidance.
524B(c): The "Cyber Device" Definition
What the Statute Says
524B(c) defines a "cyber device" as a device that includes software validated, installed, or authorized by the sponsor as a device or in a device; has the ability to connect to the internet; and contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.
Why the Definition Is Broad
All three prongs are easy to meet, and the connectivity prong is the broadest of all. Any type of connection to the device's software qualifies. Wired Ethernet, Wi-Fi, cellular, Bluetooth, BLE, NFC, Zigbee, a USB port that exposes a service or accepts firmware, a serial or JTAG port, a companion mobile or desktop app, a cloud backend, a gateway, or an indirect path through a hospital network all satisfy 524B(c). The statute does not require direct internet connectivity, and the FDA does not read it that way. If software on the device can be reached, updated, or exchanged with through any interface, the device is a cyber device.
What Satisfies It
An explicit determination in the submission stating that the device is a cyber device under 524B(c), with a brief justification referencing the three prongs and naming every interface that touches the device software. For the rare device that is not a cyber device, a justification explaining why none of the three prongs is met, with specific attention to the connectivity prong.
Deficiency Pattern
Submissions that assume "no Wi-Fi means not a cyber device" and skip the 524B section. The FDA reads the connectivity prong as covering any interface to the device software, not just internet-routable network interfaces. A USB service port, a Bluetooth radio, an NFC pairing interface, a companion app, or a gateway-mediated cloud path are all sufficient to make the device a cyber device under 524B(c).
How Blue Goat Approaches a 524B Submission
We organize 524B submissions subsection by subsection so that every reviewer question maps to a specific artifact in a specific place. The 524B(c) determination opens the cybersecurity section. The (b)(1) postmarket plan, the (b)(2) SDLC and update cadence evidence, and the (b)(3) SBOM and VEX each get a labeled subsection with the supporting artifacts attached. We draft the threat model and architecture views against AAMI TIR57, AAMI SW96, and IEC 81001-5-1, and we plug the postmarket plan into the manufacturer's CAPA procedure so that vulnerability response has a closure record, not just a ticket. Our team holds CISSP, OSCP, and prior military red-team credentials, and we ground our work in Section 524B, the FDA's February 3, 2026 guidance, AAMI SW96:2023, AAMI TIR57:2016/(R)2023, and IEC 81001-5-1:2021. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our premarket cybersecurity service or our 524B requirements guide.
FAQ
Are any subsections of 524B not about cybersecurity?
No. Section 524B is the cyber device statute, added to the FD&C Act specifically to give the FDA authority over medical device cybersecurity at premarket. Every subsection, including the definition in (c) and the future-rulemaking hook in (b)(4), is a cybersecurity provision. A submission cannot carve out a "non-cyber" portion of 524B.
Which 524B subsection do most deficiencies come from?
524B(b)(2)(A) (processes) and 524B(b)(3) (SBOM) generate the largest share of deficiencies. (b)(2)(A) deficiencies usually target the threat model and architecture views; (b)(3) deficiencies usually target SBOM machine-readability, transitive coverage, and missing VEX. 524B(b)(1) postmarket plan deficiencies are also common, typically for missing CVD intake or no CAPA linkage.
Does 524B(b)(4) require anything today?
Not yet. 524B(b)(4) authorizes the FDA to issue regulations requiring additional information, but no such regulations are in effect at the time of writing. Manufacturers should monitor the Federal Register for proposed rulemaking. The FDA has signaled interest in formalizing SBOM format, VEX, and update transparency requirements through (b)(4).
How do I know if my device meets the 524B(c) cyber device definition?
Apply the three-prong test, and be honest about the connectivity prong: any type of connection to the device's software qualifies. That includes wired Ethernet, Wi-Fi, cellular, Bluetooth, BLE, NFC, Zigbee, USB ports that expose a service or accept firmware, serial or JTAG ports, companion mobile or desktop apps, cloud backends, gateways, and indirect paths through a hospital network. Direct internet routability is not required. If software on the device can be reached, updated, or communicated with through any interface, treat the device as a cyber device under 524B(c).
Where does the FDA's February 3, 2026 guidance fit relative to 524B?
The statute is binding and sets the requirements; the guidance is nonbinding but is the operative interpretation the FDA applies when reviewing a submission. The February 3, 2026 final premarket cybersecurity guidance tells you what artifacts satisfy each subsection. Submissions are built against the guidance and traced back to the statute subsection. Citing the statute without the guidance, or the guidance without the statute, both leave gaps a reviewer will flag.
Does 524B apply to a 510(k) for a device that has no network interface?
Almost always yes. The 524B(c) connectivity prong covers any type of connection to the device software, not just network interfaces. A USB service port that allows firmware updates or configuration changes, a Bluetooth or BLE radio, an NFC interface, a serial or JTAG port, or a companion app all make the device a cyber device. The only device that escapes 524B is one with no software at all, or software that is permanently sealed with no interface of any kind, which is rare in modern medical devices.
Ready to map your submission to Section 524B subsection by subsection?
If your cybersecurity section is one block of text instead of a labeled response to each 524B subsection, you are leaving deficiency exposure on the table. We can structure the submission so every reviewer question maps to a specific artifact. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.
Christian Espinosa, Founder, Blue Goat Cyber, CISSP, OSCP. Christian has led premarket and postmarket cybersecurity programs for connected medical devices across Class II and Class III submissions and previously commanded military red-team operations. Read more at christian-espinosa.
Sources & references
Primary sources cited in this article. Links open in a new tab.