On this page
Published: · Updated:
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.
FDA Section 524B has three subsections. 524B(a) sets applicability to 510(k), De Novo, PMA, PDP, and HDE submissions for cyber devices. 524B(b) lists four requirements: a postmarket vulnerability plan (b)(1), secure design processes and update cadence (b)(2), a Software Bill of Materials (b)(3), and future rulemaking (b)(4). 524B(c) defines what qualifies as a cyber device. Every submission maps to these six anchors.
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.
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))
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 (524B(a))
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 (524B(a))
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))
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 (524B(b)(1))
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 (524B(b)(1))
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))
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) (524B(b)(2))
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) (524B(b)(2))
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 (524B(b)(2))
(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))
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 (524B(b)(3))
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 (524B(b)(3))
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))
See also: Does FDA 524B Apply to Legacy Medical Devices?, SBOM EOS, EOL & LoS for FDA 524B, and FDA PCCP Beyond AI: Cybersecurity & Firmware Uses.
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 (524B(b)(4))
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 (524B(b)(4))
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))
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 (524B(c))
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 (524B(c))
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 (524B(c))
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 Will FDA Scrutiny Under 524B Intensify in 2026?
Scrutiny under Section 524B is widening in 2026 beyond simply checking that each artifact exists, toward checking whether the evidence behind each artifact actually holds up. The February 3, 2026 final guidance is the same statute, but reviewers now have more experience applying it, and the deficiency patterns from 2024 and 2025 submissions inform what they probe on the next one.
Four areas are drawing deeper review under this shift:
| Area | What reviewers checked before | What reviewers check now |
|---|---|---|
| Threat model | Presence of a threat model document | Whether the model's elements match the actual architecture and interfaces |
| SBOM | Presence of an SBOM file | Whether the SBOM is machine-readable, covers transitive dependencies, and includes VEX |
| Postmarket plan | A stated commitment to monitor vulnerabilities | Evidence the plan links to CAPA and a working coordinated vulnerability disclosure intake |
| AI-enabled functions | Not previously a distinct review line | Data integrity and model-specific risks such as data poisoning and model evasion |
This shift also reflects the FDA's smaller postmarket workforce turning attention to whether guidance is producing real-world results, not just compliant paperwork. A submission built to satisfy a checklist rather than to describe a verified architecture is the kind of submission this heightened scrutiny is designed to catch, since 524B(b)(2)(A) already requires processes that provide reasonable assurance, not just a stated intention.
For manufacturers, the practical response is to treat every 524B artifact as something a reviewer will trace back to the device's actual build and actual operations, not as a document produced once at filing time. An SBOM that regenerates from the real build, a threat model that names the interfaces actually present in the architecture, and a postmarket plan tied to a working CAPA record are what hold up under this level of review. Manufacturers preparing a submission in 2026 should expect fewer passes on documentation that merely states a commitment without the evidence to back it.
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.
If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.
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.
Related 524B posts on this site
Go deeper on individual subsections and edge cases:
- Section 524B(b)(2): what the design and update requirements really demand, the subsection that generates the most deficiencies, unpacked.
- SBOM, EOS, EOL and Level of Support under 524B(b)(3), how support-status fields on your SBOM affect the 524B(b)(3) response.
- Patch and update mechanism testing for 524B, the (b)(2)(B) evidence reviewers expect for signed updates and rollback.
- Documenting update cadence in a 524B submission, how to state the regular cycle and the out-of-cycle expedited path.
- Does 524B apply to legacy medical devices?, applicability for devices in the installed base.
- Does 524B apply to an auto-injector?, worked example of the 524B(c) three-prong test on a combination product.
- FDA AI cybersecurity threats and 524B, how AI/ML functionality changes the 524B(b)(2) threat model.
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. 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.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.
