CRA Reporting Duty Starts September 11: How to Get Ready
The CRA reporting obligation arrives well ahead of the headline deadline: while most duties of the Cyber Resilience Act apply from 11 December 2027, Article 14 goes live on 11 September 2026. From that day, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents within 24 hours. It sounds like paperwork and is really a process problem: teams that have never rehearsed the chain from first knowledge to submitted report will not make the deadline. This piece sorts out who is covered and what should be in place by the cut-off.
What must be reported from September 11
Two classes of events trigger the duty. First, vulnerabilities in your own product that are demonstrably being exploited in the wild. Second, severe incidents that affect the security of the product. Both follow the same cascade: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report, due at the latest 14 days after a fix is available for vulnerabilities, or one month after the notification for incidents.
Reports go to the coordinating national CSIRT, in Germany hosted at the BSI, and to ENISA, technically through a shared central reporting platform. The early warning may be rough, it only signals that something happened. Substance is owed with the 72-hour notification. The full set of requirements sits in Article 14 of the regulation.
Who is covered
The CRA addresses manufacturers of products with digital elements made available on the EU market, regardless of where the company is based. Alongside device makers that explicitly includes software vendors: anyone marketing a product, an app, a licensed portal, a device with firmware, is in scope. Pure contract development without a product of your own does not trigger the duty, and neither does non-commercial open source software.
The deadline deserves attention even from companies that believe they sit just outside the scope. In grown portfolios the line between service and product is often blurry, and the fines carry weight: violations of the reporting obligations can cost up to 15 million euros or 2.5 percent of worldwide annual turnover.
24 hours is a process, not a form
The real work happens before any platform registration. A reporting chain has three links: someone learns of the exploitation, someone assesses and decides, someone reports. Every link needs a name and a deputy, because awareness does not keep office hours. A support ticket on Friday evening, a researcher’s email on Saturday: the clock starts at knowledge, not on Monday.
Part of this is an orderly intake for vulnerability reports. A coordinated disclosure policy and a security.txt under /.well-known/ on your domain cost an afternoon and make sure reports arrive where the chain begins:
Contact: mailto:security@example-vendor.com
Policy: https://example-vendor.com/security/cvd-policy
Preferred-Languages: en, de
Expires: 2027-08-31T22:00:00.000ZA prepared notification template that pre-structures the mandatory fields of the early warning helps too. Nobody wants to work out the platform’s form for the first time in the middle of a real incident.
Clarify exposure in minutes, not days
The 24-hour deadline is often decided by a mundane question: is the affected component in our product at all, and in which version? Teams that answer this through code archaeology lose the day. A maintained SBOM per release answers it in minutes and is part of CRA preparation anyway, as described in our piece on the CRA SBOM requirements. Which tools generate, manage and make SBOMs readable is covered in our SBOM tools overview.
Companies that already built NIS-2 processes start ahead: the pattern of early warning plus follow-up notification is the same, and the roles can be reused. Only the subject differs. NIS-2 reports incidents hitting your organization, the CRA reports vulnerabilities and incidents of your product. The practical NIS-2 side is covered in our article on implementing NIS-2 technically.
Conclusion
September 11 is not a documentation deadline, it is a rehearsal deadline. A reporting chain with named roles, a clean vulnerability intake, an SBOM per release and one dry run against the clock: with these in place the duty is manageable without spinning up a compliance project. If you want these building blocks wired into your product and pipeline, we help hands-on, from the reporting process to SBOM automation: software engineering consulting at EverBright.
Frequently Asked Questions
When does the CRA reporting obligation start?
Article 14 of the Cyber Resilience Act applies from 11 September 2026. From that day manufacturers must report actively exploited vulnerabilities and severe incidents with security impact. The remaining CRA duties, such as security requirements and technical documentation, follow on 11 December 2027.
What deadlines does a CRA report have to meet?
Three stages: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report. The final report is due at the latest 14 days after a fix is available for vulnerabilities, or one month after the notification for severe incidents.
Who has to report under the Cyber Resilience Act?
Manufacturers of products with digital elements offered on the EU market, regardless of where the company is established. That includes software vendors with their own products. Pure contract development and non-commercial open source software do not trigger the reporting obligation.
Where do CRA reports go?
To the coordinating national CSIRT, in Germany the BSI, and in parallel to ENISA. Both run through a shared central reporting platform. The early warning may be brief, while the full 72-hour notification must contain assessment, impact and countermeasures.
How does an SBOM help with the reporting duty?
It answers the first question of every report: is our product affected, in which version, since when? A maintained bill of materials per release cuts that clarification from days to minutes and provides the component details the 72-hour notification requires anyway.
