CRA’s 24-Hour Reporting: IT Security Must Prepare

Starting 11 September 2026, the Cyber Resilience Act mandates reporting for actively exploited vulnerabilities: 24-hour early warning, 72-hour full disclosure, and a 14-day final report. If you don’t have a CRA-ready incident-response process today, you won’t meet those deadlines when it matters. Manufacturers of products with digital elements still have five months to prepare – and time is running out.

What the CRA reporting obligations actually require from September 2026

The Cyber Resilience Act is the EU’s first cross-border product-cybersecurity regulation. It targets manufacturers, importers, and distributors of products with digital elements – 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.

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.

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’t cut it – precise details on affected products, exploits, mitigation status, and patch availability are required.

The 24-72-14 Clock: Reporting Chains in Detail

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’s 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.

Within 72 hours of the same awareness, the Full Report must follow. It includes details on the vulnerability’s nature, affected product versions, initial mitigation recommendations, and the current status of incident handling. Missing the 72-hour window breaches one of the CRA’s 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.

The third step is the final report. For actively exploited vulnerabilities, a 14-day deadline applies from the moment a corrective measure becomes available – 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.

Who Reports Within the Company and Where

CRA reports are filed centrally via the CRA Single Reporting Platform – 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.

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.

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 – pushing development teams into ad-hoc reporting – does not scale and will collapse under the 24-hour deadlines. The staffing question is at least as critical as the technical preparation.

What a CRA-ready incident response process must deliver

A CRA-compliant process rests on three pillars: Detection, Assessment and Reporting. Detection means the manufacturer must identify active exploitation early – 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.

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.

Reporting is the final pillar – 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.

SBOM as the technical prerequisite

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 – 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.

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 – 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.

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 – the prerequisite for rapid reporting.

Timeline: What must be in place when

Sources: EU Digital Strategy, BSI CRA Portal, Hogan Lovells Insights 2026

Gap Analysis: Six Questions for Your Own Process

Before implementation, a structured gap analysis based on six operational questions is recommended. These can be answered in a half-day session within the CISO team and yield a clear action plan:

1. Awareness Threshold: How does the company currently learn about actively exploited vulnerabilities in its own products? Is there a Coordinated Vulnerability Disclosure Policy with short response times? Is threat intelligence filtered and evaluated for relevance to its own products?
2. Triage Capability: Can the security department assess within three to four hours whether a reported vulnerability is actively exploited? Do reproduction environments exist for all production software versions?
3. SBOM Currency: Is an up-to-date SBOM (Software Bill of Materials) generated and maintained for each delivered product? Are the SBOMs machine-readable and searchable, or do they exist as PDF exports in a wiki?
4. Reporting Responsibility: Who within the company is authorized to submit a CRA report to the BSI? Is this role available 24/7? How is coordination with the legal department and communications handled?
5. Template Readiness: Are pre-approved templates available for early warnings, full reports, and final reports? Are they approved by the legal department and technically completed?
6. Exercise Status: Has the CRA reporting chain already been tested in a dry run? Tabletop exercises with time-driven escalation reveal process gaps before they become costly in a real incident.

If you can answer all six questions with a reliable “yes,” you’re CRA-ready. If you have to answer “no” to two or more, you need an immediate roadmap with a timeline extending to August 2026 – one month of buffer before the deadline is the absolute minimum.

Conclusion

The CRA introduces a hard regulatory deadline on 11 September 2026, a requirement that has not previously been part of German product law. The obligation to report actively exploited vulnerabilities is not a compliance document but an operational process that must function within 24 hours. IT security teams need clear accountability, defined escalation paths, current SBOMs, and prepared report templates. The technical build-out is achievable in five months – but only if the gap analysis begins now.

The underestimated challenge is the organizational side: who reports, under what authority, and on what legal basis. Without clarified responsibilities, technical preparations evaporate in a real incident. For most DACH manufacturers, establishing a Product Security Incident Response Team is the decisive step – and that should not begin on 1 September.

Frequently Asked Questions

Every question is locked. A tap unlocks the answer.