By Phil Englert
In today’s interconnected healthcare environment, the cyber resilience of medical devices is inseparable from patient safety. As cyber threats increasingly target embedded systems and clinical networks, HTM professionals are on the front lines of safeguarding device integrity.
One of the most promising tools in this effort is the Software Bill of Materials (SBOM). Much like a parts list for software, an SBOM provides visibility into the components that make up a medical device’s software stack. For HTM teams, SBOMs offer a practical, actionable way to assess risk, streamline procurement, and respond to vulnerabilities ultimately supporting safer, more resilient care delivery.
An SBOM is a formal record of the software components, libraries, and dependencies that are included in a software product. For medical devices, this means knowing what open-source and proprietary code is embedded in the firmware, operating system, or application layer. SBOMs are machine-readable and standardized, enabling automated analysis and integration into cybersecurity workflows.
Two key use cases for SBOMs in HTM are procurement and vulnerability management. HTM teams can use SBOMs to evaluate the security posture of devices before purchase, identifying known vulnerabilities or unsupported components. Once devices are in the environment and new threats emerge (e.g., Log4j or OpenSSL flaws), SBOMs help quickly determine which devices are affected and prioritize mitigation.
The Manufacturer Disclosure Statement for Medical Device Security (MDS2) has long been a staple in HTM risk assessments. While the MDS2 outlines a device’s security capabilities and configurations, it often lacks the granularity needed for software-level analysis. SBOMs complement the MDS2 by providing a detailed inventory of software components, enabling cross-referencing to known vulnerabilities via NIST’s National Vulnerability Database, assessing patching feasibility and vendor responsiveness, and informing compensating controls when direct remediation isn’t possible. Together, the MDS2 and SBOM form a more comprehensive picture of device risk, supporting informed decisions across the device life cycle.
To many in HTM, the concept of an SBOM may feel familiar. In fact, SBOMs are often compared to Material Safety Data Sheets (MSDS), which list the chemical contents and handling precautions for physical products. Just as an MSDS helps facilities manage chemical risks, SBOMs help manage software risks. Both documents promote transparency from manufacturers, enable informed handling and response, and support compliance with safety regulations. I like this analogy for bridging understanding across clinical engineering, IT and procurement teams.
For medical device manufacturers, SBOMs are no longer optional. In the U.S., Section 524B of the Federal Food, Drug, and Cosmetic Act, enacted under the 2023 Consolidated Appropriations Act, requires manufacturers to provide SBOMs as part of premarket submissions for cyber devices. The FDA’s final guidance (October 2023) mandates that SBOMs be included in submissions starting October 2024, with enforcement ramping up in 2025.
In the European Union, the Medical Device Regulation (EU MDR) also emphasizes cybersecurity and postmarket surveillance. While not SBOM-specific, the MDR’s focus on software life cycle management and risk mitigation aligns with SBOM principles.
These regulations underscore the need for HTM teams to understand and utilize SBOMs as part of their compliance and risk management strategies. During procurement, SBOMs can be used to screen for high-risk components like outdated libraries, compare vendors’ software hygiene and patching practices, and inform contract language around cybersecurity support. For example, a hospital evaluating two infusion pumps might find that one includes a deprecated Java library with known CVEs, while the other uses a more secure alternative. This insight can influence purchasing decisions and long-term support planning.
When a new vulnerability is disclosed, time is critical. SBOMs allow HTM teams to rapidly identify affected devices, coordinate with vendors for patches or mitigations, and document risk decisions for auditors and regulators. When the 2021 Log4j vulnerability crisis, organizations with SBOMs were able to quickly identify which devices used the affected library and take action. Those without SBOMs faced delays, uncertainty, and increased risk exposure.
Managing cyber risks through Software Bill of Materials (SBOMs) requires specialized tools for data quality evaluation and vulnerability correlation/prioritization because SBOMs are only as useful as the accuracy, completeness, and actionable insights they provide. SBOMs list software components, versions, and dependencies but not all SBOMs are created equal. Tools are needed because SBOMs can contain hundreds or thousands of components and vulnerability databases are vast and constantly changing. Issues like incorrect metadata, ambiguous entries, or missing components undermine risk analysis and vulnerability tracking. Reliable SBOMs enable shared understanding of software risks across clinical, HTM and IT teams. Automated SBOM analysis is a cornerstone of scalable medical device cybersecurity.
For HTM professionals, SBOMs represent far more than a compliance checkbox, they’re a strategic lever for advancing patient safety and operational resilience. When embedded into procurement workflows, risk assessments, and vulnerability management, SBOMs empower HTM teams to proactively identify software risks, streamline coordination with IT and clinical stakeholders, and uphold the integrity of care environments. As cyber threats grow more sophisticated, pairing SBOMs with tools like the MDS2 becomes essential for sustaining secure, transparent, and trustworthy medical device ecosystems.
