When does the 24-hour deadline start? Awareness under Article 14 CRA

Under Article 14(2) and (4) of Regulation (EU) 2024/2847, the 24-hour deadline for the early warning notification runs from "the manufacturer becoming aware", not from the moment an e-mail lands in the mailbox. According to the Commission guidance C(2026) 5252, the manufacturer is aware when, after an initial assessment, it knows with a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident has compromised the security of the product. The initial assessment must begin immediately. Because the ENISA platform neither asks for this moment unambiguously nor uses it for its deadline counters so far, manufacturers have to document it themselves, with evidence.

What the Regulation says

Article 14(1) requires manufacturers to notify any actively exploited vulnerability "that it becomes aware of". Paragraph 2 sets the deadlines of 24 and 72 hours, each running from "the manufacturer becoming aware"; paragraph 4 does the same for severe incidents. The Regulation does not say what "becoming aware" means. It does, however, define in Article 3, point (42), what the manufacturer has to be aware of:

"actively exploited vulnerability" means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner

Article 3, point (42) CRA

Awareness therefore requires "reliable evidence". A suspicion, a scanner finding or an entry in the public vulnerability database CVE does not meet that test. At the same time, the definition does not require a full investigation: it is enough that exploitation in a single system is proven. What counts as a trigger is covered in the guide Actively exploited vulnerability.

What the Commission guidance means by awareness

The guidance C(2026) 5252 of 27 July 2026 is not legally binding, but it is the only interpretation available. Paragraph 213 describes the moment. Where the manufacturer detects a suspicious event, or a third party brings one to its attention, "the manufacturer should assess the suspicious event immediately". The manufacturer is then to be regarded as having become aware

"when, after such an initial assessment, it has a reasonable degree of certainty that: (i) a vulnerability contained in its product with digital elements is being actively exploited; or (ii) a severe incident has occurred and has led to the security of its product with digital elements being compromised".

Commission guidance C(2026) 5252, Annex, paragraph 213

Three things follow from this. A tip-off, whether from a customer, a researcher, an authority or the media, is at first a "suspicious event", not the start of the deadline. The initial assessment must begin "immediately"; paragraph 214 puts the emphasis on "prompt action", especially where the risk is high. And the threshold is a "reasonable degree of certainty", not certainty: if you wait for the finished root-cause analysis, you became aware long before.

Paragraph 212 deliberately aligns this reading with the concept of awareness in Implementing Regulation (EU) 2024/2690 under the NIS2 Directive (the EU directive on the security of network and information systems) and with the European Data Protection Board's guidelines on personal data breaches. You can therefore determine the timestamp once and use it for all three reporting channels; the thresholds and forms remain different.

Receipt, reading, awareness: which moment counts?

The most common mistake runs in both directions. Some count from the moment the e-mail arrives; others leave it until Monday and count from when it is read. Both are wrong. Three moments need to be kept apart:

1. ReceiptThe e-mail is in the mailbox. The deadline is not yet running. The duty to carry out an immediate initial assessment, however, arises now, not when someone happens to look.
2. ReadingSomeone opens the e-mail. That does not start the deadline either; it starts the initial assessment.
3. AwarenessThe initial assessment shows, with a reasonable degree of certainty: our product, actively exploited. From this point the 24 and 72 hours run.

Does that mean nothing runs as long as nobody opens the mailbox? The wording could be read that way, but it would be unwise to rely on it. In paragraph 212 the guidance expressly aligns the concept of awareness with data protection law. There, it is the organisation that becomes aware, not an individual, and under Guidelines 9/2022 of the European Data Protection Board controllers must have measures in place to detect an incident immediately. If a report sits unread because nobody is responsible for it, data protection practice works from the time at which it would have been read in a properly run organisation. Whether market surveillance authorities and CSIRTs will take the same view under the CRA is open; there is no regulatory practice yet. But if you publish your security address in a security.txt file, you will find it hard to present an unread weekend as a lack of awareness.

