On 11 September 2026, the first binding part of the EU Cyber Resilience Act (CRA) started to apply. It is not the product-design rules, which wait until 11 December 2027. It is Article 14: the duty for manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents to the authorities, on a clock measured in hours.

Software makers selling into the EU now have a legal reporting obligation with no grace period and no dependence on whether the rest of their CRA compliance work is finished. This piece covers what triggers a report, what each filing has to contain, and the operational gaps teams are most likely to hit.

What triggers a report

Two events create the duty, and both are narrower than “any security problem.”

An actively exploited vulnerability. The test is evidence, not suspicion. Ireland’s National Cyber Security Centre, in its CRA guidance, describes it as a flaw where reliable evidence shows a malicious actor is actively exploiting it. A proof-of-concept on GitHub, or a high CVSS score, does not by itself meet that bar. Confirmed exploitation in the wild does.

A severe incident. This is an incident that affects, or is capable of affecting, the product’s ability to protect sensitive or important data or functions, or that has led, or could lead, to malicious code being introduced or executed. The “capable of” wording matters: an attack that was stopped but demonstrates the product could have been compromised can still count.

The obligation also reaches components you did not write. NCSC’s guidance says that if a third-party component inside your product has an actively exploited vulnerability or a severe incident, you report once you confirm your product is affected. Products already on the EU market are not exempt simply because they shipped before the CRA’s main application date; the NCSC page says products placed on the market before December 2027 remain in scope for reporting while they stay available there.

The three-stage clock

Reporting runs in stages, and the early stages are deliberately thin so they can be filed fast.

  1. Early warning, within 24 hours of becoming aware. NCSC’s guidance is blunt that you should not hold this back for deep technical analysis.
  2. Detailed notification, within 72 hours. This covers severity, root cause where known, and any temporary mitigations. Information can be added progressively, and the national CSIRT acting as coordinator can ask for an interim report.
  3. Final report. For an actively exploited vulnerability, within 14 days after a corrective or mitigating measure is available. For a severe incident, within one month after the detailed notification.

The vulnerability clock for the final report starts when a fix or mitigation exists, not when you learned of the flaw. That leaves the first two stages as the real pressure: you may have a 24-hour deadline before you know whether you can patch at all.

How filing works: the Single Reporting Platform

All three stages go through the Single Reporting Platform (SRP) run by ENISA, the EU cybersecurity agency. One submission is routed to the relevant national CSIRT and to ENISA, and then shared with other CSIRTs as needed, so a manufacturer notifies once rather than once per member state.

Several practical details from the published guidance deserve attention before an incident, not during one:

  • Only SRP submissions count. NCSC states that only reports submitted through the platform satisfy the legal obligation. There is an email fallback, but it applies only if ENISA officially declares the SRP offline, and it is treated as voluntary alerting. Once the platform is back, you still file formally.
  • Access is person-based. Manufacturers act through designated authorised representatives using individual EU Login accounts with multi-factor authentication. Law-firm commentary on the launch describes one primary representative and up to 20 secondary ones. That role is internal to reporting and is not the same as the Article 18 authorised representative who deals with market surveillance authorities.
  • Registration timing. NCSC says no pre-registration is needed because the account is created on first submission, and one law-firm alert reports that ENISA does not recommend registering before a reportable event. Even so, EU Login accounts with working MFA should exist for your named representatives before anyone needs them at 3 a.m.

The question that trips up multinationals

Notifications go to the CSIRT of the member state where the manufacturer has its main establishment. Commentary on the launch notes that this means the place where product cybersecurity decisions are predominantly taken, which can be an engineering site rather than headquarters, and that no published EU guidance yet lists factors for that determination. Choosing wrongly risks having a submission rejected and refiled while the clock runs.

If your engineering, security and legal functions sit in different countries, write down the analysis now and have counsel sign off. A one-page memo is cheap compared with a dispute over where a 24-hour filing should have gone.

What to have in place

Most of the failures will be organisational rather than technical. A workable readiness list:

  • Named decision rights. One person classifies an event as “actively exploited” or “severe incident,” with a backup. Debate about classification is the usual cause of missed 24-hour windows.
  • An awareness log. Record when the organisation became aware, who decided on classification, and when each stage was submitted. The clock runs from awareness, so you need a defensible timestamp.
  • Templates. Pre-written early-warning and detailed-notification drafts, so the first filing is a fill-in exercise.
  • Supplier clauses. Embedded and open-source components are the likeliest source of a report you did not see coming. Contracts should require suppliers to tell you about exploited vulnerabilities and incidents, and your vulnerability monitoring should track exploitation status (for example, known-exploited catalogues), not only severity scores.
  • Updated response plans. Incident response and PSIRT procedures need CRA triggers, the three deadlines and out-of-hours coverage built in.

What is still unsettled

Several things remain unclear from the sources reviewed. The law-firm alerts used here are secondary summaries; the regulation text and ENISA’s own SRP guidance are the authority and should be checked before you build procedures. The main-establishment test has no official factor list yet. And this article does not cover penalties, which the guidance pages consulted do not address.

The practical takeaway: treat 11 September 2026 as a live operational date, not a 2027 project. If you cannot today name who files, through which accounts, to which CSIRT, and on what evidence threshold, that is the gap to close first.