Section 524B (FD&C Act)
Ensuring Cybersecurity of Devices
Legal Requirement: This regulation is legally binding and must be complied with for US market access. Non-compliance can result in regulatory action, including warning letters, import detentions, and product recalls.
Overview
Scope
Section 524B of the Federal Food, Drug, and Cosmetic (FD&C) Act was enacted as part of the Consolidated Appropriations Act (2023 Omnibus) and codifies cybersecurity requirements for medical devices. It grants FDA explicit statutory authority to require cybersecurity documentation as part of premarket submissions. The section applies to "cyber devices" — devices that include software, connect to the internet, or contain technology considered to be vulnerable to cybersecurity threats.
Applicability
Section 524B applies to any person submitting a premarket application (510(k), De Novo, PMA, HDE, or PDP) for a "cyber device." A cyber device is defined as a device that: (1) includes software validated, installed, or authorized by the sponsor as a device or in a device, (2) has the ability to connect to the internet, and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. This broad definition covers most modern medical devices with software.
Why It Matters
Section 524B is the legal teeth behind FDA's cybersecurity enforcement. Before this law, FDA cybersecurity guidance was non-binding — manufacturers could technically ignore it. Now, cybersecurity documentation is a statutory submission requirement. FDA can refuse to accept (RTA) submissions that lack the required cybersecurity information. This is the first time cybersecurity has been written into U.S. law for medical devices, and it signals that Congress considers device cybersecurity a matter of public health and national security.
Key Concepts
- "Cyber device" statutory definition and determination criteria
- Mandatory Software Bill of Materials (SBOM) submission
- Required plans to monitor, identify, and address post-market vulnerabilities
- Required plans for coordinated vulnerability disclosure
- Demonstration of "reasonable assurance" of cybersecurity
- FDA Refuse-to-Accept (RTA) authority for non-compliant submissions
- Statutory requirement for timely security patches and updates
- Manufacturer obligation for ongoing cybersecurity monitoring
- Transition period and enforcement timeline for existing devices
Congress enacted 524B as part of the 2023 Omnibus bill after years of voluntary cybersecurity guidance proved insufficient. The healthcare sector remains one of the most targeted industries for cyberattacks.
Section 524B is a landmark. For the first time ever, cybersecurity for medical devices is written into U.S. law — not guidance, not recommendations, LAW. This means FDA doesn't have to politely suggest you include an SBOM. They can legally refuse your submission if you don't. If your regulatory team hasn't read this statute, they're already behind.
🔑 Key Takeaways
- →The "cyber device" definition is deliberately broad. If in doubt, assume your device qualifies.
- →Start SBOM generation NOW, even if your next submission is months away. It takes time to get right.
- →Your coordinated disclosure plan needs to exist before someone finds a vulnerability — not after.
- →Patch capability must be designed into the device architecture. It cannot be added later.
- →"Reasonable assurance" is the legal standard — document everything to meet this bar.
— ER | medev.ai
Building better devices, together.
Statutory Requirements
Cyber Device Determination
The first step is determining whether a device meets the statutory definition of a "cyber device." The three-prong test requires that the device: (1) includes software, (2) has internet connectivity capability, and (3) contains technology that could be vulnerable to cybersecurity threats. Most modern connected medical devices will meet this definition.
Software Bill of Materials (SBOM)
Section 524B requires every premarket submission for a cyber device to include a Software Bill of Materials. The SBOM must list all software components, including commercial, open-source, and off-the-shelf components. This is a statutory mandate — not a recommendation. The SBOM must be machine-readable and meet NTIA minimum element requirements.
Post-Market Vulnerability Management Plan
Manufacturers must submit a plan to monitor, identify, and address cybersecurity vulnerabilities and exploits in a "reasonably justified regular cycle." This plan must include: processes for monitoring new vulnerabilities, timelines for patch deployment, out-of-cycle update procedures for critical vulnerabilities, and procedures for notifying users of security updates.
Coordinated Vulnerability Disclosure
Manufacturers must submit a plan for coordinated vulnerability disclosure, including: a process for receiving vulnerability reports from security researchers, timeline commitments for acknowledgment and remediation, public disclosure procedures, and coordination with CISA, FDA, and ISAOs.
Reasonable Assurance of Cybersecurity
Manufacturers must demonstrate that the device provides a "reasonable assurance" of cybersecurity. This is evaluated based on the device's design, testing, and documentation — including the SPDF process, threat model, risk assessment, security testing, and post-market plans described in the FDA cybersecurity guidance.
Patch and Update Capability
Cyber devices must be designed to allow post-market security updates and patches. The manufacturer must demonstrate technical capability to deliver updates and document the process for deploying them. Devices that cannot receive security updates face heightened regulatory scrutiny.
Compliance Roadmap
Assess Cyber Device Status
Determine if your device meets the statutory definition of a "cyber device" using the three-prong test. Use the Cyber Device Classification tool on medev.ai for a guided assessment. Document your determination rationale.
Integrate SBOM Generation into Build Process
Implement automated SBOM generation in your software build pipeline. Choose a format (SPDX or CycloneDX) and tooling (Syft, FOSSA, Snyk, or similar). Ensure the SBOM captures all dependencies, including transitive dependencies.
Establish Vulnerability Monitoring
Set up continuous vulnerability monitoring by linking your SBOM to vulnerability databases (NVD, CVE). Implement automated alerting for newly discovered vulnerabilities in your device components. Define response timelines by severity level.
Create Coordinated Disclosure Procedure
Publish a vulnerability disclosure policy (VDP) including: security contact information (security@yourcompany.com), expected response timelines, safe harbor language for good-faith researchers, and coordination procedures with FDA and CISA.
Design Patch/Update Architecture
Ensure your device architecture supports secure over-the-air or manual security updates. Implement secure boot, code signing, and rollback capabilities. Document your update deployment process and validation procedures.
Document Reasonable Assurance Evidence
Compile evidence of cybersecurity assurance including: SPDF documentation, threat model, security test results, SBOM with known vulnerability analysis, post-market plan, and coordinated disclosure plan. Organize per the eSTAR cybersecurity section.
Common Challenges & Solutions
Determining if a device is a "cyber device"
If your device has software AND can connect to any network (Wi-Fi, Bluetooth, cellular, Ethernet), it is very likely a cyber device. The definition is intentionally broad. When in doubt, treat your device as a cyber device.
Legacy devices that cannot receive updates
For devices already on the market, create a plan to either: (a) add update capability via a design change, or (b) document compensating controls for the healthcare environment. New submissions for devices without update capability face significant risk of RTA.
Open-source component tracking for SBOM
Use Software Composition Analysis (SCA) tools to automatically identify all open-source components, including transitive dependencies. Manual tracking is insufficient for compliance — automation is essential for accuracy and ongoing maintenance.
Related Regulations
FDA Cybersecurity Guidance
Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
The finalized guidance provides the detailed implementation expectations for Section 524B requirements
21 CFR Part 820
Quality System Regulation
Section 524B requirements integrate with QSR design controls and post-market processes
Related Standards
IEC 81001-5-1
Security — Activities in the product life cycle
Provides the framework for SPDF implementation required by 524B
ANSI/AAMI SW96
Medical device security — Security risk management
FDA-recognized standard for cybersecurity risk management process
IEC 62304
Medical device software — Software life cycle processes
Software lifecycle integrates with cybersecurity requirements from 524B
Resources
Official Resources
Implementation Tools
Legal Notice: This page provides implementation guidance and educational content only. The actual regulation text is the legally binding document. Always refer to the official regulation published in the Code of Federal Regulations (CFR) and FDA guidance documents for compliance purposes.