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.
Visual Guide
FDA Section 524B & Premarket Cybersecurity Roadmap
Statutory requirements for Cyber Devices, SPDF, SBOM, and eSTAR submissions
Cyber Device Determination
Evaluate whether the device meets the statutory definition under Section 524B of the FD&C Act. Meets all 3 prongs? Premarket cybersecurity submission is legally mandatory.
Submission Verification Criteria
- Prong 1: Includes software validated, installed, or authorized by sponsor
- Prong 2: Has ability to connect to internet (Wi-Fi, BLE, Cellular, Cloud)
- Prong 3: Contains technology that could be vulnerable to cybersecurity threats
FDA Reviewer Scrutiny / RTA Risk
Statutory Requirements
Cyber Device Determination (Section 524B(c))
The three-prong statutory test determines whether a device is a "cyber device": (1) includes software validated, installed, or authorized by the sponsor, (2) possesses internet or network connectivity capability, and (3) contains technological characteristics vulnerable to cybersecurity threats. All cyber devices must satisfy statutory submission requirements under Section 524B.
Statutory Prong 1: Reasonable Assurance & Updates/Patches (Section 524B(b)(1))
Sponsors must submit a plan and procedures to maintain reasonable assurance that the device and related systems are cybersecure. This mandates technical design capability and documented procedures to make available updates and security patches on a reasonably justified regular cycle, and promptly in the case of critical vulnerabilities.
Statutory Prong 2: Post-Market Monitoring & CVD (Section 524B(b)(2))
Sponsors must provide processes and procedures to monitor, identify, and address postmarket vulnerabilities in a timely manner. This includes coordinated vulnerability disclosure (CVD) procedures, threat intelligence ingestion, and adherence to remediation timeframes derived from FDA Postmarket Cybersecurity Guidance (e.g. 30 days to disclose/remediate controlled vulnerabilities impacting clinical performance, and 60 days for non-controlled issues).
Statutory Prong 3: Software Bill of Materials (SBOM) (Section 524B(b)(3))
Every premarket submission for a cyber device must provide a comprehensive, machine-readable Software Bill of Materials (SPDX or CycloneDX). The SBOM must cover first-party software, commercial off-the-shelf (COTS) libraries, open-source dependencies, and firmware, complying with NTIA minimum element standards.
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.
Connected Knowledge Graph (Local View)
Connected standards, regulations, and workflows for Section 524B (FD&C Act)
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.