NIS2 SBOM Requirements: The 7 Fields Your CIR Evidence Needs

Search “NIS2 SBOM requirements” and most results will tell you the directive mandates a software bill of materials. It doesn’t — not by that name, and confusing NIS2’s actual text with its sister law, the Cyber Resilience Act, is the single most common error in coverage of this topic. What NIS2 and its implementing regulation, CIR 2024/2690, actually require is a documented inventory of the hardware and software components your organisation runs — worded in plain, non-technical language that happens to describe exactly what an SBOM produces.

This guide separates what the law literally says from what an SBOM programme practically does for you, cites the exact CIR Annex sections rather than a generic “Article 21(2)(d),” and gives you a concrete path for generating one for software you build versus software you buy or outsource — the distinction that determines almost everything about how hard this is in practice.

Does This Apply to Your Organisation?

If your organisation is in scope of NIS2 at all, you already have an obligation that a software bill of materials (SBOM) is the practical way to satisfy — even though the directive never uses the term. You need to be able to produce, on request from your competent authority, a documented list of what software and hardware components your systems run, and where they came from.

Your situation	Component-documentation duty	Is SBOM the practical answer?
Any essential or important entity	Yes — Article 21(2)(e) plus CIR 2024/2690 Section 6.1.2(c)	Recommended as the evidence artefact
DNS/TLD, cloud, data centre, CDN, MSP/MSSP, marketplace, search engine, social platform, trust service	Yes, and the CIR Annex binds you directly, not “by analogy”	Strongly recommended — ENISA names SBOM management explicitly for this group
Manufacturing, energy, healthcare, transport, other non-digital-infrastructure sectors	Yes, via Article 21 directly; the CIR Annex applies only “by analogy”	Recommended best-practice evidence, not a literal CIR obligation
You manufacture and sell software or hardware with digital elements	Separate question — check the Cyber Resilience Act, not NIS2	Mandatory under CRA Annex I Part II if in scope, regardless of NIS2 status

Three checks settle where you sit. Are you an essential or important entity? Then Article 21(2)(e) already applies. Are you one of the ten CIR-named digital infrastructure categories? Then Sections 5 and 6 bind you directly. Are you also a software manufacturer, not just an operator? Then the Cyber Resilience Act’s own SBOM mandate applies separately, on a different legal basis.

Does NIS2 Actually Require an SBOM?

No — not by name, and not in the way most vendor content implies. Article 21(2)(e) requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” CIR 2024/2690 turns that into something concrete at Section 6.1.2(c): entities must maintain “information describing the hardware and software components used” in ICT acquisition. That text never says “SBOM,” specifies no format, and sets no required depth — but it requires exactly the inventory an SBOM produces.

Section 5 adds the other half. Section 5.2 requires “a registry of… direct suppliers and service providers” plus “a list of ICT products, ICT services, and ICT processes provided.” Section 5.1.4 requires supplier contracts to cover vulnerability handling and incident notification. An SBOM is what lets that registry hold more than a vendor name — it ties each supplier to the specific components they’re responsible for.

Where this gets sloppy elsewhere: the EU’s Cyber Resilience Act (Regulation 2024/2847) does contain an explicit SBOM mandate that NIS2 doesn’t. CRA Annex I, Part II, point 1 requires manufacturers to draw up “a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies.” That’s a binding, named requirement — for manufacturers of products with digital elements, not NIS2 entities generally. If you’re both, two separate obligations apply on two separate legal bases.

ENISA’s own NIS2 Technical Implementation Guidance closes the gap for CIR-bound digital infrastructure entities, recommending SBOM management as the practical way to demonstrate Section 5 and 6 compliance and requiring SBOMs from critical suppliers as evidence. For everyone else, an SBOM is the most defensible way to satisfy a duty the law states in plain language rather than a named technical standard.

The 7 NTIA Data Fields Your SBOM Needs

Since NIS2 sets no field-level standard, the practical move is building to the US National Telecommunications and Information Administration’s 2021 Minimum Elements for a Software Bill of Materials — the most widely adopted baseline, and the default output of every major SBOM tool.

Field	What it records
Supplier Name	The entity that creates, defines, and identifies the component
Component Name	The designation the original supplier assigned to the software unit
Version	The identifier the supplier uses to mark a change
Other Unique Identifiers	Lookup keys such as a package URL (purl) or CPE that disambiguate the component across ecosystems
Dependency Relationship	How an upstream component relates to the software including it
Author of SBOM Data	The entity that created the SBOM entry — often not the software’s author
Timestamp	The date and time the SBOM data was assembled

