CRA reporting obligations:
The 24/72-hour plan

The Cyber Resilience Act reporting obligations become operational on 11 September 2026. Manufacturers must notify actively exploited vulnerabilities and severe incidents affecting products with digital elements. An early warning is due without undue delay and within 24 hours of becoming aware; the main notification follows within 72 hours. A team that first identifies product ownership, decision authority and available evidence during an incident will spend the deadline on coordination rather than response.

This guide turns the official requirements into a workable process for software vendors, IoT manufacturers and technical SMEs. It offers engineering and organisational guidance, not legal advice. Whether a specific business or product is in scope must be assessed against the Regulation and, where necessary, with qualified counsel.

What changes on 11 September 2026

Article 14 reporting starts on that date. The European Commission identifies two reportable categories: actively exploited vulnerabilities and severe incidents affecting the security of a product with digital elements. Manufacturers submit once through ENISA's Single Reporting Platform (SRP) to the relevant coordinating Computer Security Incident Response Team (CSIRT) and, as a rule, simultaneously to ENISA.

This does not mean “report every vulnerability within 24 hours.” According to the ENISA FAQ updated 3 August 2026, an actively exploited vulnerability requires reliable evidence that a malicious actor exploited it without the system owner's permission. A severe incident negatively affects, or is capable of negatively affecting, the availability, authenticity, integrity or confidentiality of the product's data or functions.

What information each CRA reporting deadline needs

The process is deliberately staged. The early warning prioritises speed; later submissions add technical assessment. The Commission and ENISA describe this sequence:

Stage	Deadline	Practical information core
Early warning	within 24 hours	Occurrence type, manufacturer, affected product and title; available initial facts
Main notification	within 72 hours	General nature, initial assessment, actions taken and mitigations available to users
Final: vulnerability	14 days after a fix is available	Description, severity, impact and details of the update or corrective measure
Final: incident	one month after the 72h report	Impact, likely root cause and applied or ongoing mitigation

The clock begins when the manufacturer becomes aware of the active exploitation or severe incident. Every case therefore needs a recorded awareness timestamp, source and initial reviewer. Without that evidence, a team cannot reliably control the deadline or later explain its decision.

Who may be affected by CRA reporting in 2026

The CRA directs its main obligations to manufacturers that make a product with digital elements available on the EU market under their name or trademark. This can include standalone software, connected devices and components marketed separately. Role, product and market activity matter more than industry labels or company size. The Commission's legislative summary describes in-scope products as those whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection.

Legacy products belong in the analysis. The Commission states that reporting applies to relevant products already made available on the EU market, including products placed there before 11 December 2027. ENISA also states that exploitation already known to the manufacturer before reporting begins is not notified retroactively. That temporal limit is important, but it does not replace a product-specific legal assessment.

Importers, distributors, open-source software stewards and free-software contributors have different roles and, in some cases, different duties. A SaaS product, internal application or remote service cannot be classified reliably from its label alone. The Commission's guidance published on 27 July 2026 provides examples and scope distinctions. Document uncertain cases and obtain specialist advice where the consequence matters.

A seven-step CRA incident reporting workflow

1. Inventory products and roles. Record product names, supported versions, responsible legal entity, EU markets, support status and technical owner. Mark unresolved scope questions rather than silently guessing.
2. Converge intake channels. Support, security mailboxes, monitoring, customer reports, supplier notices and public vulnerability sources must reach one triage function. A visible security contact prevents useful reports from being lost.
3. Define decision criteria. Distinguish an ordinary vulnerability, reliable evidence of active exploitation and a potentially severe product-security incident. Preserve evidence, uncertainty and the reason for the decision.
4. Record awareness. Timestamp when the company became aware, identify the source and assign a reviewer. An uncertain ticket must still have an owner and an escalation time.
5. Prepare 24h and 72h templates. Treat ENISA's current field list as a data contract. Product, Member States, event type, initial assessment, corrective action and user mitigation should be fields, not an improvised email narrative.
6. Set authority and backup. Engineering assesses evidence; management and, where appropriate, legal review external statements. Primary and secondary representatives must cover weekends, leave and unavailable specialists.
7. Run a tabletop test. Simulate an actively exploited dependency in a shipped product. After two hours, check whether the team can see affected releases, possible user impact, mitigations, accountable people and the reporting decision path.

These steps are ATMAN's implementation analysis, not verbatim CRA requirements. They derive from the short deadlines and ENISA's published reporting fields. The engineering objective is a traceable incident workflow that supports the regulatory decision without blocking containment and remediation.

How product data makes 24 hours manageable

A software bill of materials (SBOM) is not the September notification. It can, however, answer a crucial triage question: which supported product release contains the affected component? The German Federal Office for Information Security (BSI) recommends integrating SBOM tools during development and planning vulnerability handling across the product lifecycle.

In practice, the inventory must connect releases, dependencies, market availability and ownership. A scanner without product context produces findings but not a defensible reporting decision. An SBOM also does not establish exploitation or incident severity. The useful chain is: capture the signal, establish product exposure, assess evidence, contain impact, document the reporting decision and update the submission on time.

Prepare access without racing ahead of ENISA's process. An active EU Login account is required, but ENISA advises organisations to start SRP registration and validation only when a specific notification is needed. CSIRT validation then runs in parallel and does not block submission. Teams can prepare roles and company data now, while following the current ENISA registration guide when a report becomes necessary because platform details remain subject to change.

Readiness checklist for 11 September

• Is the legal entity acting as manufacturer identified for every relevant product?
• Do security, support and supplier signals reach an accountable function at any time?
• Can the team distinguish active exploitation and a severe product incident from a routine finding?
• Who records awareness and starts the 24/72-hour clock?
• Are versions, EU markets, technical owners and first mitigations quickly discoverable?
• Are approved templates ready for the early warning, 72-hour notification and final report?
• Who owns the technical decision, external communication and backup coverage?
• Has the workflow been tested with a realistic scenario and incomplete information?

Frequently asked questions about CRA reporting

What must manufacturers report from 11 September 2026?

Manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of a product with digital elements. An ordinary vulnerability does not automatically trigger a CRA notification.

Do CRA reporting obligations cover older products?

Yes. Reporting covers products with digital elements made available on the EU market before 11 December 2027. ENISA states that exploitation already known to the manufacturer before 11 September 2026 is not reported retroactively.

Should manufacturers register on the CRA reporting platform now?

An active EU Login account can be prepared. ENISA advises starting SRP registration and validation only when a specific notification is required.

Do all CRA requirements apply from September 2026?

No. Article 14 reporting applies from 11 September 2026. The main product and lifecycle requirements generally apply from 11 December 2027.

Sources and methodology

• European Union: Regulation (EU) 2024/2847 – Cyber Resilience Act, published 20 November 2024, accessed 30 August 2026
• European Commission: Cyber Resilience Act – Reporting obligations, updated 31 July 2026, accessed 30 August 2026
• ENISA: Single Reporting Platform frequently asked questions, updated 3 August 2026, accessed 30 August 2026
• ENISA: CRA SRP assigned-representative registration guide, updated 3 August 2026, accessed 30 August 2026
• European Commission: Guidance on timely CRA implementation, published 27 July 2026, accessed 30 August 2026
• BSI: Cyber Resilience Act overview for organisations, accessed 30 August 2026

Regulatory statements were checked against EU and ENISA primary sources. The seven-step workflow and prioritisation are ATMAN analysis based on those requirements and are not legal advice.