CRA Meets NIS2 Meets DORA: One Vulnerability, Three Reporting Clocks

From 11 September 2026 a single exploited vulnerability can start three EU reporting clocks at once, each with a different trigger, a different deadline and a different authority at the other end. A human reading the incident under pressure will miss one.

The Cyber Resilience Act’s reporting obligations under Article 14 start applying on 11 September 2026. That date matters for anyone who ships a product with digital elements, because it is the point at which the CRA joins two incident-reporting regimes that are already live: NIS2, in application across the Member States that have transposed it, and DORA, applying to financial entities since January 2025. The regimes were written separately, by different directorates, on different timetables. Nobody reconciled the clocks. So the firm that sits under more than one of them inherits the reconciliation problem, and it inherits it at the worst possible moment: the hours after an exploited vulnerability is confirmed.

Three regimes, three clocks that do not line up

Start with what each regime actually demands, because the deadlines look similar enough to lull you and are different enough to catch you.

CRA (Regulation (EU) 2024/2847). A manufacturer that becomes aware of an actively exploited vulnerability in its product, or a severe incident affecting that product’s security, files an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days of a corrective measure becoming available (one month for a severe incident). Notifications go through the CRA single reporting platform to the CSIRT of the manufacturer’s main establishment, with ENISA in copy.

NIS2 (Directive (EU) 2022/2555). An essential or important entity that becomes aware of a significant incident files an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. Notifications go to the national CSIRT or competent authority.

DORA (Regulation (EU) 2022/2554). A financial entity classifies an ICT-related incident and, if it is major, files an initial notification as early as possible within 4 hours of classification but no later than 24 hours from becoming aware, an intermediate report within 72 hours of the initial notification, and a final report within one month of the last intermediate report. Notifications go to the home-state competent authority acting as the single entry point.

Three sets of numbers that rhyme but do not match. The final-report windows anchor to different events. The CRA final report waits on a corrective measure; the DORA one counts from the intermediate report. And the recipients are three different front doors. If you want the board-level view of how these map together, we have set it out in the cyber-incident reporting map.

The trap is the trigger, not just the deadline

The deadlines are the visible problem. The trigger is the one that quietly sinks you. CRA and NIS2 both start their 24-hour clock at awareness. DORA starts its reporting clock at classification — a separate step that must itself happen without undue delay, in practice within 24 hours of detection. So the same incident has two different zero points depending on which regime is reading it, and a team that treats “we became aware at 09:00” as the single start time will compute the DORA deadline wrong in both directions: too early if it forgets the classification step exists, too late if it lets classification drift.

There is a second trap, and it is the one most firms get wrong in the other direction: assuming all three always fire. They do not. NIS2 gives way to sector-specific Union law where that law imposes equivalent reporting, so a financial entity generally reports its ICT incident under DORA rather than NIS2, not both. But the CRA obligation attaches to the manufacturer role — it stacks on top regardless of whether you also report as an entity. A fintech that ships a product with digital elements can therefore owe CRA and DORA on one vulnerability, while a group that contains both a financial entity and a separately-regulated essential entity can owe DORA and NIS2 across two legal persons for the same root cause. The point that the CRA is a product duty and NIS2 an entity duty is the one we laboured in why ‘entity’ and ‘product’ obligations do not merge, and it is exactly why you cannot hard-code “fire all three”.

Classify once, route many

The design that survives contact with a live incident is a router. You capture the event’s attributes once — the roles the firm holds, whether a vulnerability is actively exploited, the severity, the timestamps of detection and classification — and you let a decision table derive each regime’s applicability, clock and destination. The judgement about severity and exploitation stays human; the derivation of which clock started when and where it points does not, because that is deterministic and a person under pressure will get it wrong. Hold the mapping as versioned configuration, not as prose in a runbook, so it can be tested and changed as the transposing laws and the RTS templates settle.

# incident-router.yaml
# Classify the event once; derive each regime's obligation.
# Clocks and recipients differ. Do not assume all three fire.

regimes:
  cra:                              # Regulation (EU) 2024/2847, Art. 14
    applies_when:
      role: manufacturer            # firm ships a product with digital elements
      trigger: [actively_exploited_vulnerability, severe_incident]
    clock_starts: awareness
    deadlines:
      early_warning: 24h
      notification:  72h
      final:
        vulnerability:   corrective_measure_available + 14d
        severe_incident: 30d
    submit_to: cra_single_reporting_platform   # CSIRT of main establishment + ENISA
    live_from: 2026-09-11

  nis2:                             # Directive (EU) 2022/2555, Art. 23
    applies_when:
      role: [essential_entity, important_entity]
      trigger: significant_incident
      unless: sector_specific_act_reports_equivalent   # lex specialis, e.g. DORA
    clock_starts: awareness
    deadlines:
      early_warning: 24h
      notification:  72h
      final:         30d
    submit_to: national_csirt

  dora:                             # Regulation (EU) 2022/2554, Art. 19 + RTS 2025/301
    applies_when:
      role: financial_entity
      trigger: major_ict_incident
    clock_starts: classification    # NOT awareness
    classify_by: 24h_from_awareness
    deadlines:
      initial:      4h_from_classification   # hard ceiling 24h_from_awareness
      intermediate: 72h_from_initial
      final:        30d_from_last_intermediate
    submit_to: competent_authority  # home-state single entry point

The value is not the file. It is that the file forces you to name the awkward fields — the unless on NIS2, the separate classify_by on DORA — that a manual playbook leaves implicit and therefore leaves to be discovered live.

What the router must not do

Two failure modes bracket the design. Under-report and you miss a clock — the DORA classification step lapses, or the CRA manufacturer duty is forgotten because everyone was focused on the entity duty. Over-report and you file the same incident to NIS2 and DORA when lex specialis meant only one was owed, generating contradictory narratives that supervisors compare and that your own final reports then have to reconcile. The router’s job is to be right about applicability first and timing second, in that order. It should also keep the reports as separate, regime-shaped artefacts drawn from one evidence base, not one document reformatted three ways — the ENISA-facing CRA notification and the competent-authority DORA report ask different questions, as the emerging CRA single reporting platform makes plain.

None of this removes the human. Someone still decides whether the vulnerability is actively exploited and whether the incident is major, and those decisions carry the report. What the router removes is the clerical arithmetic of overlapping timers that no one can do reliably at 02:00 with an active exploit in the estate. If you are standing up the operating model behind it, the DORA incident-reporting architecture is the natural spine to hang the other two regimes off, because it already forces the classification discipline the others merely assume.

The firms that will struggle in September are not the ones that lack a playbook. They are the ones with three playbooks, in three teams, and no single place that decides which clocks are running.