Key takeaways
- This is a principles-level summary, not a field-by-field copy of IMDRF's own text; confirm exact recommended fields against the published N73 document before building a template a regulatory submission will rely on.
- Manufacturers, on generating, maintaining and distributing an accurate SBOM across a device's life cycle, not just at the point of initial clearance or approval.
- N73 sets out principles and practices rather than mandating a single machine-readable SBOM schema such as CycloneDX or SPDX.
- FDA's Section 524B premarket cybersecurity requirement is a binding US statutory duty; N73 is non-binding international guidance with no independent legal force anywhere.
A medical device manufacturer that already produces a software bill of materials for FDA's Section 524B duty is not starting from a different list when a hospital, a notified body, or an international regulator in another IMDRF-member market asks for the same artifact. IMDRF N73, "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity" (IMDRF/CYBER WG/N73FINAL:2023, published 13 April 2023), is the international reference point behind that overlap — a set of SBOM best practices meant to work across jurisdictions rather than a regulator-specific checklist.
Where N73 sits in IMDRF's cybersecurity guidance
N73 is the SBOM-focused sibling to IMDRF N70 on legacy medical device cybersecurity — per IMDRF's own published development timeline, both documents went through public consultation in 2022 and were finalised two days apart in April 2023. That pairing is not a coincidence: N70's legacy-device risk assessment depends on knowing exactly what software a fielded device runs, and N73 is where that software-transparency practice is detailed. Both trace back to the Total Product Life Cycle (TPLC) framing IMDRF's N60 guidance first introduced.
What an SBOM should identify, per N73's framing
Secondary-source summaries of N73 consistently describe its content recommendations as close to the broader NTIA minimum-elements approach already used across the device-security industry — see SBOM minimum elements for that general baseline. For a medical device specifically, the recommended identification covers:
| Element | What it captures |
|---|---|
| Component and dependency | Each software component, including commercial, open-source and off-the-shelf parts, and known transitive dependencies |
| Supplier | Who provides or maintains the component |
| Version | The specific version in the fielded device, not just the component family |
| Unique identifiers | Identifiers that let a component be matched against vulnerability databases |
| Relationships | How components relate to one another within the device's software stack |
| Licence | Licensing terms attached to each component |
This is a principles-level summary, not a field-by-field copy of IMDRF's own text; confirm exact recommended fields against the published N73 document before building a template a regulatory submission will rely on.
Who N73 is written for
Unlike guidance that treats SBOM purely as something a manufacturer hands over once, N73 — consistent with N60 and N70's stakeholder-inclusive structure — addresses three audiences together:
- Manufacturers, on generating, maintaining and distributing an accurate SBOM across a device's life cycle, not just at the point of initial clearance or approval.
- Healthcare providers, on using a received SBOM for their own risk management — the same use case IMDRF N70's legacy-device guidance assumes is available when a provider assesses whether a fielded device can still be reasonably protected.
- Regulators, on what an SBOM submitted as part of a premarket or postmarket interaction should actually contain.
No mandated format, deliberately
N73 sets out principles and practices rather than mandating a single machine-readable SBOM schema such as CycloneDX or SPDX. This mirrors FDA's own premarket cybersecurity guidance, which likewise declines to name a required format and instead asks for a machine-readable SBOM consistent with NTIA's minimum-elements framing, with industry-accepted formats encouraged. See CycloneDX vs SPDX for how the two leading formats compare if a manufacturer needs to pick one.
How this lines up with FDA's Section 524B duty
FDA's Section 524B premarket cybersecurity requirement is a binding US statutory duty; N73 is non-binding international guidance with no independent legal force anywhere. The two are connected through people and process rather than legal citation: FDA co-chaired the IMDRF Cybersecurity Working Group that produced N73, and FDA's own guidance describes itself as well-aligned with IMDRF's broader cybersecurity guidance suite. In practice, a manufacturer building its SBOM process to N73's principles is building toward what a 524B submission needs, not maintaining a separate parallel artifact — but FDA's own current guidance text, not N73, is what a US submission is actually checked against.
What manufacturers should do now
Build one SBOM practice that satisfies N73's principles, rather than a US-specific SBOM and a separate international one — the content overlap is close enough that duplicating the work rarely pays off. Feed the SBOM into legacy-device risk assessment, not just regulatory submissions — see IMDRF N70 for how the two documents are meant to work together. Pick a machine-readable format your tooling and customers already support— CycloneDX vs SPDX covers the practical tradeoffs — rather than waiting for N73 or FDA to name one. Share the SBOM with healthcare providers, not only regulatorsN73's stakeholder structure assumes providers use the artifact directly for their own risk management, which only works if the manufacturer actually distributes it. Confirm field-level detail against IMDRF's own published N73 textbefore finalising an SBOM template meant to support a regulatory submission.
SoftWSP's device and firmware security work can help build a medical-device SBOM that holds up against both IMDRF's N73 principles and FDA's Section 524B requirements: see Device & Firmware Security.
Sources
- IMDRF: Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity (N73, document page)
- IMDRF: Medical Device Cybersecurity Working Group — Strategic Plan progress report (N78), legacy/SBOM document timeline
- FDA: Cybersecurity in Medical Devices – Quality Management System Considerations and Content of Premarket Submissions (guidance, SBOM section)
Frequently asked questions
What is IMDRF N73?
IMDRF/CYBER WG/N73FINAL:2023, 'Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity,' is a final guidance document from the International Medical Device Regulators Forum's Cybersecurity Working Group, published 13 April 2023 after public consultation in 2022. It sets out best practices for generating, managing, distributing and using SBOMs across a medical device's life cycle.
Who is N73 written for?
N73 addresses the full chain of medical-device SBOM stakeholders together: manufacturers that generate the SBOM, healthcare providers that receive and use it for their own risk management, and regulators that may request it as part of a submission or postmarket inquiry. This mirrors the stakeholder-inclusive structure of N70, its companion legacy-device document, rather than treating SBOM as a manufacturer-only compliance artifact.
Does IMDRF N73 require a specific SBOM format like CycloneDX or SPDX?
N73 provides high-level principles and best practices for SBOM content and process rather than mandating one machine-readable schema. This mirrors FDA's own approach in its premarket cybersecurity guidance, which also declines to name a specific format and instead points to the component-level minimum elements industry-accepted formats like CycloneDX and SPDX can satisfy; see our CycloneDX vs SPDX guide for how the two leading formats compare.
How does N73 relate to FDA's Section 524B SBOM requirement?
They are not the same instrument — Section 524B of the US FD&C Act is a binding statutory requirement, while N73 is IMDRF guidance with no independent legal force in any jurisdiction. But FDA co-chaired the IMDRF working group that produced N73, and FDA's own premarket cybersecurity guidance describes itself as well-aligned with IMDRF's cybersecurity guidance suite, so a manufacturer building one SBOM practice to IMDRF's principles is typically building toward, not away from, what a 524B submission needs.
What should an SBOM under N73 actually identify?
Per consistent secondary-source summaries of the guidance, an effective medical-device SBOM should identify each software component and its known dependencies, the supplier, the version, applicable unique identifiers, the relationships between components, and relevant licence information — closely mirroring the NTIA minimum-elements framing FDA itself references. Confirm the exact field-level recommendations against IMDRF's own published N73 text before building a template from this summary alone.
In this cluster
