SBOM Management for Connected Medical Devices: From Compliance Requirement to Security Strategy

The software bill of materials has undergone a remarkable transformation in the medical device industry over the past three years, evolving from an obscure software engineering concept into a regulatory mandate that fundamentally reshapes how medical device manufacturers develop, maintain, and secure the software that powers their products. The catalyst for this transformation was the Consolidated Appropriations Act of 2023, which amended Section 524B of the Federal Food, Drug, and Cosmetic Act to require that manufacturers of cyber devices, defined as devices that include software, can connect to the internet, and could be vulnerable to cybersecurity threats, submit a software bill of materials to the FDA as part of their premarket submissions. This legislative mandate, combined with the FDA’s preexisting guidance on cybersecurity in medical devices and CISA’s evolving SBOM minimum elements framework, has created a regulatory environment where SBOM management is no longer optional for medical device manufacturers but is instead a prerequisite for market access.

Yet the regulatory mandate, while consequential, represents only the most visible dimension of the SBOM’s strategic importance. The deeper value of SBOM management lies in its role as the foundational enabler of medical device cybersecurity. Without a comprehensive, accurate, and continuously maintained inventory of the software components that comprise a medical device, it is impossible to systematically identify which devices are affected when a new vulnerability is disclosed, to assess the risk that a vulnerability poses to patient safety and device function, to prioritize patching and mitigation activities across a portfolio of fielded devices, to communicate vulnerability status to healthcare delivery organizations that depend on accurate risk information for their own security programs, or to demonstrate to regulators that the manufacturer maintains ongoing oversight of the cybersecurity posture of its products throughout their lifecycle. An SBOM that is generated once for regulatory submission and then filed away provides compliance but not security. An SBOM that is continuously maintained, automatically correlated with vulnerability intelligence, and integrated into the manufacturer’s security operations provides both compliance and the operational capability to protect patients from the cybersecurity threats that increasingly target connected medical devices.

This article provides medical device manufacturers and pharmaceutical companies with connected device portfolios a comprehensive guide to implementing SBOM management as a strategic security capability, covering the regulatory requirements, technical implementation, vulnerability management integration, lifecycle management practices, and organizational processes that together constitute a mature SBOM program.

The SBOM Imperative for Medical Device Security

The case for SBOM management in medical devices rests on a straightforward observation: you cannot secure what you cannot see. Modern medical device software is not written entirely by the device manufacturer. It is assembled from a complex supply chain of commercial software components, open-source libraries, operating system elements, middleware frameworks, and third-party modules that together constitute the majority of the code running on any connected medical device. A typical connected medical device might incorporate a real-time operating system, a network protocol stack, a web server for device management, cryptographic libraries for secure communication, database components for local data storage, device driver libraries for hardware interface, and dozens to hundreds of additional open-source and commercial components that provide functionality ranging from data parsing to user interface rendering.

Each of these components carries its own vulnerability history and its own potential for future vulnerability disclosures. When a critical vulnerability is discovered in a widely used component, such as the Log4Shell vulnerability in Apache Log4j that affected systems worldwide in December 2021, organizations that do not maintain SBOMs face the daunting task of manually investigating every product to determine whether the affected component is present. This manual investigation process can take weeks or months, during which vulnerable devices remain unpatched and patients are exposed to risk. Organizations with mature SBOM programs can identify affected products within hours, assess the risk based on how the vulnerable component is used in each device, and initiate mitigation activities with full knowledge of their exposure.

The Connected Device Landscape in Life Sciences

The SBOM imperative extends beyond traditional medical devices to encompass the broader landscape of connected products in the life sciences ecosystem. Pharmaceutical manufacturers increasingly deploy connected devices across the product lifecycle: connected drug delivery devices such as smart inhalers and auto-injectors that communicate with patient smartphone applications and cloud platforms. Connected diagnostic devices used in clinical trials for remote patient monitoring and digital endpoint collection. Connected manufacturing equipment including sensors, controllers, and monitoring systems that increasingly incorporate general-purpose computing platforms. And connected packaging and supply chain devices including temperature monitors, authentication devices, and track-and-trace systems that transmit data to enterprise platforms. Each of these connected products incorporates software components that may be vulnerable to cybersecurity threats, and each should be covered by the manufacturer’s SBOM management program.

