SBOM Compliance: What CRA, NIS2, and DORA Require

If you're a compliance lead or CISO at a financial institution that builds or buys software for EU markets, you're probably juggling at least two or three regulatory frameworks right now. Each one uses different terminology, covers a different scope, and was written by a different regulator — which makes figuring out what you need to do significantly harder than it should be.

What makes that complexity manageable is recognizing that all three are converging on the same underlying requirement: know what your software depends on, and prove you can keep it running if one of those dependencies disappears.

Who each regulation covers

The overlap between frameworks is where organizations tend to get caught out, so it's worth pinning down exactly who each one covers before looking at what they require.

• DORA — the Digital Operational Resilience Act — applies to financial services entities operating in the EU. Banks, insurers, investment firms, payment processors, crypto asset service providers, and their critical ICT third-party service providers all fall within scope. If you're a fintech, a bank, or a software provider contracted by one of them in a critical capacity, DORA applies to you.

• NIS2 — the Network and Information Security Directive 2 — casts a wider net. It covers "essential entities" across energy, transport, health, water, digital infrastructure, and financial market infrastructure, plus "important entities" in food, postal services, manufacturing, and digital services. EU member states were required to transpose NIS2 into national law by October 2024, so enforcement operates through national legislation.

• CRA — the Cyber Resilience Act — applies to manufacturers and distributors of products with digital elements sold in the EU. If you build software that runs in your customers' systems, CRA applies to you. Reporting obligations start in September 2026, with full enforcement from December 11, 2027.

A fintech company building software for EU banks can fall under all three at once — as a financial entity under DORA, as a software manufacturer under CRA, and potentially as an important entity under NIS2. That's not a rare edge case. For organizations in financial services that develop or distribute software, it's the default situation.

» Find out how you can ensure your compliance in regulated industries. 

What each regulation specifically requires on SBOMs

CRA: an explicit mandate

CRA is the most direct of the three. Article 13 requires manufacturers of products with digital elements to draw up a software bill of materials in a commonly used, machine-readable format covering at minimum the top-level dependencies of the product. That SBOM forms part of the technical documentation manufacturers must maintain and make available to market surveillance authorities on request.

Top-level dependencies are the minimum, not the ceiling. The regulation doesn't prohibit deeper documentation, and member state technical guidance — Germany's BSI TR-03183-2, published August 2025 — is already specifying requirements that go further.

The SBOM also isn't a one-time filing: CRA requires security to be maintained across the product's supported lifecycle, so it needs to stay current as the product changes and new vulnerabilities are identified.

DORA: asset inventory plus exit strategy

DORA doesn't use the term SBOM. Its requirements are framed around asset inventory and third-party risk management — but in practice, they demand at least as much as CRA, and in one critical area, they go further.

Under Article 8, financial entities must maintain a complete inventory of all ICT assets, classified by criticality. Under Article 28(3), they must maintain a register of all contractual arrangements with ICT third-party service providers, including sub-outsourcing relationships that support critical or important functions. And under Article 28(8), for any ICT service supporting a critical or important function, financial entities must have a documented, tested exit strategy — a plan for maintaining operations if that provider fails, withdraws, or can no longer deliver the service.

An SBOM is the practical mechanism for satisfying Articles 8 and 28(3). Without knowing exactly which components underpin your critical systems, you can't reliably map dependency risk, conduct meaningful due diligence, or draft credible exit plans.

But the exit strategy requirement under Article 28(8) goes further than transparency alone — it requires you to demonstrate that you can actually operate without a given provider if you have to. That's a resilience obligation where software escrow is needed to ensure independent system operation.

NIS2: supply chain security measures

NIS2 takes a similar approach, but with less explicit statutory language. Article 21(d) requires covered entities to take measures addressing "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." That's broad by design — NIS2 sets principles rather than technical prescriptions.

However, since the directive itself was originally written, both the implementing regulation (EU) 2024/2690 and ENISA's Technical Implementation Guidance have added significant specificity. The ENISA guidance explicitly recommends that in-scope organizations consider requiring SBOMs from critical software suppliers as evidence of supply chain transparency.

So while the SBOM obligation under NIS2 isn't a statutory mandate in the way CRA's is, it's now written into the guidance that regulators and auditors will use when assessing compliance with Article 21.

Comparison: what each regulation requires

When all three regulations apply at the same time

Take a payments software company with EU bank clients. It manufactures software with digital elements, so CRA applies. Its bank clients are regulated financial entities under DORA, and those clients' regulators will expect their software vendors to support their compliance posture — including exit strategy requirements. Depending on its size and sector classification, the company itself may also fall under NIS2 as a digital provider.

Three frameworks, three sets of obligations, a single software product sitting underneath all of them.

What makes this more than a paperwork problem is the practical solutions that need to be in place to satisfy each one. Many compliance teams have some version of an asset inventory or vendor register. Fewer have SBOMs at the component level. Very few have tested whether their documented recovery plans would indeed work.

What actually satisfies all three frameworks

For software vendors, satisfying the transparency requirement means CRA-compliant SBOMs at the component level. For financial entities and NIS2-covered organizations, it means extending that expectation to the software you depend on — requesting SBOMs from critical vendors as part of due diligence and contract terms.

The resilience requirement is what most organizations don't yet have covered. The exit strategy and continuity obligations across all three frameworks require you to demonstrate that you can operate without a given vendor if you have to. Verified software escrow and Software Resilience Certificates are how that gets documented in a way regulators and auditors can inspect.

Verified escrow involves a third party that holds on to all the source code, data, and documentation needed to maintain or migrate your critical systems. Codekeeper's verification service tests whether these deposited assets are complete, current, and buildable. A Software Resilience Certificate is then issued as the auditable artifact: proof that recovery has been tested, which directly addresses the exit strategy requirements under both DORA and NIS2.

So what's the plan of action?

Your starting point depends on which obligations are most pressing.

If you're a software vendor selling into EU markets:

Your primary obligation is CRA compliance — producing machine-readable SBOMs and maintaining a vulnerability management process across the product lifecycle. But your enterprise customers under DORA and NIS2 will also expect you to demonstrate that their dependency on your software is protected. Offering verified software escrow as part of your contract documentation gives you a commercial edge.

If you're a financial services firm using third-party software: 

DORA's asset inventory and exit strategy requirements are your most time-sensitive obligation — enforcement has been active since January 2025. Start by mapping your critical ICT dependencies: every provider whose failure would disrupt a critical function. For each one, you need a tested exit strategy with documentation that regulators can inspect. Software escrow with verified recovery testing satisfies that directly.

If you're an enterprise buyer in a NIS2-covered sector: 

Request SBOMs from your critical software suppliers and establish escrow arrangements for any system where vendor failure would affect your operations. Software Resilience Certificates document both what's been deposited and that it works — the kind of auditable evidence that sits behind an Article 21 compliance claim.

The enforcement window is shorter than it looks

For DORA and NIS2, the preparation phase is over — regulators are now asking for evidence, not plans. CRA gives you until 2027, but organizations spending that time catching up on the first two aren't getting ahead of the third.

» If you have an SBOM but no tested recovery plan in place, you've covered the transparency layer but not the resilience one. Find out how Codekeeper's verified escrow solutions can close that gap.