Beginning Sept. 11, 2026, manufacturers covered by the EU Cyber Resilience Act (CRA) must report actively exploited vulnerabilities and severe security incidents affecting products with digital elements. The first deadline arrives within 24 hours of awareness.
That short window changes the operational question. It is no longer enough to know how a vulnerability will be investigated and fixed. Manufacturers need to know who can recognize a potentially reportable event, who decides whether the threshold has been met, and how an early warning will reach the proper authority before the clock expires.
What changes on Sept. 11, 2026?
The European Commission says the reporting duties apply to manufacturers of covered hardware and software products with digital elements. They take effect more than a year before most other CRA obligations, which generally apply from Dec. 11, 2027.
Reports will be submitted once through the CRA Single Reporting Platform. The platform routes the notification to the relevant national Computer Security Incident Response Team (CSIRT) and makes it available to the EU Agency for Cybersecurity (ENISA), except where limited exceptional circumstances justify delayed dissemination.
The duties cover two event types:
- Actively exploited vulnerabilities: weaknesses in a covered product for which reliable evidence indicates that a malicious actor has exploited the vulnerability without permission.
- Severe incidents: incidents that affect, or can affect, a product’s ability to protect the availability, authenticity, integrity, or confidentiality of important or sensitive data or functions. This can include malicious code introduced through a compromised development, production, or maintenance environment.
Organizations should confirm scope with qualified legal counsel. Product classification, the organization’s role in the supply chain, and the facts surrounding an event can change the analysis.
How the CRA’s reporting clock works
The clock begins when the manufacturer becomes aware of an actively exploited vulnerability or severe incident. European Commission guidance describes awareness as reaching a reasonable degree of certainty after an initial assessment—not waiting until every technical fact is known.
- Within 24 hours: Submit an early warning with preliminary information and indicate whether malicious or unlawful activity is suspected.
- Within 72 hours: Submit a fuller notification with the available assessment of the event, its severity and impact, and mitigation or corrective measures.
- Final report: For an actively exploited vulnerability, submit the report no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month of the 72-hour notification.
Manufacturers must also inform impacted users—and, where appropriate, all users—in a timely manner. Those communications should explain corrective or risk-mitigation measures users can take.
Six steps manufacturers should take now
The 24-hour requirement leaves little time to build a process after an event begins. Preparation should connect product security, incident response, legal, engineering, customer communications, and executive decision-makers.
- Map products and ownership: Identify covered products available in the EU, including existing and legacy products, their support status, responsible teams, and relevant CSIRT.
- Define the awareness threshold: Document the evidence required for an initial assessment and who is authorized to make a reportability decision.
- Create a 24-hour escalation path: Establish around-the-clock contacts, alternates, and decision deadlines, so a report does not wait for ordinary business hours.
- Prepare notification templates: Predefine the data needed for the 24-hour warning, 72-hour notification, final report, and user communications.
- Improve component and supplier visibility: Maintain current product inventories and software component records, and require suppliers and researchers to escalate relevant findings quickly.
- Test the workflow: Run tabletop exercises that begin with incomplete information and test whether technical, legal, product, and communications teams can meet each deadline.
Prevention and containment support reporting readiness
CRA reporting is a governance and product-security obligation, but preventive controls can make the response more manageable. Deny-by-default policies reduce the number of unauthorized applications and scripts that can execute. Application containment can restrict how approved software interacts with files, child processes, the registry, and network destinations. Removing standing administrative rights limits the privileges an attacker can use after exploitation.
These controls do not replace vulnerability management, product testing, legal analysis, or CRA reporting, but they can help reduce attack paths, contain malicious activity, and preserve clearer evidence for an investigation while teams determine scope and impact.
How ThreatLocker can help
ThreatLocker helps organizations enforce Zero Trust controls across endpoints, applications, privileges, and network access.
Application Allowlisting blocks unapproved software by default. Ringfencing™ limits what trusted applications can access and which processes or network destinations they can reach. Privileged Access Management removes unnecessary standing administrator rights, while Unified Audit provides a centralized record of policy and activity data.
Used as part of a broader product-security and incident-response program, these controls can help organizations prevent common attack actions, contain exploitation, and investigate events with greater clarity.
CRA compliance still depends on each manufacturer’s products, roles, processes, and legal obligations.
The 24-hour deadline rewards preparation
The first CRA deadline is fundamentally an execution test.
Manufacturers need enough visibility to recognize a potentially reportable event, enough context to assess it quickly, and an escalation path that works under pressure.
Organizations that define those responsibilities before Sept. 11 will be better positioned to make timely, defensible decisions when the clock starts.
FAQs
When do CRA vulnerability reporting obligations begin?
They begin Sept. 11, 2026. Most other CRA obligations generally apply from Dec. 11, 2027.
Does every vulnerability have to be reported within 24 hours?
No. The CRA reporting duty concerns actively exploited vulnerabilities and severe incidents affecting the security of covered products. Organizations should establish a rapid assessment process and seek legal advice for their specific circumstances.
Where are CRA reports submitted?
Manufacturers submit one report through ENISA’s Single Reporting Platform, which routes it to the relevant CSIRT and ENISA.
