DORA Spared You From NIS2. It Will Not Spare You From the CRA.

In thirty-nine days the Cyber Resilience Act starts a twenty-four-hour reporting clock, and the exemption every bank reaches for does not stop it. Ask a financial institution whether NIS2 applies and you get a fluent answer: DORA is lex specialis, NIS2 Article 4 stands down where a sectoral act covers the same ground, and the bank reports ICT incidents to its competent authority rather than to a CSIRT. That answer is correct. It is also about to be given, wrongly, to a question about a different regulation. The CRA does not regulate entities. It regulates products, and it imposes its duties on whoever manufactures them. There is no financial-services carve-out in its scope article, because a carve-out drafted for entity law has nothing to attach to in product law. From 11 September 2026, a bank that makes software available on the market owes ENISA an early warning within twenty-four hours — and it owes that alongside DORA, not instead of it.

Executive Summary

• A live date, not a horizon date. Article 14 applies from 11 September 2026. The rest of the CRA waits until 11 December 2027, and the gap between those two facts is where the planning error sits.
• Scope is decided by what you ship, not what you are. The CRA's exclusions are other product regimes — medical devices, vehicles, aviation, marine equipment. Banking is not among them and was never going to be.
• The trigger is exploitation, not severity. A vulnerability under active exploitation starts the clock even if no customer is affected and nothing would be a major incident under DORA.
• Nobody owns this today. DORA reporting sits with operational resilience. CRA reporting sits with whoever is deemed the manufacturer — a role most banks have never assigned.

What Actually Starts on 11 September #

The CRA entered into force on 10 December 2024 with a staged application timetable, and the staging is the part that gets lost.

Full application — the essential cybersecurity requirements in Annex I, conformity assessment, CE marking, technical documentation — lands on 11 December 2027. Notification of conformity assessment bodies opened on 11 June 2026. Between those two sits the date that matters this quarter: 11 September 2026, when the Article 14 reporting obligations begin.

The reporting structure is three-staged and tighter than it first reads.

• Early warning within 24 hours of the manufacturer becoming aware of an actively exploited vulnerability, or of a severe incident having an impact on the security of the product.
• Full notification within 72 hours, carrying the technical detail and any corrective or mitigating measures taken.
• Final report within 14 days after a corrective measure becomes available for an actively exploited vulnerability, or within one month of the notification for a severe incident.

Reports go through the CRA Single Reporting Platform operated by ENISA. A manufacturer files once, to the CSIRT designated as coordinator in the member state of its main establishment; the platform makes the notification available to ENISA simultaneously, and the receiving CSIRT propagates it to other CSIRTs in territories where the product is distributed. That single-submission design removes an administrative excuse but does not soften the clock.

Note what the trigger is. Not severity, and not customer impact — exploitation. A vulnerability being actively exploited in the wild starts a 24-hour obligation whether or not anyone has been harmed, and whether or not the same facts would classify as a major incident anywhere else.

Why the DORA Carve-Out Does Not Reach It #

This is the part worth being precise about, because the reasoning that produces the wrong answer is genuinely good reasoning applied one regulation too far.

NIS2 Article 4 contains a deferral mechanism: where a sector-specific EU act requires entities to adopt cybersecurity risk-management measures or notify significant incidents, and those requirements are at least equivalent in effect, the corresponding NIS2 provisions do not apply. DORA is exactly such an act. So a credit institution manages ICT risk and reports major incidents under DORA, and the parallel NIS2 duties stand down. Every bank's regulatory affairs function can recite this.

Three things break the analogy when it is carried across to the CRA.

The mechanism lives inside NIS2. Article 4 is a provision of Directive (EU) 2022/2555 disapplying provisions of Directive (EU) 2022/2555. It is not a general principle that a financial entity's sectoral regime displaces everything else. It cannot reach into Regulation (EU) 2024/2847 and switch anything off, because nothing in the CRA is subject to it.