Neither the Regulation nor the guidance requires the mailbox to be staffed around the clock. What is required is an organisation in which a report promptly reaches someone who can read and classify it, at weekends too. Nobody says how long the initial assessment may take; "immediately" and "prompt action" are the only yardsticks. If a customer sends logs that prove the access, awareness in practice coincides with reading. The gap between receipt and awareness has to be filled with work, not with waiting.

Two distinctions. If a security researcher demonstrates an exploit, findings from good-faith testing are not active exploitation under recital 68; the coordinated vulnerability disclosure (CVD) process runs, the deadline does not. If a third party voluntarily reports the exploitation to the CSIRT, the CSIRT informs the manufacturer without undue delay under Article 15(4), and the manufacturer's initial assessment runs from that point.

No retrospective reporting before 11 September 2026

Under Article 71(2), the reporting obligation has applied since 11 September 2026 and, under Article 69(3), it also covers products placed on the market before 11 December 2027, including products that were already on the market before the obligation took effect. Paragraph 217 of the guidance makes clear that exploitation of which the manufacturer was aware before that date does not have to be reported retrospectively. If the vulnerability was known beforehand but its exploitation was not, and the exploitation becomes known afterwards, it must be reported. ENISA says the same in its frequently asked questions (FAQ 13), as does the Commission services' FAQ (question 5.3, as of 4 September 2026); like the guidance, neither is binding. Here, the moment of awareness decides whether there is an obligation at all.

Four timestamps you should record

In the current release, ENISA's single reporting platform still labels its time field as the time of detection, not of awareness. According to the ENISA FAQ of 3 October 2026, a field "Date/Time when you became aware" will only be used to calculate deadlines in a future release; until then, the portal's 72-hour counter runs from the submission of the early warning, which is wrong. The manufacturer therefore has to keep its own evidence. Four timestamps are enough, all in UTC (Coordinated Universal Time, so that time zones play no part), each with supporting evidence:

1. First observationWhen the tip-off arrived or your own monitoring raised an alert. Evidence: e-mail headers, ticket, log extract.
2. AwarenessWhen the initial assessment was completed with a reasonable degree of certainty. Evidence: a short note of the result, the basis (which logs, which customer confirmation) and who was involved. This timestamp starts the 24 and 72 hours.
3. EscalationWhen the call chain was triggered and who took the case on. Evidence: call log, message, ticket assignment.
4. SubmissionWhen the early warning and the later stages were submitted on the platform. Evidence: the platform's confirmation e-mail.

A record like this is the only way to defend the 24-hour deadline later.

Which time belongs in the time field of the early warning? For an incident, ENISA's SRP glossary (version 1.4, field i37) describes the field as the time of awareness: "enter the date and time you became aware of the incident"; in the current release it is still labelled "Date and time when the incident was detected". A separate field asks when the incident began. According to ENISA FAQ 26, deadline calculation is to be based on this field in future, and paragraph 213 of the guidance distinguishes noticing a suspicious event from awareness after the initial assessment. For incidents, the field should therefore contain the time of awareness from your awareness record, not the first observation. Mention both times briefly in the summary so that the entry can be followed; that is our recommendation, not an ENISA requirement. No source says whether an authority will later treat the time entered as the start of the deadline. For vulnerabilities the field only arrives with the next release, and so far the glossary describes it, inconsistently, as the time of first discovery.

A weekend, worked through

A manufacturer of packaging machines in Germany; all details are invented, times are in Central European Summer Time:

Two lessons. The deadline did not start on Friday at 23:40 but on Saturday at 09:50, because only then was the assessment complete; the seven hours before the e-mail was read must still be explainable. And Article 14 speaks of hours, not working days; the Regulation makes no exception for weekends or public holidays. Nor does the general EU rule on time limits, Regulation (EEC, Euratom) No 1182/71, postpone time limits expressed in hours (Article 3(4)). The deadline calculator works out the deadlines for your time of awareness.

