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's February 3, 2026 final premarket cybersecurity guidance, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," is the binding interpretation. 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), signed December 29, 2022, with the FDA's RTA authority effective March 29, 2023. The statute is short by design and leaves the operational detail to FDA guidance. The February 3, 2026 final guidance superseded the September 2023 final guidance, which itself superseded the 2018 and 2014 documents. 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, and Humanitarian Device Exemption submissions for cyber devices.
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
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
See also: SBOM End-of-Support, EOL, and Level of Support, CAPA and Medical Device Cybersecurity: Closing the Loop on Vulnerabilities and FDA Deficiencies, and Medical Device Incident Response Plan: FDA Expectations 2026.
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. Almost any modern device with a wired or wireless network interface, an embedded software stack, and any updateable component qualifies. Indirect internet connectivity (through a gateway, a phone app, or a hospital network) counts.
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. For devices that are not cyber devices, a justification explaining why none of the three prongs is met.
Deficiency Pattern
Submissions that assume "no Wi-Fi means not a cyber device" and skip the 524B section. The FDA reads connectivity broadly: a wired Ethernet port, a USB port that exposes a service, a Bluetooth radio, or a companion mobile app are all paths to the internet for 524B(c) purposes.
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: the device contains software, can connect to the internet (directly or indirectly through a gateway, app, or hospital network), and has technological characteristics that could be vulnerable. Most modern devices meet all three. Wired Ethernet, Bluetooth, Wi-Fi, USB exposing services, and companion apps all satisfy the connectivity prong. If you are uncertain, state your determination and reasoning in the submission rather than skipping the section.
Where does the FDA's February 3, 2026 guidance fit relative to 524B?
The statute sets the requirements; the guidance tells you what artifacts satisfy them. The February 3, 2026 final premarket cybersecurity guidance is the binding operational interpretation. 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?
Only if the device still meets the 524B(c) definition through software updateability and a vulnerable technological characteristic. A truly standalone device with no software, no update path, and no data interface is not a cyber device. A device with a USB service port that allows firmware updates or configuration changes usually is, even without Wi-Fi or Ethernet.
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.