Two fields get shortchanged most often. “Other Unique Identifiers” is left blank because populating it takes an extra tool integration — but without it, two same-named components from different ecosystems become indistinguishable during a vulnerability match. And “Dependency Relationship” often gets flattened into a flat list, which satisfies the field on paper but destroys the structure an incident responder needs to trace how a vulnerable component actually reaches production.

Beyond the Baseline: The SBOM Depth Ladder

Treating “SBOM” as one fixed standard is the most common oversimplification here. There’s a ladder of increasing rigor, and where you need to sit on it depends on your exposure, not a universal answer.

Standard	What it adds	Who it’s really for
CIR 2024/2690, Section 6.1.2(c)	“Information describing hardware and software components” — no named format, no specified depth	Baseline floor for every NIS2 entity
NTIA Minimum Elements (2021)	The 7 fields above, plus guidance on frequency, depth, distribution	Practical default for most organisations
CISA’s 2025 update	Adds license information as a required field	Organisations tracking open-source licence exposure
ENISA SBOM Landscape Analysis (Dec 2025)	EU-specific format comparison and phased-adoption guidance built on the NTIA/CISA baseline	Organisations aligning to EU expectations
BSI TR-03183-2 (Germany)	Mandates CycloneDX v1.6+ or SPDX v3.0.1+, SPDX license identifiers, a cryptographic checksum per component, and recursive dependency resolution “at least until the first ‘out of scope’ component”	The most rigorous national-authority benchmark published in the EU — written for CRA manufacturers, useful as a ceiling reference for NIS2 depth

That last row needs a caveat: BSI TR-03183-2 is a German guideline for Cyber Resilience Act manufacturers, not a NIS2 requirement, and binds no other member state’s NIS2 entities. It’s included as the most detailed field-by-field SBOM specification any EU national authority has published. Even here sources disagree at the detail level — BSI’s own example checksum is SHA-512, while a secondary summary cites SHA-256; the binding requirement is “a cryptographic checksum,” not one named algorithm, so verify the current published version before writing one into a contract.

ENISA’s SBOM Adoption State of Play 2026 survey of 334 EU organisations found 78% have started an SBOM programme, but only 9% call theirs fully mature and automated — most sit somewhere on this ladder, not at the top. That gap is exactly where the fields above go missing first.

Generating an SBOM for Software You Build In-House

Generation should be a build-time step, not a separate audit exercise — and tooling choice depends on how uniform your stack is. With a small number of consistent languages, CycloneDX’s ecosystem-specific build plugins (Maven, npm) give the most accurate result: they hook into the package manager’s own resolver, so the SBOM reflects exactly what the build resolved. The tradeoff is one plugin per ecosystem, unwieldy once you span Java, Go, Python, and JavaScript together.

For that broader, multi-ecosystem case — the norm for most mid-sized organisations — a general-purpose scanner like Syft handles container images, filesystems, and many package formats from one tool, at some cost in dependency-tree precision. Either way, treat generation as part of CI/CD, not a quarterly chore: CIR Section 6.2’s secure development lifecycle requirement expects documentation throughout development, not an annual snapshot.

One caution for your security team: don’t default to your existing vulnerability and patch management scanner without checking its current security posture. In March 2026, Trivy — a popular combined scanner-and-SBOM-generator — was compromised twice within two weeks in separate supply chain incidents, prompting several teams to pull it from CI/CD pending review. An SBOM tool is itself a supply chain dependency — apply the same scrutiny Article 21(2)(d) asks you to apply to every other direct supplier.

Getting an SBOM for Software You Buy or Outsource

Procured and outsourced software is the harder half — you can’t run a build-time scanner against code you don’t compile. This is where Section 5.1.2’s supplier-selection criteria and Section 5.1.4’s contract clauses stop being paperwork and become your only real lever.

Build SBOM delivery into procurement, not a post-contract request: specify format (CycloneDX or SPDX), minimum fields (the NTIA 7), and update cadence (per release) directly in the Section 5.1.4 contract language you already require. For vendors already under contract, request their SBOM and prioritise those who can produce one at renewal — ENISA’s 2026 survey found a meaningful share of organisations still never receive one even after asking, so build in a follow-up rather than treating one email as sufficient diligence.

For vendors who genuinely can’t or won’t provide one — smaller vendors, legacy contracts, dead-end tools — two fallbacks keep you defensible. First, request a Vulnerability Exploitability eXchange (VEX) statement: where an SBOM tells you what’s inside a product, VEX tells you whether a specific known vulnerability actually affects it as deployed, often the more urgent question mid-incident. Second, request an attestation of secure development practices (NIST SP 800-218 is the closest recognised standard). Log the gap either way — Section 5.2’s registry should note who hasn’t provided an SBOM, so it surfaces at your next risk review instead of an unfiled email thread.

Choosing Your Format: SPDX vs CycloneDX

