NIS2 has turned supply chain security from good practice into a legal obligation. Article 21(2)(d) of the Directive requires essential and important entities to manage risk arising from suppliers and service providers, and a Software Bill of Materials (SBOM) is quickly becoming the practical way to demonstrate that this obligation is met. For organisations already working through NIS2 compliance, SBOM management is often the missing piece between a governance policy and evidence a regulator will actually accept.
This guide sets out what NIS2 and the EU Cyber Resilience Act (CRA) actually require in terms of software transparency, how the two regulations compare, who is in scope, and the practical steps to build SBOM management into an existing compliance programme rather than treating it as a one-off spreadsheet exercise.
What is a Software Bill of Materials (SBOM)?
A Software Bill of Materials, or SBOM, is a structured inventory of every component that makes up a piece of software: open-source libraries, third-party packages, and their specific versions. Put simply, it is an ingredients list for software. Just as a food label discloses every ingredient in a product so a consumer can check for allergens, an SBOM discloses every component in an application so an organisation can check for known vulnerabilities.
For a compliance officer or CISO, the value is not in the software engineering detail; it is in the visibility. Modern applications are typically assembled from hundreds of open-source and third-party components, most of which nobody in the organisation has directly reviewed. When a vulnerability is disclosed, the first question a board, a regulator or an insurer will ask is simple: is the organisation affected, and where? Without an SBOM, answering that question means manually contacting every supplier and development team, a process that can take days. With an SBOM, it takes minutes — precisely the kind of software supply chain visibility NIS2 and the CRA now expect organisations to have in place before an incident occurs, not after.
What does NIS2 require for SBOMs?
NIS2 itself does not use the term "Software Bill of Materials." The Directive is deliberately outcome-based rather than prescriptive about specific tools or documents, which is one reason SBOM requirements are often missed during initial gap assessments. Look at the implementing detail, however, and the expectation becomes explicit.
Commission Implementing Regulation (EU) 2024/2690, which sets out the technical and methodological requirements for the cybersecurity risk-management measures in Article 21, requires essential and important entities providing certain digital infrastructure and ICT services to maintain information describing the hardware and software components used in the network and information systems supporting their service. In practice, that description is an SBOM in all but name.
The underlying obligation sits in Article 21(2)(d) of NIS2, which lists supply chain security — including security-related aspects concerning the relationships between an entity and its direct suppliers or service providers — as one of the ten minimum risk-management measures every in-scope organisation must implement. Software supply chain risk, where a vulnerability in a third-party or open-source component becomes an entry point into an organisation's own systems, sits squarely inside that requirement.
ENISA, the EU Agency for Cybersecurity, has gone further in its own guidance, describing SBOM management as one of the few genuinely effective methods available for managing software supply chain security at scale. That recommendation carries weight: national competent authorities enforcing NIS2 look to ENISA guidance when assessing whether an entity's risk-management measures are "appropriate and proportionate," the legal standard set by Article 21(1).
There is also a direct operational link to incident reporting. Article 23 requires essential and important entities to submit an early warning within 24 hours of becoming aware of a significant incident, followed by a more detailed notification within 72 hours. When a new vulnerability is disclosed in a widely used component, an organisation without an SBOM has no fast way to determine whether it is affected. An organisation with an SBOM can query it in minutes, identify every affected system, and meet the 24-hour window with an answer grounded in evidence rather than assumption.
NIS2 vs CRA: SBOM requirements compared
NIS2 is not the only EU regulation touching software transparency, and the differences matter when scoping a compliance programme. The table below sets out how NIS2, the Cyber Resilience Act and DORA each approach SBOMs.
| Requirement | NIS2 | CRA | DORA |
|---|---|---|---|
| SBOM named explicitly? | No — implied via Art. 21(2)(d) and Implementing Regulation (EU) 2024/2690 | Yes — explicit obligation | No — addressed via ICT third-party risk management |
| Who is in scope | Essential and important entities across 17 sectors | Manufacturers of products with digital elements placed on the EU market | Financial entities and their critical ICT providers |
| Format expected | Not prescribed; CycloneDX or SPDX in practice | Machine-readable; CycloneDX and SPDX referenced, BSI TR-03183-2 as technical baseline | Not prescribed; assessed via third-party risk registers |
| Key deadline | In force since October 2024 | Vulnerability reporting from September 2026; full SBOM obligations from December 2027 | In force since January 2025 |
| Depth required | Direct supplier relationships | Minimum top-level dependencies at first release | Register of information across all ICT arrangements |
The Cyber Resilience Act is the most explicit of the three. Manufacturers of "products with digital elements" must produce a machine-readable SBOM covering, at minimum, the top-level dependencies of a product, in either CycloneDX or SPDX format. Germany's BSI has published TR-03183-2 as a widely referenced technical baseline for what a compliant SBOM should contain, and it is increasingly treated as good practice across the EU even outside Germany. Vulnerability handling and reporting obligations under the CRA apply from September 2026, with the full SBOM and technical documentation requirements following in December 2027.
For organisations already working through DORA compliance in the financial sector, the practical difference is scope rather than intent: DORA folds software transparency into its broader ICT third-party risk management and register-of-information requirements, rather than mandating an SBOM by name. An organisation building SBOM capability for NIS2 or the CRA is, in effect, building the same capability DORA expects of its regulated financial entities and their critical ICT providers.
Who needs to comply?
NIS2 applies to organisations classified as either essential or important entities across 17 sectors, ranging from energy, transport and banking to digital infrastructure, healthcare and the manufacturing of certain critical products. The classification determines the intensity of supervision an organisation faces, but the underlying risk-management obligations, including supply chain security, apply to both categories.
Scope is generally determined by size: medium and large entities meeting or exceeding the EU thresholds of 50 employees or €10 million in annual turnover or balance sheet total typically fall in scope, alongside specific categories of entity that are in scope regardless of size, such as providers of public electronic communications networks, trust services and DNS infrastructure. Organisations headquartered outside the EU are not exempt: providers established outside the Union that offer services into the EU are required to designate an EU representative and are subject to the same obligations.
One aspect of NIS2 that consistently gets a compliance officer's attention is personal liability. Unlike much of the pre-existing EU regulatory landscape, NIS2 makes management bodies directly accountable for approving and overseeing cybersecurity risk-management measures, including supply chain security, and national authorities have the power to hold individual board members and senior management liable for non-compliance. That accountability is a strong practical reason why software supply chain visibility, and the SBOM programme that supports it, needs to be documented and defensible, not just technically correct.
How to implement SBOM management for NIS2
1. Inventory your software landscape
Before an SBOM can be generated for anything, the organisation needs a clear picture of what software estate actually exists: internally built applications, commercial off-the-shelf software, and the cloud services and platforms that support critical business processes. Many organisations discover at this stage that no single team holds a complete inventory, since procurement, engineering and IT operations often maintain separate, partial lists. Treat this step as a governance exercise as much as a technical one: the inventory should map each system to the business process and NIS2 obligation it supports, so the SBOM effort can be prioritised by risk rather than convenience.
2. Generate SBOMs for critical assets
Rather than attempting to produce an SBOM for every system on day one, prioritise assets that support essential or important services, or that would trigger NIS2 incident reporting obligations if compromised. Most modern build tools and container registries can generate a CycloneDX or SPDX SBOM automatically as part of the existing release process, so the practical effort is usually integration rather than manual documentation. Start with newly built or actively maintained systems, then work backwards to legacy and third-party components, which typically require closer supplier engagement.
3. Integrate with vulnerability management
An SBOM only creates value once it is connected to a source of vulnerability intelligence. Matching component inventories against feeds such as the National Vulnerability Database or vendor security advisories turns a static document into an early-warning system: as soon as a new vulnerability is disclosed for a component in use, the affected systems are already known. This is the link between SBOM management and NIS2 Article 23's 24-hour reporting clock, and it is where most of the practical time savings are realised.
4. Establish supplier SBOM requirements
Article 21(2)(d) explicitly extends supply chain security obligations to relationships with direct suppliers and service providers. In practice, that means building SBOM delivery into supplier contracts and onboarding: new software suppliers should be required to provide a machine-readable SBOM alongside their product, in the same way they are already expected to provide security documentation or a right-to-audit clause. For existing suppliers, a phased request campaign prioritised by criticality is more realistic than a single blanket demand.
5. Connect to incident response workflows
Finally, the SBOM needs to sit inside the incident response process, not alongside it. When a significant incident is declared, the responding team should be able to query the SBOM directly to establish which systems and services are affected, feeding straight into the impact assessment required for NIS2's 24-hour and 72-hour reporting deadlines. Where SBOM data lives in a spreadsheet disconnected from the incident management tooling, this step is invariably the one that gets skipped under time pressure.
From SBOM to continuous assurance
An SBOM produced once and filed away answers a compliance question for a single point in time. It does not answer it six months later, after new releases, new vulnerabilities and new suppliers have changed the picture. This is where treating SBOM management as a continuous process, rather than a one-off deliverable, becomes the difference between a document an auditor tolerates and evidence a regulator trusts.