Key Takeaways<\/p>\n
- \n
- The Cyber Resilience Act entered into force on 11 December 2024. Mandatory reporting for actively exploited vulnerabilities and severe incidents applies from 11 September 2026 (EU Digital Strategy, 2026).<\/li>\n
- Full CRA applicability \u2013 including all technical requirements for products with digital elements \u2013 begins on 11 December 2027.<\/li>\n
- The reporting chain has three stages: early warning within 24 hours, full disclosure within 72 hours, and a final report within 14 days of the availability of corrective measures.<\/li>\n
- Reports are filed via the CRA Single Reporting Platform to the competent CSIRT in the country of headquarters; ENISA receives the information in parallel without additional filing.<\/li>\n
- SBOMs are no longer optional \u2013 they\u2019re a mandatory component of vulnerability handling. Without component transparency, a report cannot be properly substantiated.<\/li>\n<\/ul>\n<\/div>\n
What the CRA reporting obligations actually require from September 2026<\/h2>\n
The Cyber Resilience Act is the EU\u2019s first cross-border product-cybersecurity regulation. It targets manufacturers, importers, and distributors of products with digital elements \u2013 essentially anything that contains software or is networked. This covers classic software vendors as well as hardware makers with embedded systems, vendors of connected household appliances, industrial sensors, IoT gateways, and products that receive firmware updates. Full applicability is set for 11 December 2027, but a core block of obligations kicks in earlier: from 11 September 2026, manufacturers must report actively exploited vulnerabilities and serious security incidents.<\/p>\n
This reporting duty is operationally the most critical part of the CRA. It pulls IT-security teams directly into regulatory workflows and creates a hard interface between vulnerability handling and government communication. Products placed on the market after the deadline fall squarely under the reporting obligation. Existing products enjoy transition rules, yet once an update is rolled out, the manufacturer must still be able to run the CRA reporting chain.<\/p>\n
The BSI, in its CRA advisory initiative, has stressed that these are operational reporting duties, not formal compliance paperwork. The deadlines are strict. The recipients are clearly defined. The content demanded is technically and substantively demanding. A marketing-driven boilerplate report won\u2019t cut it \u2013 precise details on affected products, exploits, mitigation status, and patch availability are required.<\/p>\n
\nDefinition<\/p>\n
Actively exploited vulnerability<\/strong> under the CRA is a vulnerability for which documented evidence of actual exploitation exists \u2013 whether via threat intelligence, an incident in your own customer base, or a verified external report. A mere proof-of-concept does not suffice; the decisive factor is evidence that the flaw has been weaponized against a live system.<\/p>\n<\/div>\n
The 24-72-14 Clock: Reporting Chains in Detail<\/h2>\n
The three CRA deadlines for actively exploited vulnerabilities build on each other and force security teams into a strictly timed escalation routine. The clock starts ticking as soon as the vendor becomes aware of the active exploitation. From that moment, 24 hours remain for an Early Warning containing the vulnerability\u2019s basic information, the affected product, and the current state of knowledge. The Early Warning is not a full report but an advance alert to the authorities.<\/p>\n
Within 72 hours of the same awareness, the Full Report must follow. It includes details on the vulnerability\u2019s nature, affected product versions, initial mitigation recommendations, and the current status of incident handling. Missing the 72-hour window breaches one of the CRA\u2019s central compliance obligations. The practical consequence is that incident-response processes must not only operate technically within the first working day after discovery but also be ready for regulatory reporting.<\/p>\n
The third step is the final report. For actively exploited vulnerabilities, a 14-day deadline applies from the moment a corrective measure becomes available \u2013 that is, when the patch can be rolled out. For severe security incidents, this period extends to one month. The final report documents the root cause, the measures taken, the patch deployment status, and lessons learned for future product versions. It serves as the basis for follow-up audits by ENISA and national authorities.<\/p>\n
\n24 \/ 72 \/ 14<\/div>\nHours Early Warning, hours Full Report, days Final Report \u2013 the CRA reporting cadence from 11 September 2026<\/div>\nSource: EU Digital Strategy, CRA Reporting Obligations 2026<\/div>\n<\/div>\nWho Reports Within the Company and Where<\/h2>\n
CRA reports are filed centrally via the CRA Single Reporting Platform \u2013 a single-entry system operated by ENISA. The vendor formally addresses the report to the Computer Security Incident Response Team in the member state of its headquarters. In Germany, that is the BSI or CERT-Bund, respectively. The information is simultaneously forwarded to ENISA, except in clearly defined exceptions involving special security interests.<\/p>\n
For companies with multiple production sites or subsidiaries across EU states, the headquarters rule is decisive. It determines which CSIRT is competent, which national guidelines apply, and who to contact with follow-up questions. Conglomerates with mixed structures must document this assignment clearly and clarify within the organization who triggers the report in an emergency. A product owner without authority for official communications will fail in the CRA reality.<\/p>\n
Within the company, the CRA report requires a defined responsibility. Typically, this sits with the Product Security Incident Response Team (PSIRT) directly linked to the CISO office. If you do not have a PSIRT today, you must establish the function before the deadline. The alternative \u2013 pushing development teams into ad-hoc reporting \u2013 does not scale and will collapse under the 24-hour deadlines. The staffing question is at least as critical as the technical preparation.<\/p>\n
What a CRA-ready incident response process must deliver<\/h2>\n
A CRA-compliant process rests on three pillars: Detection, Assessment and Reporting. Detection means the manufacturer must identify active exploitation early \u2013 through monitoring of its own products, analysis of threat-intelligence feeds, coordinated vulnerability-disclosure channels and participation in ISAC structures. A manufacturer that only reacts to customer complaints starts from a weak position because it crosses the knowledge threshold too late and the 24-hour clock starts ticking alongside incident triage.<\/p>\n
Assessment means being able to judge the relevance of a report within hours. Is the reported vulnerability actually being exploited in the wild, or only theoretically exploitable? Which product versions are affected? Are mitigations already available, or must a hotfix be built? This triage capability demands an up-to-date SBOM, tested reproduction environments and a clear escalation matrix. Teams that still finish triage after several days need process and tooling investments.<\/p>\n
Reporting is the final pillar \u2013 and the point where compliance duty meets technical reality. The disclosure content must be structured, precise and legally watertight. The CSIRT does not want marketing copy; it needs CVE-level technical details, unambiguous timestamps and verifiable mitigation steps. Translating between engineering, legal and communications on the fly wastes precious minutes. Pre-approved templates and model texts are mandatory preparation.<\/p>\n
SBOM as the technical prerequisite<\/h2>\n
The CRA explicitly requires the creation and maintenance of a Software Bill of Materials as the foundation of vulnerability handling. An SBOM is a machine-readable inventory of every software component in a product \u2013 including versions, licenses and dependencies. Without an SBOM, manufacturers cannot quickly determine which products are affected when a vulnerability surfaces, making it practically impossible to meet reporting deadlines.<\/p>\n
The two most common SBOM formats are SPDX and CycloneDX. Both are machine-readable, tool-supported and ENISA-compliant. For implementation, generation during the build process is recommended \u2013 SBOMs drawn from the repository are often incomplete because they fail to capture binary dependencies and transitive libraries. Tools such as Syft, Trivy or the SBOM integrations built into major package managers have become standard in DACH development environments and deliver reliable results.<\/p>\n
Continuous maintenance is critical. An SBOM created only at release becomes stale within days as dependencies are patched. CRA-ready organizations treat SBOMs as living artifacts, versioned with every build and stored in a central repository. In an incident, a targeted query can then identify within minutes which product versions contain the vulnerable library \u2013 the prerequisite for rapid reporting.<\/p>\n
Timeline: What must be in place when<\/h2>\n
\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/pexels-30965500-cisco-fmc-zero-day-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/supply-chain-glassworm-2026-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/pexels-279810-privileged-access-management-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-data-act-durchfuehrungsgesetz-iot-herste-60577565-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-valkey-9-redis-fork-18-monate-cloud-cach-69791755.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-ki-governance-2026-nur-14-prozent-haben-18715512-250x167.jpg\")
<\/span>