It’s too late (almost). The first major operational deadline for the EU Cyber Resilience Act (CRA) arrives this Friday, on September 11th, 2026. That’s when mandatory reporting obligations under Article 14 take effect for manufacturers of products with digital elements sold in the EU. What does that mean?
The first step to avoiding significant financial penalties for CRA infractions is to understand the similarities and differences between an actively exploited vulnerability in the product and a severe cybersecurity incident. Both trigger initial mandatory notifications to the EU agency for cybersecurity (ENISA), and national Computer Security Incident Response Teams (CSIRTs) (Figure 1).
An actively exploited vulnerability is defined as a known weakness in the digital elements of a product that has been used by a malicious actor. The CRA requires root-cause analysis of the flaw or weakness. The manufacturer must deliver a final corrective action report within 14 days following the issuance of a fix or patch.
The CRA defines a severe cybersecurity incident as an event that affects or can affect product security, including negative impacts on data or product functionality. It’s not necessarily based on pre-identified software issues. Once resolved, a final report must be issued within one month.
Existing products may receive limited exemptions. For example, products entering the market before the 11 December 2027 deadline may be exempt from some CRA design and CE-marking requirements. However, makers of legacy products must still comply with the active vulnerability and incident reporting requirements beginning on 11 September 2026. And any exemption ends if a product is substantially modified.
Definition of “Awareness”
The definition of “awareness” is important since the schedule for reporting is driven by a manufacturer becoming reasonably certain that a vulnerability is being actively exploited, or that a severe incident has happened.
It’s not wise to postpone the initial assessment to delay the start of the clock. The CRA requires prompt action, particularly where vulnerability may pose a significant risk. Being alert and becoming aware is the responsibility of the manufacturer.
The impetus for beginning an initial assessment can originate from internal monitoring, a security researcher, or a user. It can be formally communicated through the coordinated vulnerability disclosure (CVD) channel, appear through a story in the media, an inquiry from a CSIRT, or other sources.
What’s a CVD?
A CVD policy is a mandatory written framework distinct from incident reporting. The CVD provides a secure and monitored single point of contact for external parties like researchers or users to report previously undisclosed security flaws.
The interface can’t be limited to automated tools. It must provide a public, human-reachable point of contact. The CVD must include internal procedures to log, validate, assess severity, and track incident reports and subsequent actions.
Manufacturers are required to work with the reporting party when creating patches or fixes before details become public. The CRA also requires that the CVD includes systems for retaining evidence and documentation of all communications and investigations related to security flaws and vulnerabilities.
Increasingly detailed reporting
Each of the three reporting stages defined in the CRA includes increasingly detailed information and can require data from different parts of the organization (Table 1).
- First, within 24 hours of becoming aware of a triggering event, an early warning must be issued to ENISA and relevant CSIRTs, including the affected product and basic facts related to the situation.
- Second, within 72 hours of awareness, a report is issued building on the early report. Typical content includes an update about the affected product, updated and expanded information about the nature of the exploit, and any corrective or mitigating measures already implemented.
- Third is issuance of the final report. For vulnerabilities, the final report must be issued within 14 days after the correction is available, and for severe incidents, it must be available no later than 1 month after issuance of the 72-hour awareness report.
Tying up loose ends
While the following are examples of steps that should already have been taken, it’s not too late to adjust.
- Always identify specific qualified individual(s) available 24/7 to evaluate security triggers.
- Eliminate unnecessary administrative or other activities that can delay the strict CRA reporting timelines.
- Third-party and open-source system components must be continuously tracked to enable rapid awareness of flaws as they are identified.
Summary
Beginning 11 September 2026, the CRA requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe security incidents to ENISA and national CSIRTs. The required CVD policy is a mandatory written framework distinct from incident reporting. The CVD provides a secure and monitored single point of contact for reporting previously undisclosed security flaws.
References
Are products built before 2027 grandfathered under the CRA?, CRA Experts
CRA Reporting Obligations Start September 2026: What EOL Dependencies Mean for Your Compliance, HeroDevs
CRA Vulnerability Reporting: What Every Manufacturer Must Do Before 11 September 2026, Cyber Cert Labs
Cyber Resilience Act Enters Phase 1 – Reporting Requirements for Manufacturers Begin in 2026, Onekey
EU Cyber Resilience Act Countdown: 11 September 2026 Incident/Vulnerability Reporting Deadline Less Than 100 Days Away, Crowell
European Commission Publishes New Guidance on the Cyber Resilience Act, Pearl Cohen
One Year Countdown to EU CRA Compliance – September 11, 2026, Changes Everything, Keysight
Your Guide to CRA CE Marking Requirements, Regulus
Related EEWorld Online content
What can be done to prepare for post quantum cryptography?
How are single photon sensors used in quantum computing?
What is the mathematical foundation of post quantum cryptography?
Securing devices for the IoT — minimize the attack surface
Quantum computing system architectures