Does the Article 14 clock start when a report lands in our security inbox?

No. Article 14(2) and 14(4) run the 24-hour and 72-hour clocks from the manufacturer becoming aware of an actively exploited vulnerability or a severe incident — not from receipt of a tip-off. Commission guidance C(2026) 5252 paragraph 213 treats the tip-off as a suspicious event that you should assess immediately; awareness comes after that initial assessment.

What does 'becoming aware' actually mean under the Commission guidance?

Paragraph 213 of C(2026) 5252: after an immediate initial assessment of a suspicious event, you have a reasonable degree of certainty that (i) a vulnerability in your product with digital elements is being actively exploited, or (ii) a severe incident has occurred and compromised that product's security. Reasonable certainty, not a finished root-cause analysis.

Can we delay the initial assessment to push the deadline back?

That is not a credible reading. Paragraph 213 says assess the suspicious event immediately; paragraph 214 puts the emphasis on prompt action, especially where the vulnerability may pose a significant risk. A gap between first signal and awareness needs to be filled with assessment work you can explain later, not with waiting.

Do we have to report exploitation we already knew about before 11 September 2026?

No, for that specific case. Paragraph 217 of the same guidance says the CRA does not require retroactive reporting of actively exploited vulnerabilities of which you had already become aware before 11 September 2026. If you knew about the vulnerability earlier but only become aware of active exploitation on or after that date, the reporting duty does apply — including for products placed years earlier (see the legacy-products guide).

Is the ENISA SRP's 72-hour counter the same as the legal awareness clock?

Not today. The portal's visible 72-hour counter runs from early-warning submission (48 hours after that submit), not from awareness — see our ENISA SRP 72-hour counter guide. Your legal 24-hour and 72-hour clocks still run from awareness under Article 14. Record your own awareness timestamp; don't let the portal counter redefine it.

What should we write down when we set the awareness time?

At minimum: when the first signal arrived, when the initial assessment finished, who assessed it, what evidence produced reasonable certainty, and when each Article 14 stage was submitted. That awareness time is what you enter into the free desk or deadline calculator — it drives every downstream clock.

CRA Article 14 becoming aware: when the 24-hour clock starts

What Article 14 actually times from

Article 14(2) (actively exploited vulnerabilities) and Article 14(4) (severe incidents) each require an early warning without undue delay and in any event within 24 hours of the manufacturer becoming aware, then a fuller notification within 72 hours of becoming aware. The reporting deadlines guide covers the full chain. None of those paragraphs defines "becoming aware." That gap is why teams either start the clock too early (on inbox arrival) or too late (after a full forensic write-up).

The Commission's test (C(2026) 5252 §213–214)

Section 9.1 of the Commission guidance on the application of the Cyber Resilience Act (document C(2026) 5252) fills the gap. Paragraph 213 says that when you detect a suspicious event, or a third party — customer, researcher, authority, media, or other source — brings a potential incident or vulnerability to your attention, you should assess that event immediately. You are regarded as having become aware when, after that initial assessment, you have a reasonable degree of certainty that:

a vulnerability contained in your product with digital elements is being actively exploited; or
a severe incident has occurred and has led to the security of that product being compromised.

Paragraph 214 adds that how long the assessment takes depends on the case — sometimes it is clear from the outset; sometimes it takes time to establish whether your product is affected and whether exploitation or security impact is real. The emphasis, though, is on prompt action to carry out that initial assessment, especially where the vulnerability may pose a significant risk, and then to remediate and notify.

Three moments to keep apart

Treat these as separate timestamps in your case file:

First signal — the email, ticket, alert, or call arrives. Assessment duty starts; the Article 14 clock does not.
Awareness — the initial assessment reaches reasonable certainty that an Article 14 trigger is met. This is the legal start of the 24-hour and 72-hour clocks.
Submission — you file the early warning (and later stages) on the Single Reporting Platform. Useful evidence; not a substitute for the awareness time.

Waiting for a complete root-cause analysis is usually too late for "reasonable degree of certainty." Conversely, treating every unread tip as awareness is usually too early. The guidance deliberately sits in the middle: prompt triage, then a defensible awareness call.

Pre-11 September 2026 exploitation

Paragraph 217 clarifies that because the duty turns on becoming aware of active exploitation, you are not required to report vulnerabilities of whose active exploitation you had already become aware before 11 September 2026. There is no retroactive backlog of those cases. If you knew the vulnerability existed earlier but only become aware of active exploitation on or after that date, the reporting obligation does apply — including for products placed years earlier under Article 69(3) legacy-product reporting. That distinction is why the awareness record matters even for older CVEs.

Don't confuse awareness with the SRP counter

ENISA's portal shows a 72-hour counter that, today, effectively runs from early-warning submission — not from awareness. That is a UI convenience, not a rewrite of Article 14. See ENISA SRP 72-hour counter vs the legal clock. Keep your own awareness timestamp; feed that time into the calculator and the desk when you track a case.

What to put in the evidence log

When you set awareness, capture enough that someone else can reconstruct the call: signal received (time and source), assessment started, awareness concluded (time, assessor, evidence relied on), and each submission time. The evidence log guide lists the surrounding fields. Paragraph 212 of the guidance also notes that this awareness concept was aligned with NIS2 implementing guidance and EDPB personal-data-breach practice — so one well-kept timeline often supports more than one regime, even though the filings stay separate (see CRA vs NIS2 reporting).

Questions people ask

Does the Article 14 clock start when a report lands in our security inbox?: No. Article 14(2) and 14(4) run the 24-hour and 72-hour clocks from the manufacturer becoming aware of an actively exploited vulnerability or a severe incident — not from receipt of a tip-off. Commission guidance C(2026) 5252 paragraph 213 treats the tip-off as a suspicious event that you should assess immediately; awareness comes after that initial assessment.
What does 'becoming aware' actually mean under the Commission guidance?: Paragraph 213 of C(2026) 5252: after an immediate initial assessment of a suspicious event, you have a reasonable degree of certainty that (i) a vulnerability in your product with digital elements is being actively exploited, or (ii) a severe incident has occurred and compromised that product's security. Reasonable certainty, not a finished root-cause analysis.
Can we delay the initial assessment to push the deadline back?: That is not a credible reading. Paragraph 213 says assess the suspicious event immediately; paragraph 214 puts the emphasis on prompt action, especially where the vulnerability may pose a significant risk. A gap between first signal and awareness needs to be filled with assessment work you can explain later, not with waiting.
Do we have to report exploitation we already knew about before 11 September 2026?: No, for that specific case. Paragraph 217 of the same guidance says the CRA does not require retroactive reporting of actively exploited vulnerabilities of which you had already become aware before 11 September 2026. If you knew about the vulnerability earlier but only become aware of active exploitation on or after that date, the reporting duty does apply — including for products placed years earlier (see the legacy-products guide).
Is the ENISA SRP's 72-hour counter the same as the legal awareness clock?: Not today. The portal's visible 72-hour counter runs from early-warning submission (48 hours after that submit), not from awareness — see our ENISA SRP 72-hour counter guide. Your legal 24-hour and 72-hour clocks still run from awareness under Article 14. Record your own awareness timestamp; don't let the portal counter redefine it.
What should we write down when we set the awareness time?: At minimum: when the first signal arrived, when the initial assessment finished, who assessed it, what evidence produced reasonable certainty, and when each Article 14 stage was submitted. That awareness time is what you enter into the free desk or deadline calculator — it drives every downstream clock.