Last Updated on August 12, 2026
Show reporting obligations associated with the Cyber Resilience Act (CRA)
Objectives
Mandatory cybersecurity requirements for products with digital elements offered in the EU market are established by the Cyber Resilience Act (CRA). There are also specific reporting obligations associated with the Cyber Resilience Act (CRA) that manufacturers and providers must be aware of. While the full law takes effect on 11 December 2027, Article 14 introduces early, aggressive timeline rules for reporting vulnerabilities and incidents starting from 11 September 2026. Its main aims include the following:
- Force rapid ecosystem awareness of active exploits.
- To create a unified reporting pipeline via ENISA (European Union Agency for Cybersecurity) and national Computer Security Incident Response Teams (CSIRTs).
- To shield consumers and businesses from unmitigated severe incidents.
- To penalize non-compliance with heavy fines up to €15M or 2.5% of global annual turnover (whichever is higher) for severe breaches of essential cybersecurity requirements.
Important Dates & Staged Deadlines
11 September 2026
The Article 14 reporting obligations enter into force.
This is the first major milestone of the Cyber Resilience Act. From the 11th of September 2026 forward, manufacturers must report actively exploited vulnerabilities and severe security incidents. This applies to new products as well as products already placed on the market. Please note that there is an obligation to report, but no statutory deadline for a final fix.
Within 24 Hours of Awareness
Phase 1: Early Warning
The countdown starts the exact moment you verify the vulnerability—meaning an initial prompt assessment yields a reasonable degree of certainty that an exploit or incident is real. Within 24 calendar hours, you must submit an early warning to your coordinating CSIRT and ENISA.
- Vulnerabilities:
- Must indicate the EU member states where the product is available.
- Incidents:
- Must indicate whether the event is suspected to be caused by unlawful or malicious acts.
Within 72 Hours of Awareness
Phase 2: The Detailed Notification
The clock continues to run through weekends and holidays. By hour 72, you must follow up with a deeper technical dive.
- Vulnerabilities: Provide general product info, the nature of the exploit, and initial user workarounds.
- Incidents: Provide the nature of the incident, occurrence/detection timestamps, initial impact assessments, and remediation steps.
Within 14 Days of Mitigation (Vulnerabilities)
Phase 3A: The Final Vulnerability Report
The clock for the final vulnerability report does not run from initial awareness. Instead, it triggers the moment a patch, security update, or corrective measure becomes available. You have 14 days from that completion date to submit a final report detailing vulnerability severity, e.g., Common Vulnerability Scoring System (CVSS), impact analysis, and threat actor data.
Within 1 Month of Notification (Incidents)
Phase 3B: The Final Incident Report
Unlike vulnerabilities, severe incidents operate on a strict, predictable window. Exactly one month after your detailed notification (72-hour time window), you must submit a conclusive post-incident review mapping out the root cause, long-term remediation, and systemic impact.
11 December 2027
Every provision of the Cyber Resilience Act comes into effect.
Full compliance—including mandatory Software Bill of Materials (SBOM) management, public single points of contact, and vulnerability handling workflows—becomes legally binding. Products cannot be sold on EU markets if they do not comply.
What is NOT Reportable Under Article 14
Many developers significantly overestimate what needs to go to the authorities. The following does not trigger the Article 14 countdown:
- Vulnerability Scanner Findings:
- Raw Common Vulnerabilities and Exposures (CVE) flags from a dependency scanner do not count unless active exploitation is proven.
- External Security Researcher Tips:
- Coordinated disclosures remain internal matters until active exploitation or a CI/CD pipeline compromise is verified. A CI/CD pipeline compromise occurs when an unauthorized entity breaches a software build, test, or deployment workflow.
- Internal Pentest/Audit Results:
- Discovered bugs do not require reporting if they haven’t been exploited in the wild.
- Minor Incidents:
- Non-security events, such as a plain corporate website availability outage, are out of scope.
5-Step Preparation Checklist
To ensure your development team is ready before the September deadline hits, you must establish an operational framework:
- Assign Ownership:
- Name a reporting owner, a deputy, and map your designated national CSIRT.
- Compile Product Data:
- Keep active version histories, lists of EU countries where you sell, and clean customer contacts ready.
- Build Staged Templates:
- Pre-format templates for the 24-hour, 72-hour, final, and user notifications.
- Organize Rapid Triage:
- Create a single intake point for bugs so initial assessments start without delay.
- Conduct a Simulation Exercise:
- Execute a simulated tabletop exploit exercise to locate workflow bottlenecks.
- Execute a simulated tabletop exploit exercise to locate workflow bottlenecks.
Conclusion
Want to get your development workflow ready for the Cyber Resilience Act? If you build embedded systems and need to track these strict SLA windows without dedicated security compliance officers, automated tooling, e.g., provided by the Yocto Project®, can bridge the gap. Automated triage paths protect your engineering team by decoupling initial tip intake timestamps from your official legal “awareness” countdown clock.
Stay tuned for our upcoming “CRA compliance with the Yocto Project®” training.
Related Links
Appendix
If you are keen to learn how embedded Linux works plus some Linux with additional real-time, click here. To learn more about the Yocto Project®, take a look here.
