Last reviewed: May 1, 2026
Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023, gave the FDA explicit statutory authority over medical device cybersecurity. This guide explains what the law requires, how the February 2026 final guidance operationalizes it, and what evidence reviewers expect in your submission.
Last reviewed: May 2026 against the FDA final guidance issued February 26, 2026.
1. What Section 524B Actually Says
Section 524B applies to any sponsor submitting an application for a cyber device. It requires the sponsor to:
- Submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure (CVD).
- Design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and to make updates and patches available on a reasonably justified regular cycle and out-of-cycle for critical vulnerabilities.
- Provide a software bill of materials, including commercial, open-source, and off-the-shelf components.
- Comply with other requirements the FDA establishes by regulation to demonstrate reasonable assurance of cybersecurity.
These are statutory duties, not guidance suggestions. Failure to include them is grounds for Refuse-to-Accept.
2. The Section 524B(c) Definition of a "Cyber Device"
A "cyber device" is any device that:
- Includes software validated, installed, or authorized by the sponsor as part of the device;
- Has the ability to connect to the internet; and
- Contains technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.
In practice this captures nearly every modern Class II and Class III device — anything with Wi-Fi, Bluetooth, cellular, USB-to-host, or cloud connectivity. SaMD is included. See SaMD cybersecurity requirements.
3. Statutory Duty One — Vulnerability Monitoring and Disclosure
Your submission must include a plan that covers:
- Sources monitored (NVD, CISA KEV, vendor advisories, OSV.dev, internal pen-test feedback)
- Cadence of monitoring and triage
- Severity scoring (CVSS v3.1 / v4.0, EPSS, KEV-aware)
- Coordinated Vulnerability Disclosure intake — a public channel (security.txt, dedicated email, or third-party platform) and a stated response SLA
- Customer notification mechanism
See our CVD program page and VDP/CVD workflows guide.
4. Statutory Duty Two — Designed to Be Updated and Patched
This is the design-input requirement most sponsors underestimate. The device architecture must demonstrably support:
- Authenticated, integrity-protected updates (signed firmware, signed containers, app-store distribution)
- Out-of-cycle patching for critical vulnerabilities
- A patch SLA documented in the vulnerability management plan
- Operating organization notification of available updates
Devices designed without update infrastructure cannot retrofit compliance — reviewers will require redesign. Build patchability into the architecture from day one.
5. Statutory Duty Three — Software Bill of Materials
The SBOM must include commercial, open-source, and off-the-shelf software components. The February 2026 final guidance interprets this as:
- Machine-readable format (CycloneDX or SPDX)
- NTIA minimum elements (supplier, component, version, unique identifier, dependency relationship, author, timestamp)
- Known-vulnerability assessment as of the submission date
- A plan to maintain the SBOM postmarket
See SBOM vulnerability management and the CycloneDX vs SPDX comparison.
6. Statutory Duty Four — "Other Requirements" (the Final Guidance)
The "other requirements" hook is what gives the February 2026 final guidance teeth. The guidance now treats the following as expected evidence for every cyber device:
- Security risk management file aligned to AAMI SW96:2023
- Threat model (STRIDE or TARA) with architecture views
- Secure Product Development Framework evidence (IEC 81001-5-1, NIST SSDF)
- Penetration test report covering all external interfaces and protocols
- Cryptographic inventory
- Labeling for cybersecurity (controls, SBOM pointer, support lifecycle, CVD intake)
For the full deliverable list and ordering, see the premarket cybersecurity submission checklist.
7. What Changed Between the 2023 Draft and the 2026 Final Guidance
Notable shifts in the final guidance:
- SBOM expectations sharpened — VEX is strongly encouraged; postmarket maintenance plan is explicit
- AAMI SW96 elevated as the anchor standard for security risk management (replacing the earlier reliance on TIR57 alone)
- Patchability clarified as a design-input requirement, not a postmarket aspiration
- Operating-environment labeling expanded for SaMD and cloud-connected devices
- AI/ML coverage tied into the PCCP framework — security-relevant model updates must be in scope
8. How Section 524B Interacts With Other Authorities
- 510(k) / De Novo / PMA: 524B is layered on top — it does not replace substantial equivalence or PMA evidence
- QSR / 21 CFR 820: SPDF activities live inside design controls and CAPA
- HIPAA: distinct authority (data protection vs device safety); SBOM and VEX often inform a hospital's HIPAA risk analysis but are not HIPAA deliverables
- EU MDR / MDCG 2019-16: parallel set of expectations; the same evidence package usually satisfies both with formatting changes
9. RTA Triggers Tied Directly to 524B
The fastest paths to a Refuse-to-Accept hold under 524B are:
- No SBOM, or an SBOM that is not machine-readable
- No vulnerability monitoring / CVD plan
- No documented update mechanism
- A cyber-device determination that says "no" without justification when the device is plainly internet-connected
10. Enforcement Posture
The FDA has stated that 524B is a statutory requirement and that the agency does not intend to issue formal "warning letters" before declining to accept non-compliant submissions. In other words: the enforcement happens at the submission gate, not after.
Frequently asked questions
When did Section 524B take effect?
The amendment was enacted December 29, 2022 (Consolidated Appropriations Act, 2023). The FDA began enforcing the submission requirements for cyber devices on October 1, 2023, and refined expectations in the February 2026 final guidance.
Does 524B apply to legacy devices?
524B applies to new submissions. Legacy devices already on the market are governed by the postmarket cybersecurity guidance and the manufacturer's QMS — but any new submission (including a change that requires a new 510(k)) brings the device under 524B.
Is my device a "cyber device"?
If it includes manufacturer-authorized software, can connect to the internet (directly or through a paired companion), and has any cyber-relevant characteristic, yes. Document the determination either way; reviewers will challenge a "no" on connected devices.
Do I need an SBOM if my device has no third-party software?
You still need an SBOM listing your first-party components. In practice, every device includes third-party software (libraries, OS, drivers); reviewers expect the SBOM to reflect that reality.
What if I cannot meet the patch SLA?
Document the constraint (implantable hardware, regulated firmware paths), the compensating controls (network segmentation, monitoring), and the customer notification process. "We cannot patch quickly" is acceptable when justified; silence on the topic is not.
How Blue Goat Cyber helps
Blue Goat Cyber maps every 524B duty to a concrete deliverable and executes the work — SBOM, threat model, pen test, vulnerability management, and CVD program — through FDA premarket cybersecurity services and postmarket monitoring.
Sources & primary references
- Section 524B, Federal Food, Drug, and Cosmetic Act (21 U.S.C. § 360n-2)
- Consolidated Appropriations Act, 2023, Pub. L. 117-328, Div. FF, Title III, § 3305
- FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (final guidance, February 2026)
- AAMI SW96:2023; IEC 81001-5-1:2021; NIST SP 800-218
- NTIA, Minimum Elements for an SBOM