Draft of Principles and Practices for Software Bill of Material for Medical Device Cybersecurity

Written by Diego Rodriguez Muñoz Published on 23.08.2022 Last updated on 16.06.2026

Connected medical devices increasingly share third-party and open-source components. A single vulnerability in a widely used library can ripple across vendors and product lines—making Software Bills of Materials (SBOMs) essential for transparency, risk assessment, and incident response across the total product lifecycle. The International Medical Device Regulators Forum (IMDRF) formalized this with its final guidance, Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity (N73), which describes what an SBOM is, how to generate and maintain it, and how healthcare delivery organizations should consume it.

What an SBOM is—and why devices need one

The U.S. National Telecommunications and Information Administration (NTIA) defines an SBOM as a structured inventory of software components and their metadata—the “ingredients list” of a product. This transparency helps manufacturers and operators quickly identify exposure when new vulnerabilities (e.g., in a dependency) are disclosed, and it enables repeatable vulnerability and patch management processes.

IMDRF’s SBOM guidance (N73) dovetails with earlier IMDRF N60 lifecycle cybersecurity practices, positioning SBOMs as part of customer security documentation and post-market risk management. For device makers, that means SBOMs aren’t a one-time deliverable but a maintained asset that evolves with software updates, configurations, and component end-of-support.

Where regulators are today (and what they expect)

In the U.S., the FDA’s final cybersecurity guidance (2025 update) integrates SBOM expectations into quality system and premarket documentation, alongside processes for vulnerability handling, threat modeling, and update mechanisms. The FDA’s public Cybersecurity FAQs also explain how statutory changes (section 524B) affect submissions and postmarket obligations. Manufacturers should expect reviewers to look for SBOM content that’s actionable (e.g., component versions, known vulnerabilities, support status) and kept current throughout the device lifecycle.

Beyond healthcare, CISA’s 2024 framing for software component transparency shows how SBOM data is converging toward interoperable formats and exchange models—useful for scaling supplier management and incident response across complex portfolios and hospital networks.

Practical SBOM essentials for medical-device teams

Per IMDRF N73, an effective medical-device SBOM should clearly identify each component (and transitive dependency), the supplier, version, and unique identifiers, along with relationships and license data. It must also be consumable by customers: documentation should explain how the SBOM is accessed, how frequently it is updated, and how customers can map vulnerabilities to affected configurations. Manufacturers should align SBOM scope and format with their post-market cybersecurity processes so that vulnerability intake (e.g., from CISA/NVD) triggers internal triage, risk evaluation, and—when needed—field actions.

SBOMs for AI/ML and ML-enabled devices (MLMD)

AI-driven devices and machine learning-enabled medical devices (MLMD) depend on extensive software stacks plus data pipelines. While model artifacts aren’t “software components” in the classic sense, the IMDRF MLMD terminology (N67) and broader cybersecurity guidance support the same principle: maintain transparent, version-controlled inventories of the components your safety depends on—frameworks, libraries, runtimes, and security-relevant configs—so you can evaluate and communicate risk when dependencies change. Pair your SBOM with rigorous change control for models and data to preserve safety and performance.

How SBOMs reduce time to action

When a widely used component is found vulnerable, organizations that maintain current, machine-parsable SBOMs can immediately answer: Where do we run this? Which devices are impacted? What versions are affected? That shortens the path from disclosure to containment, patching, or compensating controls—reducing patient and business risk. FDA reviewers, hospital security teams, and incident-response coordinators increasingly expect this level of traceability.

Bottom line for digital-health manufacturers

Treat the SBOM as a first-class safety artifact: build it as you build your software, keep it up to date, make it accessible to customers, and wire it into vulnerability management and field-action playbooks. Align content and exchange formats with IMDRF N73 and be prepared to show how SBOMs underpin your premarket claims and postmarket responsiveness.

If you’re planning or executing a submission, MDx CRO can map your current secure-development and post-market processes to the latest expectations, align SBOM tooling and content to IMDRF/FDA, and integrate SBOM handling into your PMS and incident-response procedures.

Written by:

Diego Rodriguez Muñoz

Diego is a PhD researcher and Clinical Regulatory Associate at MDx CRO. With a strong foundation in Molecular Bioscience and immunology from the Universidad Autónoma de Madrid, he now focuses his insights on the EU AI Act. Diego is passionate about exploring how emerging AI regulations will shape the future of clinical research and healthcare technology, blending his scientific training with a keen interest in modern tech policy.
View all articles →
Industry Insights & Regulatory Updates

