A medical device SBOM: the legal requirement (FDA §524B, CRA) and how to keep it

The SBOM was long an engineering best practice that few teams formalised. That era is over: on both sides of the Atlantic, it has become a legal requirement. The FDA has required it since 2023 in every “cyber device” submission, the European Union mandates it via the Cyber Resilience Act, and IEC 81001-5-1 makes it an expectation for CE marking. For a team building medical software, the question is no longer “do I need an SBOM?” but “will mine hold up in front of a regulator?”.

What is an SBOM, exactly?

Definition: an SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all the software components — commercial, open-source, off-the-shelf — that make up a product, with their dependency relationships. It is your software’s parts list, the equivalent of a bill of materials for the software supply chain.

The NTIA structures the topic in three inseparable areas: the data fields (what each component must document), automation support (machine generation and reading, to scale), and practices and processes (how the SBOM is requested, produced and used). A PDF listing dependencies is not an SBOM: the requirement is a structured format that tools can consume.

What must a compliant SBOM contain?

The NTIA defines seven minimum data fields for each component:

1. Supplier Name;
2. Component Name;
3. Version;
4. Other Unique Identifiers;
5. Dependency Relationship;
6. SBOM Author;
7. Timestamp.

For a medical device, the FDA premarket guidance additionally expects, for each component: the asset where the component resides, the level of support provided by its manufacturer, its end-of-support date, and its known vulnerabilities. Those last three are decisive: they turn the SBOM from a mere inventory into a life-cycle risk-management tool.

Why has it become a legal requirement?

Three texts converge, with different natures and deadlines:

On top of this sits the MDR path: IEC 81001-5-1:2021 — the state-of-the-art cybersecurity standard under the MDR — already expects an SBOM in secure release management, and the MDCG 2019-16 guidance cites it as a means of compliance. In other words, even before the CRA fully applies, a notified body will ask for your SBOM.

An SBOM is not one more compliance deliverable: it is the same technical artifact that feeds your FDA file, your CRA technical documentation, and your SOUP management under 62304 at once. Build it once, use it everywhere.

Which format: CycloneDX or SPDX?

Two standards share the field:

• CycloneDX — driven by OWASP, standardised as ECMA-424, designed with a security focus (vulnerabilities, VEX).
• SPDX — driven by the Linux Foundation, published as ISO/IEC 5962:2021, rooted in open-source licence compliance.

No regulator mandates one over the other: the FDA, the CRA and IEC 81001-5-1 require a commonly used, machine-readable format. CycloneDX and SPDX both meet that criterion. In practice, many teams generate both, because tools, customers and authorities each lean a different way.

How do you generate and maintain it?

An SBOM is not written by hand: it is generated from your sources of truth.

• Generate from lockfiles (package-lock.json, poetry.lock, go.sum…) with tools like Syft, Trivy or your ecosystem’s CycloneDX plugin — include transitive dependencies, base images and runtimes.
• Regenerate on every release, automatically, in CI. An SBOM frozen on audit day is wrong by the next version.
• Wire it into the rest of compliance: every third-party component is a SOUP in the IEC 62304 sense — the SBOM is its inventory; and it is the pivot of post-market vulnerability management, since it lets you identify affected devices within minutes when a CVE is published.

That last point is what gives the SBOM its real value: not ticking a regulatory box, but knowing instantly what your product contains the day a critical vulnerability drops.

FAQ

Do I have to make the SBOM public?

No. Under the CRA it is part of the technical documentation and is provided only to market surveillance authorities, on request — it does not have to be published. On the FDA side, it is attached to the premarket submission. The transparency required is regulatory, not public.

Must it include transitive dependencies?

The CRA’s legal minimum covers top-level dependencies, but the expected practice — and what tools produce — covers the full graph, transitive dependencies included. For vulnerability management, partial depth is a blind spot: a CVE often hides in a dependency of a dependency.

Is an SBOM enough to prove my cybersecurity compliance?

No. It is a necessary but not sufficient piece. It fits into a broader cyber file — vulnerability management plan, threat model, security testing. An SBOM with no monitoring and triage process behind it is just a list.