Regulatory Framework: FDA, CISA, and IEC 62304

The regulatory framework for medical device SBOMs draws on multiple sources that collectively establish both the legal requirements and the technical expectations for SBOM content, format, and management.

FDA Statutory Requirements

Section 524B of the Federal Food, Drug, and Cosmetic Act, as amended by the Consolidated Appropriations Act of 2023, establishes the statutory requirement for cyber device manufacturers to provide the FDA with a software bill of materials, including commercial, open-source, and off-the-shelf software components. The statute requires the SBOM to be included in premarket submissions and to be maintained and provided to the FDA upon request throughout the device lifecycle. The FDA has indicated that it began refusing to accept premarket submissions that do not include an SBOM for applicable devices, making SBOM submission a de facto requirement for market access.

FDA Guidance on Cybersecurity

The FDA’s guidance document on cybersecurity in medical devices, most recently updated in September 2023, provides additional context for SBOM requirements within the broader framework of device cybersecurity. The guidance establishes expectations for how manufacturers should use SBOMs as part of their comprehensive cybersecurity risk management, including the integration of SBOM data with vulnerability monitoring processes, the inclusion of SBOM information in cybersecurity documentation submitted as part of the premarket review, and the maintenance of SBOM accuracy throughout the device lifecycle as software components are updated, patched, or replaced.

IEC 62304 and Software Lifecycle

IEC 62304, the international standard for medical device software lifecycle processes, provides the quality system framework within which SBOM management operates. The standard requires manufacturers to identify and document the software components that comprise their medical device software, classify software components by safety criticality, maintain configuration management records that track software component versions, and manage the risks associated with software components throughout the product lifecycle. SBOM management extends and operationalizes these IEC 62304 requirements by providing a machine-readable, automatically generated component inventory that can be systematically correlated with vulnerability intelligence and maintained through automated processes.

CISA Minimum Elements

The Cybersecurity and Infrastructure Security Agency has published and progressively refined its definition of minimum elements for software bills of materials, providing a cross-sector framework for SBOM content and practices. The CISA minimum elements define the data fields that each SBOM entry should contain, the practices for SBOM generation and management, and the mechanisms for SBOM distribution and sharing. While the CISA framework is not specific to medical devices, the FDA has referenced it as informing its expectations for SBOM content, making the CISA minimum elements a practical baseline for medical device SBOM programs.

SBOM Minimum Elements and Data Fields

Each entry in a medical device SBOM should contain a defined set of data fields that provide sufficient information to uniquely identify the software component, assess its vulnerability status, and trace its provenance within the software supply chain.

Required Data Fields

Based on the CISA minimum elements framework and FDA expectations, each SBOM entry should include the supplier name identifying the entity that created or maintains the component, the component name as used by the supplier, the component version using the supplier’s versioning scheme, a unique identifier such as a Common Platform Enumeration name or Package URL that enables automated correlation with vulnerability databases, the dependency relationship indicating whether the component is a direct dependency of the device software or a transitive dependency included through another component, and the author of the SBOM data indicating the entity that generated the SBOM entry. Additional data fields that enhance the utility of medical device SBOMs include the component hash providing cryptographic verification of component integrity, the license identifier documenting the software license under which the component is distributed, the component purpose describing the function the component serves in the device, and known vulnerability identifiers listing any currently known CVEs affecting the component version.

SBOM Generation for Embedded Medical Device Software

