Consider a Friday-afternoon report: a product-security analyst receives credible evidence that someone has exploited a vulnerability in a component shipped inside one of the company’s products.
The analyst doesn’t yet know which versions are affected. The incident team hasn’t established whether customer data was exposed. The product owner is in another time zone. Legal hasn’t seen the report. Nobody has confirmed which legal entity is the manufacturer responsible for the product in the European Union.
The reporting clock may already be running. But exploitation of that component elsewhere doesn’t, by itself, establish a reporting duty for this manufacturer.
Since September 11, 2026, manufacturers covered by the EU Cyber Resilience Act have had to report actively exploited vulnerabilities in their products and severe incidents affecting product security. The first warning is due without undue delay and no later than 24 hours after awareness. A fuller notification follows without undue delay and no later than 72 hours after that same awareness point. The final report comes later, after the manufacturer has had more time to investigate and respond.
That sequence matters. The law doesn’t wait for the incident team to finish the investigation before the company says something. It separates early warning from fuller assessment, so regulators receive notice while the facts are still developing.
For security leaders, the hard part isn’t writing the first report. It’s getting a fragmented organization to recognize that the clock has started.
TL;DR
The EU’s 24-hour warning requirement doesn’t wait for a completed investigation.
Compliance depends on a defined internal route from the person who first sees reliable evidence to the person authorized to report it.
Teams need a disciplined way to separate confirmed facts, current assessments and open questions.
The useful readiness test is whether the company can produce a defensible early warning on a Friday afternoon, not whether it has a finished policy.
The first report is due while the facts are moving
The Cyber Resilience Act covers hardware and software products made available on the EU market, including some components. Its main cybersecurity requirements don’t apply until December 11, 2027, but the reporting duties began on September 11, 2026.
The European Commission describes three stages. An early warning is due within 24 hours after awareness. The fuller notification is due within 72 hours of that same awareness point. For an actively exploited vulnerability, a final report is due within 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month after the manufacturer submits the 72-hour notification. In either case, a final report isn’t required if the relevant information has already been provided.
Each stage asks for a different level of detail. The early warning alerts regulators while the investigation is still developing. The 72-hour incident notification includes an initial assessment. The vulnerability notification asks for available details of the vulnerability and exploitation, including any corrective or mitigating measures. Final reports add the required impact and remediation details.
That’s a more honest model than pretending a company knows everything on day one. It’s also operationally unforgiving. An organization that treats reporting as the last step of an investigation will discover that the law treats it as one of the first.
The mistake to avoid is turning the 24-hour warning into a miniature final report. If every statement must survive the standard applied to a completed investigation, the team will spend the first day debating language while the deadline expires.
The opposite mistake is just as dangerous. Speed doesn’t excuse speculation. The early report needs a clean boundary between what the company knows, what it currently assesses and what it hasn’t established.
A company learns through a person
“The company became aware” sounds like a single event. It rarely is.
A customer tells support that a product behaved strangely. A researcher emails a security address. A threat-intelligence analyst connects an exploit to a library used in several products. A business unit receives the evidence, but the central incident team doesn’t see it until the next morning.
Which moment starts the clock?
Commission guidance says manufacturers should assess a suspicious event immediately. Awareness follows when that initial assessment gives them a reasonable degree of certainty that a vulnerability in their product is being actively exploited or that a severe incident has compromised the product’s security. The legal answer depends on the facts and should be worked through with counsel. The management problem is already visible: evidence can enter through many doors, while the duty belongs to the manufacturer as an organization.
Internal escalation has to begin before the reportability decision. Making that decision may require technical, product and legal coordination. That’s different from saying the statutory clock starts at the first signal.
The safer design is a low-friction escalation route for credible evidence of active exploitation or a potentially severe product-security incident. The first recipient doesn’t need authority to decide whether the CRA requires a report. That person needs to know where to send the evidence, what information to preserve and how to document the handoff.
Keep separate timestamps for receipt of evidence, the initial assessment and the point when the awareness threshold is met. Record who received what, when they received it and why it appeared credible enough to escalate. That doesn’t settle the legal question. It gives counsel and the response team a factual timeline instead of a reconstruction assembled two days later from chat messages and memory.
The portal exposes the handoff
The reporting mechanism itself reveals where organizations are likely to fail.
Manufacturers submit through ENISA’s Single Reporting Platform. They designate one primary Assigned Representative and can add up to 20 secondary representatives. Those people authenticate through EU Login and submit or update notifications for the organization. The primary representative needs a verified manufacturer association before inviting secondary representatives. Pending validation doesn’t itself prevent an initial notification.
That sounds administrative until the incident arrives. The platform launched without an API, so notifications must be submitted through its interface. Internal preparation can still be automated. Draft reports are stored in the individual representative’s account and aren’t visible to the organization’s other representatives. If the wrong national computer security incident response team is selected, the notification can be invalidated and must then be submitted again.
None of those details is the central policy question. Together, they show that the reporting path has human seams.
Someone must know which legal entity is the manufacturer. Someone must identify the correct national reporting destination. The default route is the CSIRT for the manufacturer’s main EU establishment; manufacturers without one follow fallback rules that can depend on an authorized representative, importer, distributor or user population. Someone must have a working account and multifactor authentication. Someone must collect the latest facts without overwriting the distinction between evidence and inference. Someone else must cover when the primary representative is unavailable.
This resembles the problem in You Can’t Patch a Supply Chain You Can’t Inventory. Product security depends on knowing which components sit inside which products. Regulatory reporting requires another map: which legal entity is the manufacturer, where product-security decisions are made and who can submit a report for that entity.
An escalation procedure that ends with “notify Legal” isn’t a reporting workflow. It’s a direction of travel.
Separate facts from assessments and unknowns
The first day’s work should produce a timely report that’s accurate about what’s known and explicit about what isn’t.
One simple discipline is to divide the working record into three parts:
Confirmed facts. What evidence has the company received or reproduced? Which product, component or version is implicated? What time did the company receive the evidence?
Current assessment. Why does the team believe the vulnerability is being actively exploited, or the incident may be severe? What scope and impact appear plausible based on the evidence available now?
Open questions. Which versions, customers, data or functions remain under investigation? What will the team do next, and when will the assessment be updated?
This structure protects speed without pretending uncertainty has disappeared. It also makes later corrections easier to explain. A changed assessment isn’t necessarily a contradiction if the first report was explicit about what remained unknown.
External notification still carries consequences. As I argued in One-Way Doors, disclosure can be an irreversible act made under pressure. Confidential regulatory notification isn’t the same as public disclosure. The response isn’t to wait for perfect knowledge. It’s to document how the decision was made and define who can authorize the submission.
Run the Friday-afternoon test
Policies written around calm working hours hide the weakness. Test the system when people and facts are scattered.
Choose one product sold in the EU. At 4:18 on a Friday afternoon, give a product-security analyst reliable evidence that attackers are exploiting a third-party component inside it. Don’t begin with the central incident commander. Begin where a real report might arrive.
Then watch the handoffs.
Can the first recipient identify the escalation route without searching a policy library? Can the company determine which products and versions contain the component? Can it identify the manufacturer and the correct national reporting destination? Can the assigned representative access the platform? Is there a backup? Can the team preserve the evidence and assessment timeline while counsel evaluates when the awareness threshold was met? Can it produce an early warning that distinguishes facts, assessments and unknowns?
Continue the exercise through the 72-hour notification. The question isn’t whether the company can solve the incident in three days. It’s whether the reporting record becomes more precise as the investigation advances.
The exercise should leave concrete repairs: a missing owner, an expired login, a product that isn’t mapped to a legal entity, an escalation address nobody monitors or a draft that only one person can see.
The reporting requirement is new, but the leadership problem isn’t. A deadline attached to organizational awareness forces the company to confront the delay between receiving evidence and authorizing action.
The 24-hour clock doesn’t require omniscience. It requires a company that can act before the investigation is complete.
Sources
Source note: The reporting stages, deadlines and portal mechanics in this article come from European Commission and ENISA guidance current as of September 21, 2026. Organizations should confirm scope and legal interpretation with counsel.
Analytical note: The argument that CRA readiness is an organizational handoff problem is my interpretation of those requirements and the platform’s operating model.