Neither NIS2 nor the CIR Annex names a required format. In practitioner experience, license-compliance-minded teams gravitate toward SPDX, built originally for that use case; security-minded teams prefer CycloneDX, designed around vulnerability management. ENISA recommends building capability for both — a position the data supports: its 2026 survey found CycloneDX in roughly 44% of implementations and SPDX in roughly 29%, the remainder proprietary or non-standard output that interoperates cleanly with neither.

Starting from scratch with no existing pull toward one format, CycloneDX’s alignment with vulnerability-management tooling makes it the more common default for NIS2’s Article 21(2)(e) emphasis — but if your organisation already tracks open-source licence obligations closely, SPDX’s native licence-expression support may save maintaining two inventories.

Keeping Your SBOM Audit-Ready

An SBOM generated once during a build isn’t documentation that survives an audit. Three practices close that gap: version and timestamp every SBOM and retain history rather than overwriting the latest (Section 5.2’s registry implies a record of what changed, not just a snapshot); tie refresh cadence to release cadence, not a calendar date, since a year-old component list at the moment of an incident undermines the Article 21(2)(e) obligation it exists to support; and make unclosed gaps visible — for suppliers who won’t provide an SBOM, keep a documented note of the request, response, and fallback accepted, rather than a silent absence an authority’s audit would surface for you.

For smaller organisations weighing the effort: the duty applies regardless of size under Article 21(1)’s proportionality principle — proportionate doesn’t mean optional, it means depth scales with risk and size. A small essential entity with a handful of core applications can maintain adequate SBOMs with one build-time tool and a spreadsheet registry; it doesn’t need a large operator’s automation maturity to meet the same obligation.

Getting This Right the First Time

The organisations that struggle with this treat SBOM as a single compliance artefact to produce once and file away. The ones that don’t, treat it as two separate operational habits — a build-time step for what you develop, and a procurement lever for what you buy — tied to the CIR Annex sections that actually require the underlying inventory, not to the word “SBOM” itself. Start with whichever half is weaker in your organisation today: if your in-house pipelines already generate SBOMs but your supplier contracts are silent on the subject, fix the contracts first; if it’s the reverse, pick one build-time tool and start there. Either way, the standard to build toward keeps rising — CISA added licence data in 2025, ENISA published EU-specific guidance in December 2025, and Germany’s BSI has already gone further still. Building past the bare CIR floor now costs less than retrofitting it later.

Frequently Asked Questions

Does NIS2 legally require a software bill of materials?
No. It requires information describing components used (CIR Section 6.1.2(c)) and a supplier/product registry (Section 5.2), but names neither “SBOM” nor a format. An SBOM is the practical way to produce that documentation, not a literal requirement in itself.

Is an SBOM the same thing under NIS2 and the Cyber Resilience Act?
No. The CRA has an explicit, binding SBOM mandate for manufacturers (Annex I, Part II, point 1). NIS2 has no equivalent named mandate — its duty is implied through Article 21(2)(e) and the CIR Annex. If you’re both a NIS2 entity and a CRA-scoped manufacturer, two separate obligations apply, even if one programme can serve both.

What format should our SBOM use?
CycloneDX and SPDX are the two dominant formats; neither is mandated. CycloneDX suits vulnerability-management-first use cases, SPDX suits licence-compliance-first use cases, and larger organisations increasingly need both.

Do we need an SBOM for software we didn’t build ourselves?
Yes, in principle — the CIR Annex’s duty doesn’t distinguish by origin. In practice, generate your own for in-house code and request one (or a VEX/attestation fallback) from vendors for procured or outsourced software.

How often should we regenerate our SBOM?
Tie it to your release cycle, not a calendar date — every release or significant update, per NTIA’s own operational guidance. A stale SBOM at the moment of disclosure defeats the purpose it exists to serve.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
2. Commission Implementing Regulation (EU) 2024/2690, Annex, Sections 5 & 6 — Advisera full-text mirror
3. Cyber Resilience Act (Regulation (EU) 2024/2847), Annex I, Part II — cyberresilienceact.eu
4. “The Minimum Elements For a Software Bill of Materials (SBOM)” — National Telecommunications and Information Administration, July 2021 (ntia.gov)
5. “SBOM Adoption State of Play – 2026” — ENISA, June 2026 — enisa.europa.eu
6. “BSI TR-03183-2: Software Bill of Materials (SBOM)” — Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany — bsi.bund.de
7. “Germany’s BSI SBOM Guidelines: What You Need to Know” — FOSSA
8. “SBOM Requirements for the CRA: A Guide to BSI TR-03183” — Interlynk
9. “NIS2 Technical Implementation Guidance: A Practical Summary” — nis-2-templates.com