Generating accurate SBOMs for medical device software presents distinctive challenges compared to SBOM generation for enterprise software or web applications. Medical device software frequently runs on embedded platforms with real-time operating systems, incorporates binary-only components from hardware vendors, uses custom build systems that may not be compatible with standard SBOM generation tools, and includes firmware components at multiple levels of the hardware stack.

Build-Time SBOM Generation

The most accurate approach to SBOM generation captures component information during the software build process, when the build system has full visibility into which components are compiled, linked, and packaged into the device firmware. Build-time SBOM generation should be integrated into the manufacturer’s continuous integration and continuous delivery pipeline so that an accurate SBOM is produced automatically with every build. For embedded medical devices, build-time SBOM generation requires integration with the cross-compilation toolchain used to build firmware for the target hardware platform, the package manager used to resolve and download dependencies, the build configuration system that determines which components and features are included in a specific device variant, and the firmware packaging process that assembles the final device image. The build-time approach should capture both direct dependencies that the device software explicitly declares and transitive dependencies that are pulled in automatically by the build system through dependency resolution.

Binary Analysis for Legacy and Third-Party Components

Not all components in a medical device can be captured through build-time analysis. Binary-only components provided by hardware vendors, pre-compiled libraries, and legacy firmware modules that predate the SBOM generation infrastructure may require binary analysis to identify their constituent software components. Binary analysis tools examine compiled code to identify known open-source components through signature matching, hash comparison, and code pattern recognition. While binary analysis is less precise than build-time analysis, it provides valuable visibility into components that would otherwise be invisible in the SBOM. For medical devices, binary analysis is particularly important for identifying components in the real-time operating system and board support package, which are frequently provided as pre-compiled binaries by the OS vendor or hardware manufacturer.

Multi-Layer SBOM Architecture

Complex medical devices may require a multi-layer SBOM architecture that captures software components at different levels of the device stack. A typical connected medical device might require an application layer SBOM documenting the device application software and its dependencies, an operating system layer SBOM documenting the OS kernel, system libraries, and middleware components, a firmware layer SBOM documenting the low-level firmware components including bootloaders and hardware abstraction layers, and a cloud/mobile layer SBOM documenting the software components in any companion cloud services or mobile applications that are part of the device system. Each layer’s SBOM may be generated through different mechanisms and maintained on different timelines, and the overall device SBOM should integrate information from all layers into a comprehensive view of the device’s software composition.

SBOM Formats: SPDX, CycloneDX, and Interoperability

Two primary SBOM formats have emerged as industry standards: SPDX, the Software Package Data Exchange format maintained by the Linux Foundation, and CycloneDX, the SBOM format developed by the OWASP Foundation. Both formats are recognized by CISA, supported by the FDA’s SBOM expectations, and supported by the major SBOM generation and consumption tools.

SPDX

SPDX is an ISO/IEC international standard (ISO/IEC 5962:2021) that provides a comprehensive specification for communicating software component information including licensing, provenance, and security data. SPDX supports multiple serialization formats including JSON, XML, YAML, and RDF, providing flexibility for different consumption scenarios. Its strength lies in its mature licensing data model, which is particularly valuable for organizations that need to track license compliance across their component portfolio. SPDX 3.0 introduced enhanced support for vulnerability information, build provenance, and AI/ML model documentation, expanding its utility beyond traditional software composition analysis.

CycloneDX

CycloneDX was designed from the ground up for cybersecurity use cases, with a data model that emphasizes vulnerability information, exploitability assessment, and security advisory integration. CycloneDX supports JSON and XML serialization and provides purpose-built extensions for medical device use cases including the ability to document device-specific risk assessments alongside component vulnerability data. CycloneDX’s VEX (Vulnerability Exploitability eXchange) integration provides a standardized mechanism for communicating whether known vulnerabilities in SBOM components are actually exploitable in the context of a specific device, addressing a critical need for medical device manufacturers who must distinguish between theoretical vulnerabilities and actual patient safety risks.

Format Selection for Medical Devices

