When does CRA Article 14 reporting start?

The reporting obligations apply from 11 September 2026 — over a year before the CRA's main obligations (11 December 2027). If you manufacture a product with digital elements sold in the EU, the clocks are live from that date.

What must be reported under Article 14?

Two things: an actively exploited vulnerability in your product, and a severe incident having an impact on the security of your product. Each triggers an early warning within 24 hours of awareness and a notification within 72 hours, submitted via the single reporting platform to the coordinating CSIRT and ENISA.

When is the final report due?

For an actively exploited vulnerability: no later than 14 days after a corrective or mitigating measure is available — that clock starts when your fix ships, not when you became aware. For a severe incident: within one month after the 72-hour notification.

Do users have to be told?

Yes. Manufacturers must inform impacted users about the incident or vulnerability without undue delay, including risk-mitigation and corrective measures they can apply.

CRA Article 14: the 24-hour clock, explained.

From 11 September 2026, any manufacturer of a product with digital elements sold in the EU must report actively exploited vulnerabilities and severe incidents — with an early warning due 24 hours after you become aware. This is the CRA obligation that arrives first, a full fifteen months before the CE-marking regime. Here is what triggers the clock, what each deadline requires, and how to be ready before the first bad Friday night.

The clock goes live11 September 2026Article 14 reporting applies from this date, via the single reporting platform (ENISA). The CRA's main obligations — essential requirements, CE marking — follow on 11 December 2027.

Who has to report

Manufacturers of products with digital elements placed on the EU market — which reaches far beyond hardware vendors. If you ship a downloadable app, an SDK or library, firmware, or a connected device, you are likely in scope; a pure web platform consumed as a service generally is not. Not sure? The scope question is its own guide — settle it first, because everything below only bites if the answer is yes.

The two triggers

An actively exploited vulnerability — there is reliable evidence that someone is executing malicious code, or bypassing security, using a vulnerability in your product, on a system they have no permission to touch. Not a theoretical CVE — one being used, in the wild, now.
A severe incident having an impact on the security of your product — for example a compromise of your build or update pipeline, or an incident that degrades the product's ability to protect its users' data.

Either one starts the same clock — and the clock starts at awareness, not at confirmation, triage or fix.

The deadlines, in order

Step	Deadline	What it must contain
Early warning	24 hours	That the thing happened — and for a vulnerability, whether it's exploited and which member states are affected. Submitted via the single reporting platform, reaching your coordinating CSIRT and ENISA.
Notification	72 hours	The detail: the nature of the vulnerability or incident, its severity and impact, and — for a vulnerability — any corrective or mitigating measures available and what users can do.
Final report — vulnerability	14 days after the fix	Due no later than 14 days after a corrective or mitigating measure is available. That clock starts when your fix ships — not when you became aware.
Final report — incident	1 month	Due within one month after the 72-hour notification: root cause, mitigation, and any cross-border impact.

And your users

Reporting to the authorities is not the whole duty. Manufacturers must also inform impacted users — without undue delay — about the incident or vulnerability and the corrective or mitigating measures they can apply. A report filed with ENISA while your users stay in the dark is half a compliance.

What trips teams up

The clock starts at awareness. The 24 hours run from the moment your firm becomes aware — a support ticket, a researcher's email, a security vendor's alert. If your on-call process can't produce an early warning on a Saturday, you don't have an Article 14 process yet.
The final-report clock is different for vulnerabilities. Fourteen days after the fix is available — teams that diarise "14 days after awareness" file either too early with nothing to say, or forget entirely once the fix ships.
No register, no defence. A market-surveillance authority can ask how you handled a report. An internal register — what you knew, when, what you filed, when — is the difference between an answer and a scramble.
Voluntary reporting exists. If something looks serious but you're unsure it meets the threshold, you can report voluntarily rather than argue definitions at hour 23.

How to be ready before September

Settle scope now — is your product in scope, and in which risk class?
Name the owner — one person (with a deputy) who files, out of hours included.
Stand up the register — log every candidate event with its awareness timestamp, and let the deadlines compute from it.
Draft the notification before you need it — a template holding the product, versions, contacts and structure, so hour one is about facts, not formatting.
Drill it once — a tabletop run of a Friday-evening awareness → Saturday early warning proves more than any policy document.

Log it, and the clocks run themselves

Open the CRA module →

Log a vulnerability or incident — the Article 14 countdown starts, the ENISA notification drafts itself, and your reporting register builds as you go. In your browser · nothing uploaded

This guide is general information, not legal advice. Timelines and thresholds are set by Regulation (EU) 2024/2847, Article 14 — confirm the current requirement against the regulation and, where needed, qualified counsel. CleanDesk is decision-support: it drafts and tracks, your firm reviews and files.