
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: the device must meet all three criteria, and the submission must be within Section 524B(a).
- 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.
Section 524B has subsections (a) through (e), including exemption and guidance provisions in (d) and (e). 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 transition period for deferring refuse-to-accept decisions based solely on 524B ended, as described in 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 policy date does not establish the date of any individual rejection.
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. The opening text of 524B(b)(2) requires processes and procedures providing reasonable assurance that the device and related systems are cybersecure and requires postmarket updates and patches. Subparagraph (A) addresses known unacceptable vulnerabilities on a reasonably justified regular cycle; subparagraph (B) addresses critical vulnerabilities that could cause uncontrolled risks, as soon as possible out of cycle.
Process Evidence (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.
Update and Patch Evidence (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))
Process evidence belongs to the opening obligation in Section 524B(b)(2). Subparagraph (A) concerns a reasonably justified regular update cycle for known unacceptable vulnerabilities; (B) concerns critical vulnerabilities that could cause uncontrolled risks and need out-of-cycle updates as soon as possible.
Section 524B(b)(2)(A) addresses the regular cycle for known unacceptable vulnerabilities; (B) addresses critical vulnerabilities that could cause uncontrolled risks, as soon as possible out of cycle.
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))
An SBOM covering commercial, open-source, and off-the-shelf software components, with content verified against the submitted device build; the FDA recommends machine-readable, industry-accepted formats, optionally 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. Missing device-specific vulnerability assessments; VEX itself is optional. 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?, FDA PCCP Beyond AI: Cybersecurity & Firmware Uses, and Documenting Update Cadence for an FDA Submission.
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; do not treat optional VEX or a specific SBOM format as a current FDA requirement.
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))
The definition requires all three criteria. Direct or indirect internet connectivity can satisfy the connectivity criterion, including a path through a companion app or gateway. A USB, serial, JTAG, NFC, or other software interface alone does not establish internet capability. Evaluate the actual device, related systems, and environment of use rather than treating every interface as sufficient.
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 which required criterion is not met, with specific attention to the connectivity prong.
Deficiency Pattern (524B(c))
A lack of Wi-Fi does not establish non-applicability: assess indirect internet paths through apps, gateways, and related systems. Conversely, a software interface by itself does not establish that all three criteria are met.
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 addresses the existing 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 supports device-specific vulnerability assessment (VEX is optional) |
| 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 |
The statute requires processes and procedures that provide reasonable assurance of cybersecurity under Section 524B(b)(2). A stated intention alone does not demonstrate that the actual architecture and operational processes support that assurance.
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 optional 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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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.
Related reading: Breakthrough Device Designation and Cybersecurity Requirements, What Is a Medical Cyber Device? FDA Cyber-Device Definition Explained.
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?
There is no FDA-wide deficiency-frequency dataset cited here that ranks the subsections. Review process evidence under (b)(2), the SBOM under (b)(3), and the vulnerability-management plan under (b)(1) against the specific concerns raised in the letter.
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. Do not infer announced rulemaking from the existence of this statutory authority.
How do I know if my device meets the 524B(c) cyber device definition?
Apply all three statutory criteria: sponsor-authorized software, ability to connect to the internet, and sponsor-authorized technological characteristics vulnerable to cybersecurity threats. Check both direct and indirect internet paths. An interface such as USB or JTAG alone is not a complete applicability determination.
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?
Not automatically. Evaluate all three criteria and the covered submission pathway. A device without a network interface may still connect indirectly through related systems, but a local software interface alone does not prove internet capability. Document the actual connection paths and the applicability rationale.
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 process and update obligations, unpacked.
- Postmarket SBOM Maintenance for Medical Devices, how component support information recommended by the FDA informs lifecycle planning.
- Patch and update mechanism testing for 524B, the (b)(2)(B) evidence FDA guidance recommends 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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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 has red-team and DoD cyberwarfare experience. 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. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. 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.




