On December 29, 2022, the Consolidated Appropriations Act of 2023 was signed into law, and tucked inside this massive spending bill was a provision that changed medical device cybersecurity forever. Section 3305 amended the Federal Food, Drug, and Cosmetic Act to require that medical device manufacturers submit cybersecurity information — including software bill of materials — as part of their premarket submissions to the FDA.
By early 2023, the medical device industry was scrambling to understand what this meant in practice.
What the Law Actually Requires
The new requirements apply to all cyber devices — defined as devices that include software, connect to the internet, or could be vulnerable to cybersecurity threats. For practically every modern medical device, that's the bar. Starting March 29, 2023, manufacturers submitting premarket applications must:
- Submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities in a reasonable time, including coordinated vulnerability disclosure
- Design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure
- Make available postmarket updates and patches to the device and related systems to address known vulnerabilities in a reasonable time
- Provide a software bill of materials, including commercial, open-source, and off-the-shelf software components
This isn't guidance or recommendation. It's law. The FDA can refuse to accept device submissions that don't include this information.
What an FDA-Compliant SBOM Looks Like
The FDA's guidance documents elaborate on what the SBOM should contain. It goes beyond simply listing packages:
Component Information
For every software component, the SBOM should include:
- Component name
- Component version
- Component manufacturer/developer
- Dependency relationships (what depends on what)
- The level at which the component operates (device level, operating system level, application level)
Vulnerability Information
The SBOM should be accompanied by:
- Known vulnerabilities in any component (CVEs)
- Risk assessment for each known vulnerability
- Mitigation strategies for unpatched vulnerabilities
- Support and patch timeline commitments
Format Requirements
The FDA expects SBOMs in machine-readable format. They've indicated support for:
- SPDX (ISO/IEC 5962:2021)
- CycloneDX
Both formats are acceptable, though SPDX has the advantage of being an international standard.
The Challenge for Medical Device Manufacturers
Most medical device manufacturers in early 2023 were not prepared for these requirements. The challenges are significant:
Legacy Software Stacks
Medical devices often run on software that was developed years or even decades ago. Many manufacturers don't have complete records of what open-source components are embedded in their firmware. The devices might run on modified Linux kernels, use old versions of OpenSSL, or include libraries that were incorporated so long ago that no one remembers where they came from.
Creating an accurate SBOM for these devices requires reverse engineering the existing software — extracting binaries, analyzing linked libraries, identifying embedded open-source components.
Deep Dependency Trees
A modern medical device's software might directly include 50 components, but those 50 components have their own dependencies. A complete SBOM might contain hundreds or thousands of entries. For each one, the manufacturer needs to track vulnerabilities and have a plan for patching.
Firmware and Embedded Systems
Unlike a web application that can be updated with a Docker pull, medical device firmware updates require:
- Regulatory review of the update
- Validation and verification testing
- Distribution to devices in the field (many of which aren't connected to the internet)
- Hospital IT team coordination for deployment
Promising "reasonable time" patches for a firmware-based medical device is a fundamentally different commitment than patching a cloud service.
Supply Chain Complexity
Medical devices often incorporate third-party components — both hardware and software — from multiple vendors. A ventilator might use a display component from one vendor, a communications module from another, and a processing unit from a third. Each of those components has its own software with its own dependencies.
The device manufacturer needs SBOMs from all their suppliers, creating a cascading SBOM requirement down the supply chain.
What "Reasonable Time" Means
The law requires addressing vulnerabilities in a "reasonable time" — a deliberately vague standard. The FDA's guidance provides some framework:
- Critical vulnerabilities: Should be addressed as soon as possible, with compensating controls deployed immediately
- High-severity vulnerabilities: Should be addressed in the next planned update cycle
- Lower-severity vulnerabilities: Can be addressed through routine maintenance
The key is having a documented process. The FDA is looking for evidence that manufacturers have systems in place to identify, assess, and remediate vulnerabilities on an ongoing basis — not just at the time of submission.
Impact Beyond the FDA
The FDA's SBOM requirement is significant not just for medical devices but for the broader software industry:
Regulatory Precedent
The FDA is the first U.S. federal agency to make SBOMs a legal requirement for product approval. This sets a precedent that other regulatory bodies are watching. NIST, CISA, and sector-specific regulators are likely to follow with similar requirements for their domains.
Market Pressure
When the FDA requires SBOMs, every company in the medical device supply chain needs to produce them. This creates market pressure on software vendors, RTOS providers, and component manufacturers to support SBOM generation.
Maturity Forcing Function
The requirement forces an entire industry to build SBOM capabilities, which raises the security maturity of the whole sector. Companies that build these capabilities for FDA compliance will likely apply them to all their products.
Practical Steps for Compliance
1. Inventory Existing Software
Start with what you know. Catalog all software components in your devices, including the operating system, middleware, libraries, and application code.
2. Choose an SBOM Format and Tooling
Pick SPDX or CycloneDX and select tools that can generate and manage SBOMs in that format. Standardize across your organization.
3. Integrate SBOM Generation into Your Build Process
SBOMs should be generated automatically as part of the build, not manually assembled after the fact. This ensures accuracy and makes ongoing maintenance feasible.
4. Establish Vulnerability Monitoring
Set up continuous monitoring for vulnerabilities in all components listed in your SBOMs. This needs to be an ongoing process, not a point-in-time check.
5. Document Your Patch Process
Create and document a process for assessing and remediating vulnerabilities in deployed devices. Include timelines, responsibilities, and escalation procedures.
How Safeguard.sh Helps
Safeguard.sh is purpose-built for the SBOM challenges that FDA compliance presents:
- Automated SBOM Generation: Safeguard.sh generates SBOMs in both SPDX and CycloneDX formats, automatically detecting components including deeply nested dependencies that manual processes miss.
- Continuous Vulnerability Monitoring: Once your SBOM is generated, Safeguard.sh continuously monitors every component against CVE databases, NVD, and vendor security advisories, alerting you when new vulnerabilities affect your devices.
- Compliance Reporting: Safeguard.sh generates FDA-ready reports that document your software components, known vulnerabilities, risk assessments, and remediation status.
- Supply Chain Visibility: Safeguard.sh tracks dependencies across your entire product portfolio, giving you a single pane of glass for understanding your software supply chain exposure.
The FDA's SBOM mandate is just the beginning. Organizations that build robust SBOM practices now will be ahead of the curve as similar requirements spread across industries.