The CRA regulates products, not entities. DORA and NIS2 both ask what kind of organisation are you. The CRA asks what did you place on the market. Those are different questions, and equivalence arguments between them do not work: there is no sense in which DORA's incident-reporting regime is "equivalent in effect" to a product manufacturer's duty to warn a CSIRT that a shipped artefact is being exploited, because they protect different populations. DORA protects the financial system through the supervisor. Article 14 protects everyone running the product, through the CSIRT network.

The exclusions are the wrong shape. The CRA's scope article carves out products covered by other sectoral product legislation — medical devices under Regulations (EU) 2017/745 and 2017/746, vehicles under Regulation (EU) 2019/2144, civil aviation under Regulation (EU) 2018/1139, marine equipment under Directive 2014/90/EU — plus spare parts manufactured to identical specifications and products developed exclusively for national security or defence. There is no financial-services exclusion, and there is no exclusion for products made by entities regulated under DORA. That is not an oversight to be corrected by guidance. It is what happens when a legislature writes product law: it does not carve out industries, it carves out other product regimes.

Table 1: Three regimes, and which of them stands down #

Are You a Manufacturer? Nobody Has Answered That For You #

Here the honest position is that the question is live rather than settled, and a bank that waits for it to be settled will be waiting past the date.

The CRA reaches products with digital elements made available on the market — supplied for distribution or use in the course of a commercial activity. Two consequences follow immediately from that phrasing.

Price is not the test. Software supplied free of charge is in scope if it is supplied in the course of a commercial activity. The Commission's own framing on open source turns on commercial activity rather than payment, and a bank distributing an application to acquire and service paying customers is not doing so outside the course of commercial activity. The instinct that "we give the app away, so we are not selling a product" is the single most common reason this file has not been opened, and it is the weakest of the available arguments.

Internal-only software is genuinely outside. Products not made available on the market — the core banking platform, internal tooling, anything never supplied beyond the institution — are not caught. That is a real and substantial exclusion, and it is why the exposure is narrower than the panic version of this analysis suggests.

So the question is not whether a bank is in scope as an entity. It is which specific artefacts it supplies. Four categories are worth inventorying before anyone reaches a conclusion:

• The mobile banking application, distributed through app stores to the general public. Whether a customer-facing app is a product supplied for use, or merely the interface to a service the bank provides, is the genuinely contested question — and it is contested, not resolved in the bank's favour.
• Developer-facing artefacts: SDKs, client libraries, API tooling and reference implementations published for corporate clients or partners. These look far more like supplied products and far less like a service interface.
• Open-source projects the institution publishes and maintains as part of its commercial activity, where the steward provisions may also engage.
• White-labelled or embedded software the bank ships onward to partners under its own name, which is the fastest route from deployer to manufacturer in any EU product regime.

The honest planning posture is not to assert a conclusion. It is to inventory the artefacts, take a documented position on each, and be able to show the reasoning if a CSIRT asks why no notification arrived.

The Clock Collision #

Assume for a moment the analysis lands in scope for at least one artefact. What changes operationally is not the existence of an incident process — banks have those — but the fact that two processes now run on the same event with different parameters.

A vulnerability in a bank's published SDK comes under active exploitation. DORA asks whether this is a major ICT-related incident affecting the institution, and if it is, the initial notification runs to the competent authority within four hours of that classification and in any event within 24 hours of becoming aware, with an intermediate report and a final report behind it. Article 14 asks a different question entirely — is a product this institution manufactured being exploited — and runs its own 24-hour early warning to a CSIRT and ENISA.

The two can diverge in both directions, which is what makes a single merged process unsafe.

An exploited vulnerability in a shipped SDK that causes no disruption to the bank's own services may be no major incident at all under DORA, while sitting squarely inside Article 14. And a severe outage of an internally built platform is a DORA notification with no CRA dimension whatever, because nothing was placed on the market. Building one workflow that assumes the two always co-fire produces both false negatives and needless regulatory noise.

Table 2: What to establish before 11 September #

The Number That Sets the Priority #

Non-compliance with the essential requirements in Annex I and with the obligations in Articles 13 and 14 attracts administrative fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other manufacturer, importer and distributor obligations sit a tier below at €10 million or 2%, and supplying incorrect or misleading information to authorities at €5 million or 1%.

