CRA Article 14: what "aware" means for the 24-hour clock

The clock starts at awareness, not confirmation

CRA Article 14 requires a manufacturer to notify an actively exploited vulnerability in a product with digital elements through an early warning within 24 hours of becoming aware of it, a fuller notification within 72 hours, and a final report within 14 days.

The word that does the work is aware. Awareness is a factual threshold — the point at which you have reasonable grounds to believe a vulnerability in your product is being exploited in the wild. It is deliberately earlier than "confirmed", "triaged", or "reproduced in a lab". A team that waits for certainty before starting the clock has misread the obligation and will miss the 24-hour window on the incidents that matter most.

Why this is an operations problem, not a paperwork problem

If a credible signal about one of your dependencies lands at 18:00 on a Friday, the 24-hour clock is running through the weekend. The compliant path does not care whether anyone was watching. So the real questions are operational:

• Who is your named triage authority, and can they be reached out of hours?
• How does a signal reach a human — and is its arrival time recorded, not the time someone read it?
• What do you actually file, and into what?

The fastest-moving trigger produces no CVE

The exploitation events that put you on the clock quickest are often upstream package compromises — a hijacked or maliciously updated dependency — which produce no CVE at the moment they matter. A detection primitive built only on CVE feeds will not see them in time. A timestamped record of when the signal arrived is the single fact that determines Article 14 liability, so it is worth banking from day one.

The €15m / 2.5%-of-global-turnover penalty ceiling sits behind this obligation; the practical risk, though, is simply missing a 24-hour window nobody was staffed to catch.