For a long time the FDA's role in software security was described as "advisory." The agency published guidance documents, hosted workshops, and nudged manufacturers toward better practices, but the enforcement tools were limited to the general postmarket authority the FDA has over medical devices. That changed in December 2022, when the Consolidated Appropriations Act added Section 524B to the Federal Food, Drug, and Cosmetic Act, giving the FDA explicit statutory authority to require cybersecurity information for cyber devices.
The practical effect has been significant. As of October 2023, the FDA has refused to accept premarket submissions that do not include the cybersecurity documentation required by Section 524B, and the September 2023 guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" has become the working reference for what those submissions look like. For any team shipping connected healthtech -- whether a Class II wearable, a Class III implantable, a hospital infusion pump, or a software-as-a-medical-device diagnostic tool -- this is now the baseline.
What Section 524B Actually Requires
Section 524B applies to cyber devices, defined as devices that include software validated, installed, or authorized by the sponsor, have the ability to connect to the internet, and contain technological characteristics that could be vulnerable to cybersecurity threats. The definition is broad enough to sweep in almost everything connected, from blood glucose monitors to MRI consoles.
The statutory requirements fall into four buckets. First, the sponsor must submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities. Second, the sponsor must design, develop, and maintain processes and procedures to provide reasonable assurance that the device and related systems are cybersecure. Third, the sponsor must make available updates and patches to the device and related systems. Fourth, the sponsor must provide a software bill of materials, including commercial, open-source, and off-the-shelf software components.
The SBOM requirement is the most operationally visible change. The FDA has been explicit that it expects an SBOM in a machine-readable format, and its guidance references SPDX, CycloneDX, and SWID as acceptable formats. The SBOM must cover first-party software, third-party commercial components, and open-source dependencies down to the level of detail needed to identify vulnerabilities.
The 2023 Premarket Guidance
The September 2023 guidance fleshes out what the FDA expects in a submission. It replaces the 2014 and 2018 guidances and significantly raises the bar. The guidance describes a Secure Product Development Framework that includes threat modeling, security risk management, security architecture documentation, security testing, and postmarket vulnerability management.
A conforming submission includes a security risk management report that traces threats through to mitigations, an architecture view that shows global and multi-patient harm paths, vulnerability assessment documentation including SBOM analysis, and a cybersecurity management plan that covers the product lifecycle. The guidance is explicit that the SBOM is not a standalone artifact -- it must be analyzed, the analysis must flow into the risk assessment, and the postmarket plan must describe how new vulnerabilities in SBOM components will be evaluated and addressed.
This means that for healthtech engineering teams, SBOM generation is the start of the obligation, not the end. The submission is judged on the quality of the analysis and the credibility of the postmarket monitoring plan. Reviewers at the FDA's Center for Devices and Radiological Health look for evidence that the manufacturer understands its own supply chain -- knows which components are in each firmware variant, which versions are shipping in the field, and which newly disclosed vulnerabilities would affect which installed units.
The Postmarket Side: 21 CFR Part 820 and the New QMSR
The Quality Management System Regulation, which finalizes in February 2026 as a replacement for 21 CFR Part 820, aligns US medical device QMS expectations with ISO 13485. For cybersecurity, this means design controls, purchasing controls, and complaint handling all need to address software supply chain risk explicitly.
Design controls require that security requirements be captured, that risk analysis include cybersecurity threats, and that verification and validation cover security claims. Purchasing controls require that suppliers of software components be qualified and that supplier changes be evaluated. Complaint handling ties into MDR reporting under 21 CFR Part 803, which now explicitly contemplates cybersecurity events as reportable when they cause or could cause serious injury or death.
The interplay with the FDA's Cybersecurity Safety Communications regime is also important. When a vulnerability in a widely used component creates patient safety risk -- the urgent/11 VxWorks issues in medical devices, for example, or the Ripple20 issues in Treck TCP/IP -- the FDA has increasingly issued coordinated safety communications that name affected manufacturers and expected remediation timelines. Being on one of these lists is painful, and the difference between a quick remediation and a protracted one often comes down to SBOM quality.
Third-Party Components and the OTS Question
Off-the-shelf software, particularly open source, is where most healthtech teams struggle. A typical connected device firmware contains a real-time operating system, a TCP/IP stack, cryptographic libraries, compression libraries, a BLE stack if applicable, and dozens of smaller utilities. The FDA does not forbid the use of OTS software, but it does expect the manufacturer to understand what is included, to track vulnerabilities, and to have a plan for updates.
The 2023 guidance strengthened expectations around third-party managed services and cloud components too. A device that sends telemetry to a cloud backend is not just a device -- it is a system, and the SBOM and threat model need to cover the backend as well. The FDA has accepted varied approaches here, from full-stack SBOMs to layered attestations from cloud providers, but it will push back if the submission tries to draw the boundary too narrowly.
Interaction With HIPAA and State Law
Federal cybersecurity rules for medical devices do not replace HIPAA obligations. Any healthtech product that handles protected health information is subject to the HIPAA Security Rule, which has its own information system activity review and risk analysis requirements. The HHS Office for Civil Rights has been increasingly active on the enforcement side, and supply chain incidents affecting healthcare entities frequently generate HIPAA breach notifications alongside FDA safety communications.
State laws add another layer. New York's SHIELD Act, California's CMIA, and Texas's HB 300 all impose notification and security obligations on entities handling medical information, and several states have added specific requirements around connected medical device security. The federal preemption story is complicated and manufacturers generally assume they have to meet the strictest applicable rule.
Operationalizing the Requirements
The teams that are shipping smoothly under the new FDA regime have a few things in common. They treat SBOM generation as a build artifact, produced automatically for every firmware build and versioned with the firmware itself. They map each component to a vulnerability feed and have an on-call rotation for triaging new CVEs against their fleet. They maintain a field inventory -- which firmware version is running on which installed unit -- so that when a vulnerability does require action, they can target the remediation precisely.
They also invest in the documentation layer. The FDA submission is a narrative, and the narrative is easier to write when the underlying data is clean. Threat models reference the architecture, the architecture references the SBOM, and the SBOM references the vulnerability assessment. When a reviewer asks a question, the answer is a link rather than a scramble.
How Safeguard Helps
Safeguard produces FDA-ready SBOMs in SPDX and CycloneDX directly from medical device firmware builds, enriches them with KEV and ICS-CERT vulnerability intelligence, and tracks which firmware versions are deployed in the field so postmarket monitoring is grounded in real data. Manufacturers use Safeguard to compile premarket submission artifacts, manage the ongoing vulnerability disclosure workflow that Section 524B requires, and generate the evidence that QSR and QMSR auditors expect. When the FDA issues a safety communication naming a component vulnerability, Safeguard answers "which products and which units in the field are affected" from the same data set.