In January 2025, CISA and the FDA disclosed that certain Contec CMS8000 patient monitors — used in hospitals across the United States — contained a hardcoded backdoor that silently transmitted patient data to a remote IP address and could push unauthorized firmware over the network. No one on the clinical engineering team had built that monitor's firmware from scratch, and almost none of them had a component-level inventory of what was running inside it. That is the core problem a medical device firmware SBOM solves: it turns an opaque, life-critical black box into a list of ingredients that hospitals, manufacturers, and regulators can actually act on when a vulnerability surfaces. As connected infusion pumps, imaging systems, and implantables multiply, firmware transparency is no longer a nice-to-have for IoMT security — it's becoming a legal and clinical necessity, tightly coupled with how the industry runs coordinated vulnerability disclosure.
What is a medical device firmware SBOM, and why is it different from a regular software SBOM?
A medical device firmware SBOM is a machine-readable inventory of every open-source library, RTOS component, third-party driver, and proprietary module baked into a device's firmware image, plus the version and license of each. It differs from a typical application SBOM in three important ways. First, firmware is deeply layered — a single infusion pump might run a real-time operating system like VxWorks or FreeRTOS, a TCP/IP stack, a Bluetooth Low Energy protocol library, and a proprietary control application, all cross-compiled into one binary blob with no build manifest to reference. Second, firmware SBOMs often have to be generated through binary analysis rather than pulled from a package manager, because manufacturers frequently can't produce a clean build-time SBOM for legacy devices that shipped a decade ago. Third, the stakes are different: a vulnerable JavaScript dependency might expose customer data, but a vulnerable firmware component in a ventilator or insulin pump can directly threaten a patient's life, which is why the FDA treats SBOM completeness as a premarket submission requirement rather than a best practice.
What does the FDA actually require for firmware SBOMs today?
The FDA now requires SBOMs as a condition of premarket clearance for "cyber devices" under Section 524B of the FD&C Act, added by the Consolidated Appropriations Act of 2023 and effective March 29, 2023. Since October 1, 2023, the agency has applied a Refuse-to-Accept policy: premarket submissions for connected devices that lack a cybersecurity plan, a vulnerability management process, and a machine-readable SBOM covering all commercial, open-source, and off-the-shelf software components can be bounced back before review even begins. The FDA's guidance leans on the NTIA's "minimum elements" framework — supplier name, component name, version, and dependency relationships — and accepts SPDX or CycloneDX as the standard formats. For manufacturers, this shifted SBOM generation from a post-incident forensic exercise to a day-one artifact that has to be maintained across the device's entire market life, including the years after a product line is discontinued but units remain implanted or deployed in hospitals.
How does coordinated vulnerability disclosure work for connected medical devices?
Coordinated vulnerability disclosure for medical devices runs through a structured pipeline designed to fix a flaw quietly before attackers or the public learn about it, and the Health Information Sharing and Analysis Center (H-ISAC) sits at the center of that pipeline alongside CISA's ICS Medical Advisories program. When a researcher or manufacturer finds a firmware vulnerability, the typical flow is: private disclosure to the manufacturer, triage against a firmware SBOM to determine which product lines and versions are affected, coordination with CISA and the FDA on a public advisory date, and simultaneous release of a patch, mitigation, or compensating control when a patch isn't feasible for a device already implanted in a patient. This is exactly the model that played out with the 2017 St. Jude Medical (Abbott) Merlin@home transmitter case, where the FDA approved a firmware update addressing CVE-2017-9481 and related flaws after MedSec's disclosure to Muddy Waters became public ahead of a coordinated timeline — an outcome regulators cite as a cautionary example of why coordination matters. It also mirrors how the 2019 URGENT/11 vulnerabilities in the IPnet TCP/IP stack, which affected ventilators, infusion pumps, and patient monitors from multiple manufacturers, were disclosed jointly by Armis, CISA, and the FDA with synchronized advisories so hospitals could deploy network segmentation before patches were ready. Without an accurate firmware SBOM identifying exactly which devices used the vulnerable stack, that kind of synchronized, cross-manufacturer response isn't possible.
What is ISO 81001-5-1 and why does it matter for IoMT security?
ISO/IEC 81001-5-1:2021 is the international standard that defines security life cycle requirements for health software and health IT systems, and it matters because it's the first standard to formally weave SBOM management into the medical device development life cycle rather than treating it as a bolt-on compliance task. Published in 2021 as part of the broader IEC 80001 family, 81001-5-1 requires manufacturers to run security risk management, secure design, verification, and — critically — transparency activities including SBOM production and vulnerability disclosure processes, across the full product life cycle from design through end-of-support. It's increasingly cited alongside IEC 62304 (software life cycle) and IEC 62443 (industrial network security) in FDA premarket submissions and EU MDR technical files, because it gives auditors a concrete checklist for questions like "how do you know what's in your firmware" and "what's your process when a component you depend on gets a CVE." For IoMT security programs specifically, 81001-5-1 compliance has become a practical prerequisite for hospital procurement teams, many of whom now ask vendors for both a valid SBOM and evidence of an 81001-5-1-aligned disclosure process before signing a purchase order.
Why do so many hospitals still lack visibility into their device firmware?
Most hospitals still lack firmware visibility because the SBOM obligation sits with manufacturers, but the operational risk sits with hospital biomedical engineering teams who rarely receive machine-readable SBOMs even when one exists. A 2022 survey by the Ponemon Institute found that 53% of connected medical devices in use had a known critical vulnerability, and a large share of hospital security teams reported they couldn't produce an accurate inventory of firmware versions running on devices already in clinical use — some purchased 10 to 15 years earlier, long before SBOM requirements existed. Legacy devices compound the problem: a CT scanner or infusion pump platform can stay in clinical service for 15-20 years, far outliving the vendor's active firmware support window, which means the SBOM a hospital needs to assess exposure to a newly disclosed CVE may never have been generated at all. This gap is precisely why binary-based SBOM generation — extracting a component inventory directly from a shipped firmware image rather than relying on the original build pipeline — has become essential for any IoMT security program covering an existing device fleet, not just new purchases.
How Safeguard Helps
Safeguard closes the gap between what medical device manufacturers are required to produce and what hospitals and regulators actually need to act on. Our platform generates accurate, standards-compliant SBOMs — SPDX and CycloneDX — directly from firmware binaries, so manufacturers get complete component visibility even for legacy devices where original build artifacts no longer exist, and hospital security teams get a real inventory instead of a best-effort spreadsheet. When a new CVE drops, Safeguard automatically cross-references it against every firmware SBOM in your device catalog, flags affected product lines and versions in minutes rather than weeks, and routes findings into your coordinated vulnerability disclosure workflow with the audit trail regulators expect under FDA Section 524B. We map that same evidence to ISO 81001-5-1 life cycle controls, so compliance teams can walk into an audit with continuous, provable answers to "what's in this device" and "how fast can you tell us if it's affected" — the two questions that matter most when the device in question is keeping someone alive.