Here is a scene that plays out more often than it should. A manufacturer with a CE-marked device decides to enter the US market. The regulatory lead has a mature technical file: clinical evaluation, risk management to ISO 14971, post-market surveillance plan, the IT security requirements of Annex I. Years of work, and it is good work.
There is no software bill of materials in it. Not because anyone was careless. Because nothing in the European framework asked for one.
Why the European file does not contain it
Two things have to be true at once, and both are.
First, the Cyber Resilience Act does not reach the device. Article 2(2) of Regulation (EU) 2024/2847 excludes products with digital elements covered by the MDR and the IVDR. The CRA is where the EU's SBOM obligation lives — it requires manufacturers to draw one up covering, at minimum, top-level dependencies. That obligation does not travel to a device the MDR already covers.
Second, the guidance that does apply barely mentions it. For cybersecurity of medical devices in Europe, the operative document is MDCG 2019-16, Guidance on Cybersecurity for medical devices. It is 46 pages, developed by regulators, notified bodies, hospital associations and industry.
Search it for “bill of materials” and you get exactly one result. It appears on page 26, inside a list of what documentation provided to the user may include:
“Such information may include the following: ▪ List of IT security controls included in the medical device … ▪ Software Bill of Materials ▪ User roles and respective access privileges/permissions on the device …”
One mention, in a permissive list, addressed to user documentation rather than to the technical file. That is the whole of it.
MDCG 2019-16 was written before the SBOM became a regulatory instrument anywhere. It has not been revised since. There is nothing improper about a European medical device programme that has never produced one.
What the US asks for instead
Section 524B(b)(3) is not guidance and not permissive. The sponsor of a premarket submission for a cyber device shall:
“provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components.”
The February 2026 guidance then adds what FDA expects each component entry to carry, beyond the NTIA baseline attributes: the software's level of support — “actively maintained, no longer maintained, abandoned” — and its end-of-support date. Manufacturers are also asked to identify known vulnerabilities associated with those components, including those in CISA's Known Exploited Vulnerabilities Catalog, with a safety and security risk assessment for each.
The part most summaries get wrong
It is tempting to compress this into “the US demands a deeper SBOM than Europe.” That is not accurate, and stating it that way in front of anyone who has read the source documents will not survive the conversation.
On depth, the US baseline is not deep. FDA anchors to the NTIA minimum elements, and NTIA's relationship model describes a component's immediate upstream relationships — one level. It also defines four states of knowledge about those relationships, of which the first is:
“Unknown. This is the default. There is not yet any claim, knowledge, or assertion about upstream components.”
A framework that names a default for “we do not know what is upstream” is not a framework built around exhaustive dependency resolution. The CRA's floor — top-level dependencies — sits at roughly the same depth.
So the asymmetry is real, but it runs along two different axes:
- What you must say about each component. FDA wants maintenance status and end-of-support date per component. That is the uncomfortable part, because “abandoned” is a word no one wants to write next to something shipping in a Class II device.
- Whether you hand it over. FDA requires you to provide it to the agency. The CRA requires you to have one; on showing it to anyone, Annex II is explicit that it is the manufacturer's choice — information on where the SBOM can be accessed is required only “if the manufacturer decides to make available the software bill of materials to the user.”
Europe asks for less and lets you keep it. The US asks for more about each item and takes a copy.
What this means if you are the regulatory lead
The practical consequence is narrow and worth stating plainly: the artifact that satisfies your European obligations does not satisfy Section 524B, and the gap is not the one you would guess. If you build an SBOM to the CRA floor and bring it to a 510(k), what is missing is not levels of the dependency tree. It is the lifecycle column — maintained, unmaintained, abandoned, end-of-support — and the fact that FDA expects it in the submission rather than in a drawer.
That column also cannot be generated retroactively by a tool. Somebody has to determine, per component, whether the upstream project is alive. That is a research task with a real duration, and it belongs in the plan rather than in the week before filing.
And a note about your regulatory consultant
If you work with a European regulatory consultancy and they have never raised the SBOM with you, that is not a gap in their expertise. Their framework did not ask for one. An MDR specialist who has spent a decade on clinical evaluation, GSPR conformity and notified body dialogue has had no professional reason to build depth here, because until very recently there was nothing to build depth on.
It is worth being explicit about this, because the alternative reading — that somebody dropped the ball — is both unfair and wrong. The frameworks diverged. The people did not.