IMDRF Machine Learning-enabled Medical Devices: Key Terms and Definitions

Written by Alberto Bardaji de Qixano Published on 03.06.2022 Last updated on 15.07.2026

The International Medical Device Regulators Forum (IMDRF) has published Machine Learning-enabled Medical Devices: Key Terms and Definitions (IMDRF/AIMD WG/N67, Edition 1). This foundational guidance establishes a common vocabulary for artificial intelligence (AI) and machine learning (ML) in the medical device sector. Its purpose is to create uniform expectations and understanding, improve patient safety, inspire innovation, and encourage access to breakthroughs in healthcare technology.

Artificial intelligence is broadly defined as the use of algorithms or models to perform tasks, make decisions, or generate predictions. Within AI, machine learning is a subset where models are trained on data, enabling them to learn patterns without explicit rule-based programming. The IMDRF document situates these concepts within a regulatory and clinical context, ensuring clarity when applied to medical devices.

One of the key goals of the guidance is to reduce confusion across jurisdictions. Manufacturers, regulators, and clinicians may use different terms for the same concepts, such as “model,” “training,” or “retraining.” This lack of alignment can complicate regulatory submissions and reviews. The IMDRF’s definitions create a standard set of terms that can be consistently referenced across regulatory frameworks and development programs.

In February 2025, IMDRF released Good Machine Learning Practice (GMLP), which builds on the definitions in N67 by providing ten guiding principles for the development, validation, and monitoring of ML-enabled devices. The link between the two documents is crucial: N67 defines the language, while GMLP sets expectations for practice across the product lifecycle.

Key Terms and Their Impact

The N67 guidance defines terms such as “model,” “training set,” “test set,” “drift,” “bias,” “retraining,” “locked model,” and “continuous learning.” These definitions are not academic—they directly influence how safety risks are assessed, how validation studies are structured, and how regulatory change control is applied. For instance, a locked model is one that does not evolve after deployment, while a continuous learning model adapts over time, requiring additional oversight and safeguards.

Understanding drift and bias is particularly important. Drift refers to performance degradation when the underlying data distribution changes, while bias indicates systematic error or unequal performance across patient subgroups. The IMDRF document clarifies these terms to support manufacturers in identifying when retraining or remediation is required to maintain safety and performance.

Why Uniform Definitions Matter

A harmonized vocabulary enhances regulatory predictability and cross-border alignment. With common definitions, manufacturers can prepare more consistent submissions, and regulators can apply more transparent and standardized review processes. It also helps notified bodies, standards committees, and audit organizations maintain consistent evaluation criteria.

Clear definitions are equally important for clinicians and patients. When a device is described as “continuously learning,” stakeholders need to understand the precise boundaries of its adaptation. This clarity reduces risks of misinterpretation that could compromise patient safety or compliance.

Integration with Regulatory Practice

The IMDRF’s N67 definitions are now referenced in the GMLP principles adopted by multiple regulators, including those in the U.S., UK, EU, and Canada. This reinforces the importance of shared terminology as the basis for regulatory policy. Together, N67 and GMLP create a roadmap for the development and oversight of AI/ML-enabled devices, from design and testing to monitoring and lifecycle management.

Implications for Developers

Manufacturers must integrate IMDRF definitions into their development practices from the outset. Risk management plans, validation strategies, and change-control procedures should explicitly reflect terms such as drift, retraining, and continuous learning. Clinical performance evaluation must be designed using clearly defined training and test sets, while monitoring strategies must track performance shifts aligned with N67 definitions.

Failure to align with this common vocabulary can lead to misinterpretation, regulatory delays, or gaps in safety oversight. By embedding these terms into development and documentation, companies can demonstrate compliance and strengthen the credibility of their devices.

Conclusion

The IMDRF’s Machine Learning-enabled Medical Devices: Key Terms and Definitions guidance represents a milestone in harmonizing global understanding of AI/ML in healthcare. By defining key terms such as model, drift, and retraining, it lays the foundation for safe innovation and regulatory clarity. Together with the GMLP framework, it provides a roadmap for developers and regulators alike as AI-enabled healthcare technologies continue to evolve.

If your team is developing an ML-enabled device and needs support in aligning with IMDRF definitions and regulatory expectations, contact MDx CRO to discuss how we can guide your strategy from concept to approval.

Written by:

Alberto Bardaji de Qixano

Master of Engineering with close to 20 years of international experience in product development, regulatory affairs and market access of Medical Devices. Authorized MDR and ISO 13485 QMS Auditor.
View all articles →
Industry Insights & Regulatory Updates