The CRA reporting deadline is close, but the real risk is not the date—it is discovering during a live event that ownership, access, product data and evidence controls do not exist.

What changes on September 11, 2026

The Cyber Resilience Act generally applies later, but its mandatory reporting provisions apply first. From September 11, manufacturers must notify actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements. The ENISA Single Reporting Platform is scheduled to be operational by that date; its production URL and live workflow have not yet been published for production verification. See the detailed CRA 24-hour and 72-hour reporting requirements for the staged workflow and evidence fields.

This is not a general requirement to report every bug, outage or support ticket. The two occurrence types have defined thresholds. An actively exploited vulnerability requires reliable evidence that a malicious actor exploited the vulnerability without the system owner’s permission. A severe incident is an incident with a sufficiently serious effect on the security of a product with digital elements, including the CRA criteria concerning important data or functions and malicious code.

The four reporting deadlines

StageDeadlineOperating implication
Early warningWithout undue delay and no later than 24 hours after awarenessThe team needs a minimal, accurate packet and emergency approval path.
Vulnerability or incident notificationWithout undue delay and no later than 72 hours after awarenessThe record expands to product, event, assessment, measures, user actions and sensitivity.
AEV final reportNo later than 14 days after a corrective or mitigating measure is availablePatch or mitigation availability must be timestamped and controlled.
Severe-incident final reportWithin one month after submission of the 72-hour incident notificationThe actual submission timestamp must drive the final-report calendar.

Reporting applies to products already on the EU market

The reporting obligations apply to in-scope products with digital elements made available on the Union market, including products placed on the market before the broader December 11, 2027 application date and products whose support period has ended. A company should not limit readiness work to products scheduled for launch in 2027.

The rules do not retroactively require a report merely because active exploitation was already known before September 11. If a vulnerability was known but the manufacturer learns of active exploitation on or after September 11, the reporting duty can be triggered. Product-specific legal review remains necessary.

The SRP is only the submission route

The platform is designed to route a notification to the relevant coordinating CSIRT and ENISA. ENISA says to continue the same notification record through the 24-hour early warning, 72-hour notification, subsequent updates and final report; a coordinating CSIRT may request an intermediate report where necessary.

The SRP does not solve the internal work required to determine awareness, identify affected products and Member States, collect technical facts, manage uncertainty, obtain approvals, track corrective measures, preserve user communications or prove what was submitted. ENISA currently states that no API will be available initially.

What manufacturers should complete before launch

  1. Assign a primary reporting owner and backup. Both should have authority and an after-hours escalation path.
  2. Prepare active personal EU Login accounts and two-factor authentication. ENISA’s Assigned Representative is an SRP user role, distinct from a CRA authorised representative. SRP registration occurs when a report is needed.
  3. Inventory products and versions made available in the EU. Include ownership, support status, EU availability and evidence locations—even where support has ended.
  4. Define the awareness decision. After a prompt initial assessment, record when there is a reasonable degree of certainty the trigger is met, with the factual basis in UTC.
  5. Pre-build the 24-hour and 72-hour packets. Do not begin mapping fields during a live event.
  6. Plan submission-confirmation evidence. Preserve notification IDs, exact content, confirmation email or alert, and a screenshot or export if available.
  7. Run two tabletop scenarios. Test one actively exploited vulnerability and one severe incident without making a fictitious SRP submission.

A practical first-week sequence

Day one should establish ownership. Day two should establish access. Day three should build the product register. Day four should approve awareness and reportability procedures. Day five should test the reporting packets. Day six should organize the evidence repository and naming rules. Day seven should run a tabletop and assign every gap.

The objective is not to predict every incident. It is to make sure the organization can identify the right people, preserve the right time, collect the right facts and produce a controlled report before the deadline becomes the process. Teams can also download the 24-hour reporting readiness checklist to assign the first operating steps.

Turn the rule into a controlled process

EU CRA 24/72-Hour Reporting Readiness & Evidence System

Manage awareness, deadlines, ENISA fields, stage packets, approvals, corrective measures, evidence and submission confirmations in one Excel-based operating system.

$149Early access
View the system

Frequently asked questions

Do all CRA requirements start September 11, 2026?

No. The mandatory reporting provisions apply from September 11, 2026; most broader product requirements apply from December 11, 2027.

Is the 24-hour report a complete technical investigation?

No. It is an early warning. The available facts expand at the 72-hour and final-report stages.

Does the September 2026 reporting duty reach existing products?

It applies to in-scope products made available on the EU market, including products placed before December 11, 2027 and products whose support period has ended, subject to the non-retroactivity and awareness nuances described above.

Primary sources

Independent scope boundary

Syntera Systems is not affiliated with or endorsed by the European Commission, ENISA or any member-state CSIRT. This article provides operational information, not legal advice. Applicability and reportability are fact-specific.