What triggers the EU Cyber Resilience Act's 24-hour early-warning report?
answer
- the clock starts at awareness
- exploited, not merely severe
- evidence of code execution, not a proof of concept
- regulator first, not the public
- 24 hours, then 72, then 14 days
basics
~20 sBecoming aware that a vulnerability in your product is being actively exploited, or that a severe incident affects its security. Within 24 hours you send an early warning to the coordinating national CSIRT and ENISA - not a public advisory.
solid answer
~50 sThe clock starts when the manufacturer becomes aware that a vulnerability in one of its products is being actively exploited - the CRA means reliable evidence that an attacker executed code on a system without the owner's permission - or that a severe incident is affecting the product's security. Within 24 hours you send an early warning to the CSIRT designated as coordinator and to ENISA through a single reporting platform. It is deliberately thin: that this is happening, and which member states the product is available in if you know. A fuller vulnerability notification follows within 72 hours, with what you know about the flaw and any corrective or mitigating measures, and a final report within 14 days of a fix being available. You must also inform affected users without undue delay. Awareness starts the clock, not confirmation and not having a patch.
go deeper
Remember the trigger and the number: evidence that a flaw in your product is really being exploited starts a 24-hour clock, and the report goes to the authorities rather than to the public.
Explain the full staged sequence - 24-hour early warning, 72-hour notification, 14-day final report - who receives each, and why awareness rather than confirmation starts it.
Show what you would build to meet it: a monitored security contact, a named decider for what counts as exploitation, pre-registered reporting accounts, and a product-to-version inventory that answers which markets are affected at 01:00.
Own the tension between filing fast and filing accurately, the cost of a permanently staffed intake, and how you rehearse this across many product lines without the legal, engineering and support functions arguing about it during the incident.
## The obligation The CRA gives manufacturers a reporting duty with a staged clock, and the first stage is 24 hours. Two things trigger it: 1. **An actively exploited vulnerability in a product with digital elements you make.** The regulation defines actively exploited narrowly and usefully: there is reliable evidence that a malicious actor executed code on a system without the permission of its owner. A public proof of concept is not enough. A high severity score is not enough. Evidence of real exploitation is. 2. **A severe incident having an impact on the security of the product** - for example a compromise of your build or update infrastructure that could affect the products themselves. ## The stages For an actively exploited vulnerability: | When | What | To whom | | --- | --- | --- | | Within 24 hours of awareness | Early warning: that an exploited flaw exists, and the member states where the product is available if known | Coordinating CSIRT and ENISA | | Within 72 hours | Vulnerability notification: general information about the product, the nature of the flaw, and any corrective or mitigating measures taken and that users can take | Coordinating CSIRT and ENISA | | Within 14 days of a corrective measure being available | Final report: description of the vulnerability, its severity and impact, and the fix | Coordinating CSIRT and ENISA | For a severe incident the shape is the same but the tail is longer: early warning in 24 hours, an incident notification in 72 hours, and a final report within one month. Reports go through a single reporting platform, to the CSIRT designated as coordinator - normally in the member state of your main establishment - and to ENISA. There is a separate duty to inform the affected users of the product without undue delay, and where appropriate about the risk and any corrective measures they should take. ## What the clock does and does not mean **It starts at awareness.** Not at triage, not at reproduction, not at root cause, not at patch. The moment a credible report reaches someone who can be said to have made your organisation aware, you are inside 24 hours. That is a process design problem before it is a legal one: if your only path from a customer email to a person who can file is an unmonitored inbox, you have already lost the window. **It is not disclosure.** Notifying a regulator is not publishing an advisory, and it does not force you to burn an embargo or tell the world before a fix exists. The regulation is aware of this tension and lets the coordinating CSIRT delay dissemination on cybersecurity-risk grounds. Running the coordinated disclosure itself - the embargo, the advisory, the fix delivery - is a separate discipline with its own rules. **It is not conditional on a fix.** Manufacturers routinely assume the report is what you file when you have something to say. The early warning exists precisely because you do not yet. ## What this forces you to build Consider a consumer thermostat vendor that pushes firmware over the air. On a Friday night, a researcher's mail lands showing a device being taken over on a customer's network by someone standing next to it, and the heating held on. The on-call rota is one person. To survive that, the following must exist before the night in question: - **A monitored intake.** A published security contact that a human or a pager watches at weekends, not a shared inbox someone reads on Monday. - **An awareness definition and a decision rule.** Who is empowered to declare exploitation reliable, and the standing instruction that when unsure, you file - the early warning is cheap and late is not. - **Pre-registered plumbing.** Accounts on the reporting platform, the coordinating CSIRT identified, the report skeleton drafted, the list of member states each SKU is sold into ready. Nobody should be working out which CSIRT is theirs at 01:00. - **A product inventory keyed to versions.** You cannot say which products and which member states are affected without knowing which firmware builds contain the component, which is what the SBOM duty is for. - **A user-notification path.** A way to tell owners of installed devices something, including those whose devices are online but whose owners are not. ## Common wrong answers Saying the 24-hour report goes to customers, or to a data protection authority, or that it applies to every vulnerability you find rather than the exploited ones, or that the clock starts when you finish investigating. Each of those is a different obligation from a different regime, and mixing them up is exactly what an interviewer is testing for.
- Your on-call sees credible evidence of exploitation at 23:00 on a Friday. What happens in the first hour?Declare it and start the clock rather than investigating first. Wake the person who can file, pull the affected build and market list, and send the early warning with what you have - the early warning is allowed to be thin. In parallel, begin containment and decide what to tell owners of devices. Do not wait for root cause, a patch, or business hours; the 24 hours are already running.
- Does the 24-hour early warning force you to disclose the vulnerability publicly?No. It is a notification to the coordinating CSIRT and ENISA, not publication, and the regulation allows dissemination to be held back on cybersecurity-risk grounds. You still owe affected users information without undue delay, but the timing and content of a public advisory follow your coordinated disclosure process, which is a separate obligation from the reporting clock.
- A researcher sends a proof of concept but there is no sign of real attacks. Does the clock start?Not on the exploited-vulnerability trigger. The CRA's definition needs reliable evidence that an attacker executed code without the owner's permission, and a proof of concept is not that. You still owe the vulnerability-handling duties: remediate without delay and ship a free security update. Watch for it flipping - the moment credible exploitation evidence appears, the 24 hours start from then.
It works like a hospital's initial alert rather than the discharge summary: you are ringing the bell to say something is happening, not filing the full account of what happened.
saying these in an interview costs you the question
- Says the clock starts once the vulnerability is confirmed or fixed
- Thinks the 24-hour report is a public advisory
- Applies the clock to every vulnerability, not exploited ones
- Names the data protection authority as the recipient
- Treats a public proof of concept as active exploitation
- Assumes weekends and holidays pause the clock