EU Cyber Resilience Act Starts 24-Hour Clock

EU Cyber Resilience Act reporting obligations are now in effect, creating a time-bound operational duty for technology manufacturers.

Everyone else is listing three deadlines; we are explaining which operational clock starts when a product team becomes aware and why this is not yet full CRA compliance.

EU Cyber Resilience Act reporting is now live

The EU Cyber Resilience Act reached its first broad operational deadline on 11 September 2026. Manufacturers of products with digital elements made available in the European Union must now report actively exploited vulnerabilities and severe security incidents through the Single Reporting Platform operated by the European Union Agency for Cybersecurity, or ENISA. The first filing is an early warning due within 24 hours after the manufacturer becomes aware of the event; a fuller notification follows within 72 hours. This is a legally meaningful start date, but it is not the date when every product-design, support and conformity duty in the regulation becomes applicable. Most of those wider requirements begin on 11 December 2027. The immediate task is therefore to build a reliable reporting decision process, not to claim that the entire EU Cyber Resilience Act compliance programme appeared overnight.

The three clocks are different

The European Commission describes a sequence rather than one deadline. An early warning is due within 24 hours of awareness, and a main notification within 72 hours. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident affecting product security, the final report is due within one month after the 72-hour notification. Those endpoints answer different questions. The early warning alerts authorities quickly; the main filing adds available scope, severity and mitigation information; the final report explains the event and response with more complete evidence. A manufacturer should not wait for a finished patch or a fully attributed attacker before deciding whether the initial clock has started. It needs a documented triage route that can make a preliminary legal and technical judgment under time pressure.

Which products and companies are in scope

The reporting duty applies to manufacturers of products with digital elements placed on the EU market. That broad category can include connected hardware, embedded software, apps and other software products, including products already available before the wider 2027 obligations apply. The exact role matters: manufacturer, importer, distributor and open-source software steward are not interchangeable labels, and a company outside the EU can still face obligations when it sells a covered product into the bloc. ENISA’s FAQ also points companies to their main establishment for routing decisions, generally the location where product-cybersecurity decisions are predominantly taken. Businesses should map legal entities to products and markets rather than assign “CRA compliance” to a global security team without ownership. When an alert arrives, the organisation needs to know which entity is the manufacturer and which national authority should receive the notification.

Actively exploited is narrower than merely vulnerable

The EU Cyber Resilience Act does not require a filing for every weakness in every product. One trigger is an actively exploited vulnerability: a flaw for which there is reliable evidence that a malicious actor has exploited it. A public proof of concept, a scanner hit or a vulnerability report may be an important signal without automatically proving malicious exploitation. The second trigger is a severe incident affecting the security of a product with digital elements. Teams therefore need separate decision paths for vulnerability intelligence and incident response, plus a way to combine evidence when an event has both characteristics. Our report on the Chrome 153 zero-day response shows why the distinction matters: an exploited browser flaw creates a different urgency from a dormant defect. A legal filing decision should still be recorded even when the team concludes that the available evidence does not meet a CRA trigger.

Awareness becomes an operating-model problem

The regulation measures deadlines from awareness, which turns organisational design into compliance infrastructure. A researcher may email support, a reseller may notify an account manager, a cloud system may raise an alert or an open-source maintainer may see exploitation discussed publicly. If those channels are not connected, the company can lose hours before the right product-security owner sees the evidence. Manufacturers need a central intake route, clear severity and exploitation criteria, an on-call decision group and timestamps that show when credible information reached the organisation. They also need alternates for weekends and holidays because the law’s clock does not follow office hours. The core mechanism is traceability: preserve the original signal, the evidence reviewed, the people who made the determination and the time each escalation occurred.

The Single Reporting Platform is the submission path

ENISA built and operates the Single Reporting Platform for these notifications. The platform is designed to route information to relevant national computer-security incident response teams and competent authorities. A working account is only one part of readiness. Companies should pre-authorise submitters, store the legal-entity and product information likely to be required, test access controls and define how sensitive vulnerability details move from engineering systems into the filing. A rushed copy-and-paste process can introduce its own security risk or disclose more than the initial stage requires. The F5 workforce AI security launch provides a useful adjacent lesson: security tools and identities are valuable only when they fit an accountable workflow. The CRA process needs the same discipline, with product, legal, incident-response and executive roles agreed before the first mandatory report.

What is not required yet

The September 2026 milestone is specifically the Article 14 reporting obligation. The European Commission says the main EU Cyber Resilience Act requirements apply from 11 December 2027. Manufacturers should not infer that security-by-design, conformity assessment, technical documentation, CE-marking and lifecycle-support work can wait until the last minute; those programmes need long lead times. But news reports should not present every future duty as already enforceable today. ENISA’s FAQ also says a manufacturer does not have to report retrospectively an actively exploited vulnerability it already knew was being exploited before 11 September 2026. That boundary does not erase other incident, privacy, consumer or contractual duties. It simply keeps the new CRA reporting clock tied to the regulation’s application date and the facts of awareness.

A 24-hour readiness checklist

A practical readiness test has six parts. Maintain one monitored channel for vulnerability and incident reports. Link each covered product to its manufacturer, main establishment, security owner and legal owner. Define evidence thresholds for active exploitation and severe incidents without demanding impossible certainty at the early-warning stage. Pre-authorise people who can submit through the ENISA platform at any hour. Prepare a fact template covering product versions, discovery time, impact, geography and mitigation status. Finally, run a short exercise that starts with an ambiguous external report and ends with a timed filing decision. The RBI quantum-proof payments call covers a different technology transition, but the lesson transfers: resilience comes from staged ownership and rehearsed escalation, not from a policy document that nobody can execute during an incident.

The bottom line for global manufacturers

The EU Cyber Resilience Act now puts a 24-hour legal clock around two specific product-security events: awareness of an actively exploited vulnerability and awareness of a severe incident. The 72-hour notification and later final report deepen the evidence as it develops. For global manufacturers, the real implementation challenge is detecting the signal across support, engineering, supplier and threat-intelligence channels, then identifying the responsible legal entity and making a defensible decision quickly. The rule does not mean every bug is reportable and does not make all CRA duties applicable before December 2027. It does mean that unclear ownership, unmonitored intake and weekend-only escalation are now measurable compliance risks. Product mapping, timestamped triage, authorised platform access and a tested response playbook are the controls to focus on first.

EU Cyber Resilience Act facts table

EU Cyber Resilience Act FAQs

When did EU Cyber Resilience Act reporting begin?

The Article 14 reporting obligations began applying on 11 September 2026.

What must be reported within 24 hours?

Manufacturers must submit an early warning after becoming aware of an actively exploited vulnerability or a severe incident affecting a covered product’s security.

Where are CRA reports submitted?

Manufacturers use ENISA’s Single Reporting Platform, which routes information to the relevant national authorities.

Are all CRA product requirements already in force?

No. The main product-security and conformity obligations generally apply from 11 December 2027; the September 2026 milestone is the reporting duty.

Sources

• European Commission — Cyber Resilience Act reporting obligations
• ENISA — Single Reporting Platform
• European Commission — Safer and more secure digital products
• ITPro — Three things businesses need to know as CRA rules take effect
• The Register — EU CRA starts the 24-hour vulnerability clock
• OpenSSF Global Cyber Policy Working Group — CRA reporting checklist for manufacturers