Read the top tier against the work it is attached to. Determining whether four categories of artefact are in scope, registering on a reporting platform, and adding one branch to an existing triage runbook is a modest piece of work with a named owner and a five-week runway. It is not comparable to the conformity assessment and technical documentation programme waiting in December 2027. The asymmetry between the exposure and the remediation cost is the whole argument, and it is the rare compliance argument that survives contact with a prioritisation meeting.

The Operating Playbook #

Five moves, and the first one is not a legal opinion.

1. Inventory what leaves the building. Not systems — artefacts. Anything the institution supplies to anyone outside it, including free applications, published libraries and open-source repositories. Most banks have no such list, because no previous regulation asked for one.
2. Take a position per artefact, in writing. Manufacturer, or not, and why. The value is not in being right on every line; it is in having reasoning that predates the incident rather than being constructed after it.
3. Onboard to the Single Reporting Platform now. Registration, credentials and a named filer are exactly the kind of prerequisite that is invisible until a 24-hour clock is already running.
4. Split the trigger in triage. Add one explicit question — is a product we manufactured being actively exploited — that is evaluated independently of DORA major-incident classification. Independence is the point; a nested check inherits the wrong threshold.
5. Start the SBOM work against the December 2027 date. Annex I requires a software bill of materials in a commonly used machine-readable format covering at least top-level dependencies. That duty is sixteen months out, and it is the same enumeration problem institutions are already failing at on the cryptographic side.

The pattern here is not new. A regime is drafted with a particular industry in mind, financial institutions read the industry name, and conclude the file belongs to somebody else. The CRA was written for device manufacturers and software vendors. It reaches the bank anyway, in the narrow place where the bank happens to be one — and the exemption everyone will reach for first was written into a different law, for a different purpose, and does not apply.

Frequently Asked Questions #

We report under DORA. Does that not cover this?
No. DORA displaces the parallel NIS2 obligations through NIS2's own Article 4 deferral mechanism. That mechanism is internal to NIS2 and has no effect on Regulation (EU) 2024/2847. The CRA imposes duties on manufacturers of products, not on financial entities, so there is nothing for a lex specialis argument to displace.

Is our mobile banking app in scope?
That is the genuinely open question, and it should be answered deliberately rather than assumed. The app is software with a data connection, supplied to the public in the course of a commercial activity, which is the statutory phrasing. The counter-argument is that it is the interface to a regulated service rather than a product supplied for use. Take a documented position; do not rely on the fact that it is free, because price is not the test.

What exactly triggers the 24-hour clock?
Becoming aware of a vulnerability in your product that is being actively exploited, or of a severe incident having an impact on the security of the product. Exploitation is the trigger, not severity and not customer impact — which is why it does not map onto DORA's major-incident classification.

Who do we actually file with?
Through the ENISA CRA Single Reporting Platform, addressed to the CSIRT designated as coordinator in the member state of your main establishment. ENISA receives it simultaneously, and the receiving CSIRT shares it with CSIRTs in other territories where the product is distributed. One submission, not several.

Does anything else start in September?
No. Only the Article 14 reporting obligations. The essential cybersecurity requirements, the SBOM duty, conformity assessment, technical documentation and CE marking all apply from 11 December 2027. Treating September as the whole file is the mirror image of ignoring it.

What is the downside if we get the scoping wrong?
Breaches of Articles 13 and 14 and of the Annex I essential requirements attract fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. The more immediate cost is procedural: a missed early warning cannot be cured retroactively, and the first time an institution discovers it was a manufacturer should not be while a CSIRT is asking why no notification arrived.

References #

• European Parliament and Council of the European Union, 2024. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2024..
• European Commission, 2026. Cyber Resilience Act — Reporting obligations. Brussels: Directorate-General for Communications Networks, Content and Technology. Available at: European Commission, 2026..
• European Commission, 2026. The Cyber Resilience Act — Summary of the legislative text. Brussels: Directorate-General for Communications Networks, Content and Technology. Available at: European Commission, 2026..
• European Parliament and Council of the European Union, 2022. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2022..
• European Parliament and Council of the European Union, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2022..

Last reviewed 2026-08-16.