For medical device manufacturers, the choice between SPDX and CycloneDX should be guided by the organization’s specific requirements and ecosystem. CycloneDX’s native VEX support and cybersecurity-oriented data model make it particularly well-suited for medical device security use cases where vulnerability management integration is the primary driver. SPDX’s ISO standardization and comprehensive licensing model may be preferred by organizations with significant license compliance requirements or regulatory contexts that favor internationally standardized formats. Many organizations maintain the capability to generate and consume both formats, ensuring interoperability with the broadest possible ecosystem of tools, partners, and regulatory stakeholders.

From SBOM to Vulnerability Management

The transformative value of SBOM management is realized when SBOMs are integrated with vulnerability management processes that continuously correlate component data with vulnerability intelligence to identify, assess, and mitigate security risks across the device portfolio.

Continuous Vulnerability Monitoring

SBOM-driven vulnerability monitoring involves continuously comparing the components documented in device SBOMs against vulnerability databases, including the National Vulnerability Database maintained by NIST, vendor-specific security advisories, and commercial vulnerability intelligence feeds. When a new CVE is published that affects a component present in one or more device SBOMs, the monitoring system should automatically identify all affected devices, classify the vulnerability severity based on both the CVSS score and the device-specific context, notify the appropriate product security team, and initiate the vulnerability assessment workflow that determines the appropriate response.

Vulnerability Exploitability Exchange

Not every vulnerability in a device’s SBOM represents an actual risk to the device or its users. A vulnerability in a library function that the device does not call, a network vulnerability in a component that is not exposed to network traffic, or a vulnerability in a feature that is disabled in the device configuration may pose no practical risk despite its presence in vulnerability databases. The Vulnerability Exploitability eXchange (VEX) provides a standardized mechanism for documenting these contextual assessments, enabling manufacturers to communicate to healthcare delivery organizations and regulators whether a known vulnerability is exploitable in the specific context of a given device. VEX statements can indicate that a device is not affected by a vulnerability because the vulnerable component is not present in the device, the vulnerable function is not called, the vulnerability is mitigated by other device controls, or the vulnerability has been remediated through a software update. For medical device manufacturers, VEX is an essential companion to the SBOM because it transforms raw vulnerability data into actionable risk information that stakeholders can use to make informed decisions about device security.

Risk-Based Prioritization

The volume of vulnerabilities disclosed annually, approaching thirty thousand CVEs in 2023, makes it impossible to address every vulnerability with equal urgency. Medical device manufacturers must prioritize vulnerability response based on a risk assessment that considers the severity of the vulnerability as measured by CVSS score and exploitability metrics, the patient safety impact if the vulnerability were exploited on the specific device, the attack vector accessibility considering the device’s network exposure and deployment context, the availability of exploit code or evidence of active exploitation in the wild, and the feasibility and timeline for delivering a remediation to fielded devices. This risk-based prioritization should be documented and defensible, demonstrating to regulators that the manufacturer’s vulnerability management decisions are grounded in systematic risk assessment rather than ad hoc judgment.

Lifecycle SBOM Management for Fielded Devices

Medical devices may remain in clinical use for ten to twenty years after their initial market authorization, and the SBOM must be maintained throughout this lifecycle to provide accurate vulnerability assessment and support ongoing postmarket cybersecurity obligations.

SBOM Versioning and Change Tracking

Every software update to a fielded device, whether a security patch, a bug fix, or a feature enhancement, potentially changes the device’s software composition and should trigger an SBOM update. The SBOM management system should maintain a version history that documents the software composition of every device software version released to the field, track the specific changes between SBOM versions to support vulnerability impact analysis, and link SBOM versions to the device software versions deployed on specific device serial numbers when the manufacturer maintains this level of fleet management capability. This version history is valuable for both security operations, where it enables investigation of whether a specific device instance is affected by a vulnerability based on its installed software version, and regulatory compliance, where it demonstrates the manufacturer’s continuous oversight of device software composition.

End-of-Life SBOM Considerations

