EU Cyber Resilience Act and DORA
NIS2 regulates the organisations that run essential services. Two other EU laws complete the picture and come up in interviews for any EU role, or any company selling into the EU:
Last verified2026-10 — guidance and technical standards for both regulations are still being published; check the Official Journal and the European Commission's guidance before relying on exact wording.
regulates products: anything with software in it sold in the EU, from smart cameras to accounting software. It makes manufacturers responsible for security for the product's whole support life.
, the Digital Operational Resilience Act, regulates financial entities (banks, insurers, investment firms, crypto-asset providers) and their critical technology suppliers.
Organisations providing essential and important services. "Is your company secure?"
Products with digital elements placed on the EU market. "Is what you sell secure, and do you fix it?"
Financial entities and their ICT providers. "Can the financial system keep running through a cyber incident or supplier failure?"
The Cyber Resilience Act (CRA)
What is this?Regulation (EU) 2024/2847 sets security requirements for products with digital elements: hardware and software whose intended use includes a data connection to a device or network. It entered into force on 10 December 2024. Because it is a regulation, not a directive, it applies directly in every member state without national transposition.
Why it mattersIt is the first law to make software security a condition of selling the product, like electrical safety. Products will carry the CE mark to show they meet the cybersecurity requirements, and non-compliance can lead to fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, and withdrawal from the market.
Timeline
-
In forceAdopted10 Dec 2024
- Regulation (EU) 2024/2847 published
-
Reporting obligations applyReporting11 Sep 2026
- Manufacturers must report actively exploited vulnerabilities and severe incidents
-
All obligations applyFull11 Dec 2027
- Essential security requirements, conformity assessment, CE marking for products placed on the market
How it worksThe obligations fall on the manufacturer, meaning whoever sells the product under their own name, plus importers and distributors.
no known exploitable vulnerabilities at release, secure default configuration, protection of data, minimal attack surface (Annex I, Part I).
(Annex I, Part II): a coordinated vulnerability disclosure policy, a software bill of materials (SBOM) covering at least top-level dependencies, security updates free of charge and separate from feature updates where possible.
security updates for the product's expected lifetime, at least five years unless the product is expected to be used for less.
most products self-assess. "Important" products (class I and II, such as identity management software, password managers, VPNs, firewalls) need harmonised standards or third-party assessment, and "critical" products may require EU certification.
non-commercial open-source projects are outside the scope; "open-source stewards" (foundations supporting commercially used projects) have light obligations.
Reporting clocks (from 11 September 2026)For an actively exploited vulnerability or a severe incident affecting the product's security:
| Step | Deadline |
|---|---|
| Early warning | 24 hours after becoming aware |
| Notification with details | 72 hours |
| Final report | 14 days after a fix is available (exploited vulnerability), or one month after the notification (severe incident) |
Reports go through ENISA's Single Reporting Platform to the national CSIRT and ENISA. Users must also be informed, with mitigation advice. The Commission's guidance says the clock starts once an initial assessment gives reasonable certainty, not at the first suspicious signal, and that exploitation known before 11 September 2026 needn't be reported retroactively.
In practiceThe CRA turns things security teams already recommend into evidence a regulator can ask for:
CRA technical file — router firmware 4.2 (abridged)
Risk assessment ............ threat model v3, reviewed 2026-08 ← Annex I, Part I
SBOM ....................... CycloneDX 1.6, generated per release, 214 components
Vulnerability disclosure ... security.txt + PSIRT inbox, 90-day disclosure policy
Support period ............. security updates until 2031-12 (stated on the box and website)
Update mechanism ........... signed OTA updates, automatic by default, user can opt out
Exploited-vuln process ..... PSIRT on-call, 24h early warning via ENISA SRP ← live since 11 Sep 2026🎯On the job. For a product company, CRA readiness is mostly product-security hygiene with deadlines: an SBOM generated in CI for every release, a working PSIRT (product security incident response team) with an on-call rota able to file a 24-hour report, a published support period, and a signed update mechanism. The first engineering question to ask is "can we tell, within hours, which shipped versions contain a given vulnerable component?"
DORA — Digital Operational Resilience Act
What is this?Regulation (EU) 2022/2554, applying since 17 January 2025, harmonises ICT (information and communication technology) risk rules for about 20 types of financial entity, from banks to crypto-asset service providers. It is backed by detailed regulatory technical standards from the European Supervisory Authorities (EBA, EIOPA, ESMA).
Why it mattersFinance depends on a few large technology providers, so a cloud or software outage can become a financial-stability problem. DORA treats operational resilience, not just data protection, as a regulated obligation, and for the first time gives EU supervisors direct oversight of critical ICT third-party providers, such as major cloud platforms.
How it worksFive pillars:
A board-approved framework: asset inventory, protection, detection, response, recovery, backup and testing. The management body is ultimately responsible
Classify ICT incidents; report major ones to the competent authority on fixed clocks
Annual testing of critical systems; threat-led penetration testing (TLPT, based on TIBER-EU) at least every three years for significant entities
A register of all ICT contracts, mandatory contract clauses (audit rights, exit plans, incident support), concentration-risk assessment
Voluntary exchange of threat intelligence between financial entities
Major incident reporting clocks
| Report | Deadline |
|---|---|
| Initial notification | Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it |
| Intermediate report | Within 72 hours of the initial notification |
| Final report | Within one month of the latest intermediate report |
📰Real incident — CrowdStrike content update (2024). A faulty Falcon sensor configuration update crashed about 8.5 million Windows machines worldwide on 19 July 2024, grounding flights and disrupting banks, payment systems and hospitals. It wasn't an attack, which is exactly DORA's point: operational resilience covers failures at critical ICT providers, not only hackers. Under DORA, financial entities must map such dependencies, test exit and recovery plans, and report major ICT incidents whatever the cause.
🎯On the job. At a bank or fintech, DORA work for a security engineer usually means: keeping the ICT asset and third-party register accurate, building runbooks that can classify an incident as major within hours, preparing for threat-led penetration tests, and making sure contracts with cloud and SaaS providers include audit rights, incident notification and an exit plan.
How They Fit Together
| NIS2 | CRA | DORA | |
|---|---|---|---|
| Legal form | Directive (national laws) | Regulation (directly applicable) | Regulation (directly applicable) |
| Regulates | Organisations in critical sectors | Products with digital elements | Financial entities and critical ICT providers |
| Applies from | 18 Oct 2024 | Reporting 11 Sep 2026; fully 11 Dec 2027 | 17 Jan 2025 |
| First report | 24 hours (early warning) | 24 hours (early warning) | 4 hours after classification as major |
| Max fine | €10m or 2% (essential entities) | €15m or 2.5% | Set by member states |
| Overlap rule | DORA replaces NIS2's ICT rules for financial entities | Complements NIS2: NIS2 entities buy CRA-compliant products | Specific law for finance (lex specialis) |
Interview Questions
NIS2 regulates organisations that run essential and important services, like energy, health and digital infrastructure, and requires risk-management measures and incident reporting. The Cyber Resilience Act regulates products: anything with software sold in the EU must be secure by design, come with an SBOM and get security updates for its support period, and manufacturers must report actively exploited vulnerabilities within 24 hours since September 2026. DORA is the financial sector's specific regime, applying since January 2025, covering ICT risk, incident reporting within four hours of classification, resilience testing and oversight of critical tech suppliers.
Since 11 September 2026 the manufacturer must send an early warning within 24 hours of becoming aware, through ENISA's Single Reporting Platform, then a notification with details within 72 hours, and a final report within 14 days of a fix being available. It must also inform users with mitigation guidance. In practice that requires a PSIRT on call, a way to identify affected versions quickly, which is where SBOMs matter, and pre-agreed templates, because 24 hours goes fast.
The bank must record the provider in its register of ICT third-party arrangements, assess concentration risk, and make sure the contract includes the DORA clauses: service levels, audit and access rights, incident notification, data location and a tested exit strategy. Critical functions running there must be covered by resilience testing, including threat-led penetration tests at least every three years for significant entities. And if the provider has an outage, the bank still has to classify and report it as a major ICT incident if it qualifies; the CrowdStrike update in 2024 showed that a supplier failure, not an attacker, can be the incident.
Because most product vulnerabilities are in third-party components, and the 24-hour reporting clock means a manufacturer must quickly know which shipped versions contain a vulnerable library. An SBOM generated for each release answers that in minutes instead of days, as Log4Shell showed when companies spent weeks finding where they used Log4j. The CRA requires manufacturers to keep an SBOM covering at least top-level dependencies, which turns a good practice into evidence a market surveillance authority can request.