Does someone have to be woken at 4 a.m. on a Sunday?

Usually not. An e-mail that arrives at 04:00 on a Sunday can normally wait until the morning, provided someone reliably checks then. The reason is the worst-case calculation: even if an authority later moves the time of awareness back to the arrival of the e-mail, there is still enough time for the early warning.

In our reading, the words "without undue delay" in Article 14(2) do not require anyone to be woken at night either. A delay is undue only if it cannot be justified, and someone who sleeps at night and checks at the agreed time in the morning is not delaying unduly. This is an interpretation, not confirmed regulatory practice. The position is different if the e-mail itself already shows that an attack is under way, for example with logs or a report of an ongoing attack at a customer site. Then it is no longer only about the deadline but about harm to customers, and the call at 4 a.m. is worth making.

The real risk lies elsewhere. An e-mail that arrives at 23:00 on a Friday and is first read at 08:00 on Monday has been sitting there for 57 hours. That can no longer be explained as an immediate assessment. A simple rule works in practice:

• Fixed times at which someone checks at weekends and on public holidays, for example morning and evening, set down in writing.
• Wake people at night only if the e-mail itself contains strong indications: logs, traces of an attack, a customer with an ongoing incident, terms such as "exploited" or "in the wild".
• Record every check and every classification with the time. You can then show later that the gap between receipt and awareness was planned, not accidental.

Free templatesCRA Reporting KitThe awareness record as a form, and a case log with the four timestamps that calculates every deadline from awareness.Request the kit

Common mistakes

• Waiting for the full root-cause analysis. Awareness requires a reasonable degree of certainty, not completeness.
• Leaving the assessment untouched so as not to start the clock. The guidance requires "immediately"; the gap between receipt and awareness must be explainable.
• Not reading the mailbox at weekends because the deadline only starts with awareness anyway. Late awareness caused by poor organisation is likely to be moved back.
• Not recording the time of awareness. Without a timestamp, the 24-hour deadline can neither be proven nor defended later.

CRA Response Center helps with this classification: every report sent to your security address is classified, at night and at weekends too. Alerts go out only for important e-mails, for example when an e-mail looks like exploitation or an authority writes; everything else stays quietly under Everything else. The person responsible confirms the time of awareness in the tool with one click, and receipt, the moment someone took the case on and awareness are recorded with timestamps in the history; the assessment and the submission remain with the manufacturer.

Frequently asked questions

Further reading

• Actively exploited vulnerabilityWhat has to be reported and what does not: CVE, scanner finding, a researcher's exploit.
• The first 24 hoursA step-by-step plan from the incoming report to the early warning.
• ENISA Single Reporting Platform step by stepRegistration, roles and mandatory fields on the platform.
• ENISA FAQ of 3 October 2026: the portal's 72-hour counter shows 48 hoursThe portal counts the 72-hour deadline from the early warning. For vulnerabilities there is not yet a field for the time of awareness.

Sources

• Regulation (EU) 2024/2847, Article 3, point (42), Article 13(7), Articles 14, 15, 64 and 71, recital 68, Official Journal of the EU, 20 November 2024.
• Commission guidance C(2026) 5252, Annex, paragraphs 209 to 221, European Commission, 27 July 2026.
• FAQs on the Cyber Resilience Act, version 1.4, question 5.3, Commission services, 4 September 2026.
• Regulation (EEC, Euratom) No 1182/71 determining the rules applicable to periods, dates and time limits, Articles 1 and 3, Official Journal of the EC, 3 June 1971.
• Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, European Data Protection Board, 28 March 2023.
• CRA Single Reporting Platform: Frequently Asked Questions, ENISA, as of 3 October 2026.
• CRA SRP Glossary, version 1.4, ENISA, 1 October 2026.
• Commission CRA application guidance published, cyberresilienceact.eu, 27 July 2026.
• Cyber Resilience Act Reporting Playbook 2026, wavect, 24 August 2026.