When components in the device SBOM reach their end of support and will no longer receive security patches from their suppliers, the manufacturer faces a decision about whether to replace the component, accept the residual risk with compensating controls, or plan for device end-of-life. The SBOM provides the visibility needed to anticipate these end-of-support events through proactive monitoring of component support timelines, enabling the manufacturer to plan component replacements before support ends rather than reacting to vulnerability disclosures after support has already ended. For connected medical devices with long field lifetimes, proactive component lifecycle management based on SBOM data is essential for maintaining device security throughout the product’s operational life.

Software Supply Chain Governance

SBOM management is a cornerstone of software supply chain governance for medical device manufacturers because it provides the visibility needed to assess, monitor, and manage the risks inherent in the use of third-party software components. A mature software supply chain governance program uses SBOM data to inform component selection decisions, ongoing risk monitoring, and supplier management practices.

Component Selection and Approval

Before a new software component is incorporated into a medical device, it should be evaluated against defined criteria that consider the component’s vulnerability history, including the frequency and severity of past vulnerabilities and the supplier’s track record for timely patch releases. The component’s maintenance status should be assessed, including whether it is actively maintained, the size and health of its contributor community for open-source components, and the supplier’s stated support timeline. The component’s license compatibility with the device’s distribution model should be verified. And the component’s security characteristics should be evaluated, including whether it supports secure configuration options, provides adequate logging for security monitoring, and follows secure coding practices.

Supplier SBOM Requirements

Medical device manufacturers that incorporate commercial software components into their devices should require their software suppliers to provide SBOMs for the supplied components. This requirement enables the manufacturer to create a complete device SBOM that includes the sub-components of commercial software elements, to monitor vulnerabilities not only in the commercial component as a whole but also in its individual sub-components, and to anticipate end-of-support events for sub-components that may affect the commercial component’s long-term viability. Supplier SBOM requirements should be documented in procurement agreements and should specify the SBOM format, the minimum data fields required, the frequency of SBOM updates, and the mechanism for SBOM delivery.

SBOM Considerations for Software as a Medical Device

Software as a Medical Device, software that performs a medical function without being part of a hardware medical device, presents distinctive SBOM considerations because SaMD products are typically deployed on general-purpose computing platforms, may depend on cloud infrastructure and third-party services, and are updated more frequently than embedded device software.

Cloud Infrastructure Components

SaMD products that operate on cloud infrastructure should include cloud platform components in their SBOM scope to the extent that these components are part of the manufacturer’s managed environment. This includes container base images and their constituent components, application runtime environments and their dependencies, middleware and database components that the manufacturer configures and manages, and serverless function runtimes and their associated libraries. Components managed entirely by the cloud provider, such as the hypervisor and underlying infrastructure services, are typically not included in the manufacturer’s SBOM but should be addressed through the cloud provider’s own security and compliance programs.

Rapid Update Cycles

SaMD products that follow continuous deployment practices may release updates weekly or even daily, requiring SBOM generation and vulnerability assessment to be fully automated within the deployment pipeline. The SBOM should be regenerated with every release, vulnerability assessment should be performed automatically as a release gate, and SBOM distribution to stakeholders should be automated to ensure that healthcare delivery organizations always have access to the current device SBOM.

Automating SBOM Workflows in DevSecOps Pipelines

Manual SBOM management is unsustainable for any organization that maintains more than a handful of products. Automation is essential for generating accurate SBOMs at the speed of software development, maintaining SBOM currency as software evolves, correlating SBOMs with vulnerability intelligence in real time, and distributing SBOM updates to stakeholders without manual intervention.

Pipeline Integration Architecture

