The 24-Hour Clock: Reporting an Actively Exploited Vulnerability
For an actively exploited vulnerability, the Cyber Resilience Act does not ask a manufacturer to wait for a finished investigation before speaking. This chapter follows the vulnerability track from the moment the manufacturer becomes aware through the 24-hour early warning, the 72-hour notification, and the final report after a corrective or mitigating measure is available. The practical goal is to understand what each stage must accomplish, what information can mature later, and which product-lifecycle capabilities make the clock survivable.
The clock begins at awareness
Article 14 applies when a manufacturer becomes aware of an actively exploited vulnerability contained in a product with digital elements. The legal trigger is not the date on which a researcher first discovered the weakness, the date on which a vendor finished reproducing it, or the date on which a patch was released. It is tied to the manufacturer’s awareness of a vulnerability for which there is reliable evidence that a malicious actor has exploited it without the system owner’s permission.
That rule creates an important operational boundary. A security team may receive several weak signals before anyone can say that the manufacturer is aware of a qualifying event: a scanner finding, an unverified report, unusual telemetry, a supplier warning, or a customer complaint. Those signals can deserve urgent investigation. They do not all have the same legal meaning. Once reliable evidence reaches the manufacturer and the event meets the active-exploitation definition, however, the organization cannot postpone the reporting analysis until its investigation is complete.
The exact internal meaning of “becomes aware” can depend on facts that the Regulation does not spell out in one universal formula. Which legal entity received the information? Was it reliable enough to establish exploitation? Did the information concern the product as marketed, or only an unrelated environment? A manufacturer should record the source, time, product identity, initial evidence, and escalation decision. That record does not decide every legal question, but it prevents the organization from silently moving the start of the clock as more teams learn about the same event.
The first outer limit is 24 hours, but Article 14 uses two expressions together: the manufacturer must notify “without undue delay” and, in any event, within 24 hours of becoming aware. The 24-hour mark is therefore not a safe waiting period. It is the longest stated limit for the early warning under ordinary application of the rule. If the manufacturer can submit earlier, the duty points toward submitting earlier.
The early warning must indicate, where applicable, the Member States in which the manufacturer knows that the product with digital elements has been made available. That detail may appear administrative, but it determines who can act on the information. A product that has reached several national markets creates a broader coordination need than a product known to be available in only one. The manufacturer does not need to invent certainty about markets it cannot yet identify; it does need to pass on the applicable information it knows.
Two notices with different jobs
The early warning is designed to move a credible signal quickly. It is not the place to pretend that the root cause, severity, affected population, and fix are already settled. Its value is that it tells the competent coordination chain that a product contains an actively exploited vulnerability and supplies the known market-availability information needed for the next response.
Within 72 hours of awareness, the manufacturer must submit a fuller vulnerability notification, again without undue delay and in any event within that outer limit. The Regulation allows the manufacturer not to repeat information that has already been provided, but it does not turn the second stage into an optional update. Unless the relevant information is already in the earlier submission, the vulnerability notification must provide available general information about the product, the general nature of the exploit and vulnerability, corrective or mitigating measures already taken, and measures users can take. It must also indicate, where applicable, how sensitive the manufacturer considers the information to be.
The progression is from existence to usability. The first notice says, in effect, that a qualifying vulnerability is active and identifies the known market footprint. The second gives authorities and affected parties a working picture of the product and the threat: what kind of exploit is involved, what the weakness appears to be, what has already been done, and what users can do while the response develops. The word “available” matters. A manufacturer must provide the information it has, not manufacture a level of certainty that the investigation has not reached.
This staged structure also limits a common failure mode: treating the first notice as either a complete forensic report or an empty alarm. An empty message may not support coordinated action. An overconfident message may turn assumptions into official facts. A useful early warning is concise but specific about the product and event; a useful 72-hour notification adds the best available technical and mitigation picture while marking sensitivity and uncertainty honestly.
The duties are simultaneous in destination even though the information matures in stages. Article 14 requires notification to the designated coordinator CSIRT and ENISA through the Single Reporting Platform. The platform’s routing architecture is examined later, but the vulnerability team should understand the consequence now: this is not merely an internal incident ticket, and it is not a sequence of separate voluntary messages to whichever authority happens to answer first.
Users form a parallel responsibility. After becoming aware of an actively exploited vulnerability, the manufacturer must inform impacted users, and where appropriate all users, about the vulnerability and about risk-mitigation or corrective measures they can deploy. Where appropriate, that information should be structured and machine-readable so that it can be processed automatically. The authority notification and the user communication serve different audiences, but they are driven by the same awareness event.
Consider a software component inside a network-connected product. At 09:00 on a Monday, the manufacturer receives a credible report showing that an unauthorized actor used the component weakness against a deployed product. The team can reproduce the attack path, but it does not yet know the complete number of affected installations or the final patch design. The organization should preserve 09:00 as the awareness point. It can send the early warning with the known product and Member-State availability, then use the next period to assemble the general product, exploit, mitigation, sensitivity, and user-action information needed for the 72-hour notification. The incomplete patch is a reason for staged reporting, not a reason to let the first deadline pass.
The final report follows the measure
The vulnerability track has a different endpoint from the incident track because its final report is linked to remediation. The manufacturer must submit the final report no later than 14 days after a corrective or mitigating measure is available, unless the relevant information has already been provided. The timing is not fourteen days after the initial discovery, and it is not automatically fourteen days after the 72-hour notification. The event creates the first clock; the availability of a measure creates the final-report milestone.
The final report must include at least a description of the vulnerability, including its severity and impact; available information about any malicious actor that has exploited or is exploiting it; and details about the security update or other corrective measures made available to remedy it. This is a change in information maturity. By this point, the report should connect the weakness to its consequences and to the measure users or authorities can evaluate and apply.
A “measure” need not be described as a perfect final state in every circumstance. Article 14 refers to a corrective or mitigating measure. That wording recognizes that risk may be reduced by more than one kind of action while a permanent change is being developed. The organization still has to say what was made available and how it addresses the vulnerability. It should not confuse an internal plan to create a fix with a measure that is actually available to users or otherwise ready to mitigate the risk.
The final report also intersects with public vulnerability information. The CRA’s vulnerability-handling requirements call for information about fixed vulnerabilities to be shared and publicly disclosed once a security update is available, while allowing a justified delay when the security risks of publication outweigh the security benefits and users have first had a chance to apply the patch. This does not erase the Article 14 reporting duty. It shows that notifying the competent chain, informing users, and making public technical information are related decisions with different audiences and safeguards.
The initially receiving CSIRT may request an intermediate report when necessary. An intermediate report is not a replacement for the required stages; it is a way for the coordinator to obtain relevant status updates while the vulnerability or remediation changes. In practical terms, the manufacturer needs a status record that can be updated without losing the original awareness time, the facts already submitted, the new evidence, and the decisions about user and public communication.
The lifecycle obligations explain whether that record can be assembled quickly. The manufacturer must document and update its cybersecurity risk assessment during the support period, exercise due diligence when integrating third-party components, document relevant vulnerabilities and information supplied by others, and maintain policies and procedures for processing and remediating potential vulnerabilities from internal or external sources. The Regulation specifically includes coordinated vulnerability disclosure policies. It also requires a contact point through which vulnerabilities can be reported and received.
Those requirements are not a demand for a particular ticketing system or staffing chart. They identify the kinds of capability the reporting clock presupposes. Someone must be able to recognize the product and its components. Someone must own the legal manufacturer relationship. Someone must distinguish a report that is credible from one that is merely speculative, preserve the awareness timestamp, map known product availability, prepare user guidance, and track the availability of a corrective or mitigating measure. If those facts live in disconnected supplier, security, support, and legal records, the 24-hour duty exposes the gap.
The support period matters because the vulnerability does not disappear when the final report is sent. Manufacturers must handle vulnerabilities effectively during the period in which the product is expected to be in use. The support period is generally at least five years, unless the product is expected to be used for less time, and the manufacturer must disclose the basis for determining it. Security updates made available during that period must remain available for at least ten years after issuance or for the remainder of the support period, whichever is longer. The rule has qualifiers, including a tailored business-user context, but its direction is clear: a reporting event belongs to a continuing product relationship.
The same is true of the update itself. The CRA requires security updates to be disseminated without delay and, unless otherwise agreed for a tailor-made product with a business user, free of charge. Where technically feasible, new security updates should be provided separately from functionality updates. Separating those purposes helps users receive a security correction without being forced to adopt unrelated new functionality solely to obtain protection. It also gives the final report a concrete object: a measure that users can identify, obtain, and apply.
The sequence does not mean that ENISA or a CSIRT waits until the final report to see the event, nor that users receive every internal technical detail. It shows the relationship among the milestones: authority notification begins quickly, user protection runs alongside it, and the final vulnerability report is anchored to a measure that can change the risk.
What the clock demands
A manufacturer can meet the vulnerability track only if it treats time and information as linked but different problems. Time determines when the organization must communicate. Information maturity determines what each communication can responsibly contain. The 24-hour early warning should be fast and grounded; the 72-hour notification should be more useful without overstating certainty; the final report should connect severity, impact, available attacker information, and the measure that addresses the vulnerability.
That model gives uncertainty a proper place. Uncertainty about the full scope of exploitation does not automatically defeat the duty when reliable evidence of active exploitation exists. Nor does a preliminary report authorize the manufacturer to turn a hypothesis into a fact. The disciplined response is to state what is known, what is suspected, what users can do, and when the next material update will follow.
The legal manufacturer also has to preserve the difference between a component problem and a product duty. A third-party maintainer may help create the fix, but the manufacturer whose product contains the component must still assess and report the qualifying vulnerability in its product. The company’s product inventory, component relationships, user contacts, and corrective-action records are therefore part of the reporting mechanism, not background administration.
The 24-hour clock is best understood as the first visible test of that mechanism. It asks whether product security can move from evidence to ownership, from ownership to notification, and from notification to user protection without waiting for a perfect ending. The next judgment is more difficult: when the event is defined by serious operational impact rather than by active exploitation of a known weakness, the CRA uses a related but distinct reporting track.