2026-09-07 • 12 Min Read

The Cyber Resilience Act Reaches Banking: SBOMs and the Software Supply Chain

On 11 September 2026 the EU Cyber Resilience Act's reporting obligations take effect; on 11 December 2027 the rest of it does. Most banks filed the CRA under “product regulation, not ours.” That was a defensible first reading and an expensive second one — because the CRA rewrites what every supplier in your estate owes you, while DORA already holds you accountable for what they ship.

The Deadline Nobody Put on the Banking Roadmap

Regulation (EU) 2024/2847 — the Cyber Resilience Act — entered into force in December 2024 with a long runway, and most financial institutions read it as somebody else's problem. Its unit of regulation is the product with digital elements placed on the EU market: routers, industrial controllers, operating systems, libraries, firmware. A bank does not, on the face of it, manufacture any of those. The obligations appeared to land with vendors, and the file went into the monitoring pile.

That pile is now overdue. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform on a 24-hour, 72-hour and 14-day cadence. From 11 December 2027, the full essential requirements and CE marking apply. Between those dates every serious supplier in a banking estate will rebuild how it documents components, discloses vulnerabilities and commits to support periods — and institutions that treated the CRA as a vendor concern will find it arrives instead as a contract problem, an incident-response problem and, for some, a problem with their own name on it.

What the CRA Regulates — and Whether It Regulates You

The CRA governs the product placed on the market, not the service operated for customers. Pure software-as-a-service falls outside it — that is NIS2 territory — unless it is a remote data processing solution without which the product cannot perform its function. Free and open-source software supplied outside a commercial activity is likewise out of scope, with a deliberately lighter regime for open-source stewards. For most of a bank's internal estate — the core, the data platform, the internal portals — the CRA binds the supplier, not the operator.

The edge cases deserve a legal opinion rather than an assumption. A retail banking app distributed through public app stores; a white-labelled terminal shipped to merchants; a payments SDK handed to corporate clients; an API gateway licensed to a subsidiary in another member state — each of those looks more like software made available on the market in the course of a commercial activity than like an internal service. The answer is institution-specific, but the question has a deadline, and “we assumed we were out of scope” is a poor position to defend in December 2027.

The SBOM Stops Being a Nice-to-Have

Annex I requires manufacturers to identify and document the components contained in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies. Read that clause slowly. Machine-readable means SPDX or CycloneDX, not a spreadsheet attached to an email. The SBOM must stay current across the support period — at least five years, or the product's expected lifetime if shorter — and forms part of technical documentation retained for a decade.

The phrase at the very least is where the argument starts. Log4Shell was not a top-level dependency in the estates it broke; it sat three or four levels down, inside a logging façade, inside a framework, inside an application server. An SBOM that stops at direct dependencies satisfies the letter of Annex I and answers almost none of the questions asked at two in the morning during an exploited-in-the-wild event. Banks receiving SBOMs from suppliers should specify depth contractually, because the regulation sets a floor and will not raise it for them.

Two Clocks, One Incident

A single exploited vulnerability in a vendor-supplied component can start two regulatory clocks that do not agree. Under CRA Article 14 the manufacturer owes an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure becoming available — filed once, to its lead CSIRT and to ENISA. Under DORA Article 19 and its technical standards, the bank owes its competent authority an initial notification within four hours of classifying the incident as major and no later than 24 hours from awareness, an intermediate report within 72 hours, and a final report one month after the last intermediate one.

The clocks differ in trigger, recipient and content, and they run concurrently on the same underlying event. Worse, the bank's four-hour clock often starts before the vendor's disclosure arrives, because institutions usually learn from their own telemetry rather than from a supplier notice. The operating-model answer is not a second reporting team. It is one incident record with two rendering paths, a triage step that evaluates DORA materiality and CRA relevance together, and contractual notification windows that oblige suppliers to tell you inside your deadline rather than theirs.

Your Suppliers' New Obligations Are Your Leverage

The most valuable thing the CRA does for a bank is make contractible what used to be discretionary. From December 2027 a compliant manufacturer must operate a coordinated vulnerability disclosure policy, provide security updates across a declared support period of at least five years, ship products with secure-by-default configurations, and hand over a machine-readable SBOM. Those were once negotiating asks that a confident vendor could simply decline. They are becoming conditions of market access.

The practical move is to fold them into procurement now rather than inherit the vendor's own 2027 timetable. Clauses worth writing this quarter: SBOM delivery with every release at a specified depth and format; a declared end-of-support date instead of a rolling promise; notification of actively exploited vulnerabilities inside a window compatible with DORA's four hours; and CRA conformity representations for anything placed on the market after December 2027. The same work feeds the DORA register of information — the supplier facts the CRA forces into the open are largely the facts the register already demands.

The Engineering Behind the Paperwork

For institutions that do place products in scope on the market, compliance artefacts are only credible if they are generated rather than assembled. An SBOM produced by hand in the week before an audit is a document; an SBOM emitted by the build pipeline, signed, attested and stored alongside the artefact it describes is a control. The same distinction applies to vulnerability handling: a coordinated disclosure policy is a PDF until there is an intake channel, a triage rota, a severity rubric and a measured path from a reported CVE to a released patch.

The capability that separates readiness from paperwork is queryability. When the next Log4Shell lands, the question is: which of our releases, in which environments, contain this component at any depth — and which customers are running them? Answering that in minutes requires an SBOM store spanning versions and a VEX practice that records, per product, whether a listed CVE is genuinely exploitable there. Without VEX a deep SBOM mostly manufactures noise, and noise is precisely what makes a 24-hour clock unmeetable.

Fifteen Months to December 2027

The sequencing writes itself once the scoping question is answered. Between now and the end of 2026: establish with legal whether any product the institution places on the market falls in scope, and add CRA relevance to the existing DORA incident triage so the two assessments happen in one pass. Through the first half of 2027: rewrite procurement templates, and start demanding SBOMs from the ten suppliers whose software sits closest to critical or important functions — not because the regulation yet compels them, but because reading ten real SBOMs teaches more than any readiness assessment.

The second half of 2027 is for estate-wide work: an SBOM repository that is queried rather than filed, VEX for products you ship, and conformity evidence for anything in scope. None of this is exotic engineering, and most of it is worth doing on its own merits — which is the honest case for starting early. The CRA's deadline is a forcing function for a capability banks already needed: knowing precisely and quickly what their software is actually made of.