An automated SBOM pipeline for medical device development should include SBOM generation integrated into the build process, producing an SBOM as a build artifact alongside the device firmware or software package. Automated vulnerability scanning should compare the generated SBOM against vulnerability databases and flag any components with known vulnerabilities that exceed the organization’s risk threshold. Policy enforcement should evaluate the SBOM against organizational policies for component approval, license compliance, and vulnerability tolerance, blocking builds that violate defined policies. SBOM storage should archive each generated SBOM in a centralized repository linked to the corresponding software version and build metadata. And SBOM distribution should provide mechanisms for sharing current SBOMs with regulatory authorities, healthcare delivery organizations, and other stakeholders through standardized APIs or portal access.

SBOM Sharing with Healthcare Delivery Organizations

Healthcare delivery organizations, the hospitals, clinics, and health systems that deploy medical devices in clinical settings, are increasingly requesting SBOMs from device manufacturers as part of their own cybersecurity risk management programs. Effective SBOM sharing requires not only making the SBOM available but also providing the contextual information that enables healthcare organizations to make informed risk decisions.

Sharing Mechanisms

Manufacturers should establish standardized mechanisms for sharing SBOMs with healthcare organizations, which may include a manufacturer-hosted portal where authorized customers can access current SBOMs for their deployed devices, direct delivery of SBOMs as part of the device procurement and deployment process, API-based access that enables healthcare organizations’ security tools to programmatically retrieve and process device SBOMs, and integration with emerging healthcare SBOM aggregation platforms that provide a centralized view of SBOMs across a healthcare organization’s device fleet.

Contextual Information

Raw SBOMs without contextual information may overwhelm healthcare organizations with vulnerability data that they cannot meaningfully act on. Manufacturers should supplement SBOM sharing with VEX documents that communicate the exploitability status of known vulnerabilities in the device context, security architecture documentation that helps healthcare organizations understand the device’s attack surface and defensive controls, patching and update guidance that explains how to apply security updates and what compensating controls to implement when patches are not immediately available, and end-of-support notifications that provide advance notice when device software components will no longer receive security updates.

Building an SBOM Maturity Model

SBOM management capability should be developed progressively, with organizations building foundational capabilities first and adding sophistication as processes mature and tools are deployed. A practical maturity model for medical device SBOM management provides a roadmap for this progressive development.

Level 1: Compliance Baseline

The initial maturity level focuses on meeting the regulatory minimum: generating SBOMs for premarket submissions, maintaining SBOM documentation as part of the design history file, and establishing basic processes for SBOM updates when device software changes. At this level, SBOM generation may be semi-manual, vulnerability monitoring may be periodic rather than continuous, and SBOM sharing may be limited to regulatory submissions.

Level 2: Operational Integration

The second maturity level integrates SBOM management into operational processes: automated SBOM generation in the build pipeline, continuous vulnerability monitoring with automated alerting, VEX generation for known vulnerabilities, and proactive SBOM sharing with healthcare delivery organizations. At this level, the SBOM program becomes a functional component of the organization’s product security operations rather than a compliance documentation exercise.

Level 3: Strategic Capability

The highest maturity level leverages SBOM data as a strategic input to product security decisions: predictive analytics that anticipate component risk based on historical vulnerability patterns, automated supply chain risk scoring that informs component selection, portfolio-wide vulnerability impact analysis that enables enterprise risk management, and SBOM data integration with threat intelligence that enables proactive security response to emerging threats targeting specific software components.

The software bill of materials is not merely a regulatory compliance artifact; it is the foundation of a security capability that protects patients, enables efficient vulnerability management, supports transparent communication with healthcare delivery organizations, and demonstrates to regulators that the manufacturer takes seriously its obligation to maintain the cybersecurity of its products throughout their lifecycle. The organizations that invest in building mature SBOM programs will find that the regulatory compliance benefit, while important, is the least valuable outcome. The real value lies in the visibility, the speed of response, and the confidence that comes from knowing exactly what software is running on every device in the field and being able to assess, in hours rather than weeks, whether a newly disclosed vulnerability affects any of those devices. In an industry where software vulnerabilities can directly threaten patient safety, that visibility is not merely a business advantage; it is an ethical obligation.