So, you're busy mapping your critical ICT providers. You've reviewed the contracts. Then someone in an audit prep meeting asks: "Do we actually know what's inside the software these vendors are running?"
That question cuts to the heart of what DORA's supply chain visibility requirement is trying to get at. And an SBOM is perfectly situated to answer it.
DORA doesn't use the words "software bill of materials." But what it asks of financial entities adds up to the same thing: a clear, maintained, and tested record of the software your business depends on, down to its components and dependencies. If your answer to that question is "we have a vendor contract," you have a gap.
What DORA actually asks about your software supply chain
DORA rests on five pillars, and ICT third-party risk management is one of them. Two requirements within that pillar do most of the work when it comes to software component visibility.
The first is Article 8, which covers ICT asset management. Financial entities must identify, classify, and document all ICT assets, and that includes software. The regulation is explicit that this extends to third-party dependencies: you must map the configurations, links, and interdependencies between your ICT assets, and document all processes that rely on ICT third-party service providers. That's a software inventory exercise, not a contract review exercise.
Article 28 takes it further. This is the ICT third-party risk article, and it requires financial entities to maintain a register of all ICT third-party arrangements, review it continuously, and build a formal strategy around managing that risk. For services that support critical or important functions — the ones your business couldn't operate without — Article 28(8) requires exit strategies that account for provider failure. Those strategies must be documented and tested, not just written down and filed away.
Put both articles together, and the compliance problem becomes clear. When an auditor asks whether you understand your third-party ICT risk, a contract tells them what you agreed to. It says nothing about what's actually running, what libraries it depends on, or whether those dependencies are still maintained. That's the question DORA is asking — and most firms don't have a clean answer to it yet.
So how does an SBOM factor in?
A software bill of materials is an ingredients list for a piece of software. It tells you what components went into building it, what versions they're running, and what each one depends on in turn.
The requirement to have that information is stipulated in the Regulatory Technical Standards (RTS) under Article 15 — think of these as the detailed rulebook behind the main regulation text. Article 10 of Commission Delegated Regulation (EU) 2024/1774 requires financial entities to track third-party libraries, including open-source ones, used by ICT services that support critical or important functions. It also requires ongoing monitoring of version changes and available updates.
The problem is that open-source libraries are in almost every piece of enterprise software your business runs on. Some are maintained by only a handful of contributors. Some haven't seen a security update in years. Others are flagged in public vulnerability databases right now.
Without that component-level view, you can't know which of your critical ICT services are sitting on top of something that could fail, get exploited, or go unmaintained. Which is why everyone's reaching for SBOMs to fill the gap.
The CRA cuts straight to the chase
While DORA requires component tracking without naming SBOMs, the EU Cyber Resilience Act calls for it directly.
The CRA mandates that manufacturers of products with digital elements generate and maintain machine-readable SBOMs for everything they sell into the EU market. Full compliance applies from December 11, 2027. But vulnerability reporting obligations under the CRA begin September 11, 2026, and you can't report on vulnerabilities in components you haven't inventoried. In practice, SBOM readiness needs to be in place well before the official deadline.
For financial services firms in scope of both regulations, the pressure is coming from two directions. DORA is live now and requires the information. The CRA formalizes the format and makes it mandatory for product manufacturers. Treating the CRA as a 2027 problem and just focusing on your DORA obligations is the wrong sequencing — the underlying work for both can be set up in one go.
What a DORA-compliant software supply chain setup looks like
Component visibility is the starting point, not the finish line. Knowing what's in your software matters because it determines what kind of exit strategy you need.
Articles 28(8) and 30(3) together set the standard: for any ICT service supporting a critical or important function, you must have a tested, documented path out. That means having access to the materials you'd need to migrate or rebuild, and being able to show that recovery is possible.
This is where SBOM and verified software escrow work together. An SBOM tells you what's in the software and where the risks are. Verified escrow backs up copies of the materials supporting the product: the source code, configuration, and documentation you'd need to rebuild the software. They cover different parts of the same compliance question — transparency on one side, continuity on the other.
In truth, you can't really have just one or the other. Article 30(2)(d) makes the continuity requirement explicit at the contract level. Every ICT service contract must include provisions ensuring access, recovery, and return of all data and materials in the event of the ICT provider's insolvency, resolution, or business discontinuation. Having that clause in a contract is one thing. Being able to exercise it is another.
How Codekeeper's verification certificates serve as DORA evidence
Most firms can show a disaster recovery plan. Fewer can prove it works. Under DORA, that distinction matters — regulators want evidence that recovery has been tested, not documentation that says it should be possible.
Software Resilience Certificates are Codekeeper's answer to that problem. When you deposit source code and documentation into escrow, Codekeeper tests whether those deposits are complete, current, and buildable from scratch. The certificate is the record of that test: what was checked, when, and whether it passed.
That's what makes it useful in an audit: documented proof that someone ran the recovery process and it worked.
The ongoing monitoring requirement in the DORA RTS is also covered. Daily automated syncs across Codekeeper's 50+ platform integrations, so deposits stay current with every change to the codebase rather than reflecting a snapshot from six months ago.
Meet your DORA requirements the right way
Most firms that struggle with DORA audits are missing evidence. The gap between what their contracts say and what they can actually demonstrate about their software supply chain is where auditors look — and where findings get written up.
Getting component visibility and verified escrow in place before that conversation happens is considerably easier than explaining the absence of both during one.
» Not sure if the software you're running falls under a regulation? You can run your dependencies through Codekeeper's compliance scanner.
