New signups are temporarily closed.Existing customers can still sign in. Contact us to be notified when we reopen.
Skip to main content
← All articles
CRAincident-reportingNIS2GDPR

CRA reporting is live: the 24-hour clock started 11 September

Article 14 applies from 11 September 2026. Who counts as a manufacturer, what starts the 24-hour clock, the three filings, and the NIS2 and GDPR overlap that can pull one incident into three regulators.

EuroCompliant·

CRA reporting is live: the 24-hour clock started 11 September

On 11 September 2026, Article 14 of the Cyber Resilience Act started applying. Manufacturers of connected products sold in the EU now have 24 hours from the moment they become aware of an actively exploited vulnerability to file an early warning. The rest of the CRA waits until December 2027. This part does not.

Who has to report

Article 14 lands on manufacturers. You are one if you design, develop or produce a product with digital elements, or have someone do it for you, and you place it on the EU market under your own name or trademark. Importers and distributors carry other CRA duties, but not this one, unless they rebrand the product as their own.

A product with digital elements is software or hardware plus its remote data processing, including components sold separately. Mobile apps, firmware, sensors, industrial controllers and consumer devices all count.

Two things about scope catch people out. The risk class of your product is irrelevant here, so Annex III and IV classification changes nothing about whether you file. And the duty covers products already on the market, including ones you shipped years before September 2026.

The two triggers

Two events start the clock.

  • An actively exploited vulnerability is a flaw for which there is reliable evidence that someone exploited it without the owner's permission. Suspicion, a theoretical attack path, or an unconfirmed scanner alert does not qualify.
  • A severe incident is one that harms, or could harm, the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or could lead to malicious code running on the product or on a user's systems.

A single event can be both. You report once and cover both triggers.

When the clock actually starts

The regulation ties everything to "becoming aware", and the Commission's guidance published on 27 July 2026 defines that as the point where an initial assessment gives you a reasonable degree of certainty that the event happened. It is not the first alert from a scanner. It is also not the end of your investigation. Once you hold reliable technical indicators, start the filing and supplement it later.

The same guidance gives you one genuine escape. A false positive is not reportable, provided your assessment was timely, traceable and documented. Skipping the assessment is not an option.

There is no retrospective duty for a vulnerability you knew about before 11 September 2026 but had no evidence was being exploited. If exploitation surfaces afterwards, the clock starts at that point, not back at first knowledge.

The three filings

  • Early warning, within 24 hours of awareness. State the member states where the product has been made available. For an incident, state whether malice is suspected.
  • Full notification, within 72 hours of awareness. Cover the general nature of the flaw or incident, the corrective or mitigating measures you have taken, and the measures users can take.
  • Final report, 14 days after a fix is available for a vulnerability, or one month after the 72-hour filing for an incident. Cover severity, impact, root cause and the fix.

You file through the Single Reporting Platform. It reaches your coordinating CSIRT and ENISA together, so you file once. Article 14(8) adds a separate duty to inform affected users, and where appropriate all users, of the event and of any steps they can take. That duty is proportionate to the risk.

Reporting outlives your support window

The support-period rule is easy to misread. Your vulnerability handling obligations run for the support period, which the CRA sets at a minimum of five years. The reporting duty does not stop there. It attaches to the product, and it continues after you stop supporting it. Hardware you no longer sell stays in scope.

The triple-filing trap

One incident can pull in three regulators on three clocks.

  • The CRA wants an early warning within 24 hours of awareness.
  • NIS2 wants an early warning within 24 hours and a full notification within 72.
  • GDPR wants a personal data breach notification within 72 hours of awareness.
  • If a financial customer is involved, DORA's separate regime can require an initial notification within 4 hours of classifying a major incident.

The CRA filing is additional, not a substitute. It does not discharge a NIS2 or GDPR notification for the same event, and the thresholds and recipients differ across all three. The teams that cope classify the incident once against every regime and draw all the filings from a single evidence record. The teams that struggle keep separate notes and send the regulator two accounts of the same week.

What is not in force yet

Most of the CRA still waits. The essential cybersecurity requirements for products, vulnerability handling, technical documentation, conformity assessment and CE marking apply from 11 December 2027.

Article 14 stands on its own and applies now. If your programme is planned around the 2027 date, the reporting duty is already live and currently unowned.

The cost of getting it wrong

Article 64(2) sets the exposure, and Article 14 sits in the top tier. Non-compliance is subject to an administrative fine of up to 15 million euros or 2.5 percent of total worldwide annual turnover for the preceding financial year, whichever is higher.

What to do this week

  • Confirm the Single Reporting Platform account exists and that two people can log in from a phone, not just from a desk.
  • Write the 24-hour decision rule into your incident runbook. Name who declares reasonable certainty, and how they reach the on-call engineer at 3am.
  • Add every product to the reporting scope, supported or not. New development alone is not enough.
  • Pre-draft the 72-hour fields, so the team fills blanks under pressure instead of composing prose.
  • Run one tabletop: an exploited remote code execution flaw in last year's firmware, on a Friday night. Time the early warning.

What this means on the platform

We updated our CRA checklists and breach workflows the week Article 14 went live. The 24-hour, 72-hour and final-report deadlines sit in the obligations engine, and the reporting route through the Single Reporting Platform is attached to the obligation itself.

Because one incident can touch the CRA, NIS2 and GDPR at once, the platform tracks them as separate duties with their own clocks rather than collapsing them into a single deadline. Start an assessment and it maps the CRA reporting obligations that apply to your products.

Ready to get compliant?

Register your AI systems, classify risk, and generate audit-ready evidence.

Start free trial