Reading time: 5 minutes.

SBOM in practice: What NIS2 and CRA 2026 really require of you

The next major security vulnerability, such as Log4Shell, is bound to happen – but are you prepared? From 2026, the Cyber Resilience Act (CRA) will require manufacturers of digital products, and the NIS2 Directive will require critical infrastructure operators, not only to provide a Software Bill of Materials (SBOM) but also to put it into operational use.

However, an SBOM on its own is merely a static list: what matters is how you automatically detect, prioritise and remediate vulnerabilities such as new CVEs – using verifiable processes for audits. This article explains why SBOMs will become a ‘ticket to entry’ in 2026 and how you can turn a mere compliance requirement into a genuine security advantage. After all, only those who actively manage vulnerabilities throughout the vulnerability lifecycle not only meet legal requirements but also minimise the risk to your organisation.

When the next log4shell vulnerability emerges — will you know within minutes which products are affected?

That is precisely the question to which NIS2 and the Cyber Resilience Act (CRA) demand robust answers. Not only from critical organisations covered by NIS2, but  under the CRA from every manufacturer of a product containing digital elements. By 2026/2027, this will affect far more companies than many currently realise.

In 2026, the SBOM will be the entry ticket, not the accolade

A Software Bill of Materials (SBOM) in the CycloneDX-Standard is the machine-readable table of contents for your software. By 2026, it will be generated automatically in every serious build process — GitHub, GitLab, Composer and npm will provide this capability. Generating an SBOM will become standard practice.

But the real question is: what happens next?

The difference lies in the operational vulnerability lifecycle

An SBOM without continuous comparison against vulnerability databases is merely a table. Only when newly reported CVEs are automatically checked against your component inventory, defined thresholds control escalation, and a traceable workflow exists from detection to patching, do you comply with Art. 21 of NIS2 and the obligations set out in Annex I of the CRA.

At dkd, this has been standard operational practice for years: GitLab generates SBOMs with every production deployment; OWASP Dependency-Track continuously monitors against the NVD, GitHub Advisories and the OSS Index; and defined policies govern response and escalation. The audit trail is generated in the background.

What can we do for you & why dkd

We put you in the same position. We integrate GitLab and Dependency-Track into your development infrastructure, work with you to define thresholds and response pathways, and train your teams so that the tools become an integral part of your processes. On request, we operate the platform as a managed service — GDPR-compliant and hosted in Germany.

We don’t sell you tools that you could put together yourself. We bring operational experience to the table, drawn from our own use of these tools and over two decades of professional software development. The question isn’t whether you’ll have SBOMs by 2026. The question is what they’ll deliver for you when it really matters.

We put SBOMs into practice – get in touch.