EU Cyber Resilience Act Reporting: What Changed in 2026

From 11 September 2026, manufacturers of products with digital elements within the scope of the EU Cyber Resilience Act (CRA) must report actively exploited vulnerabilities and severe incidents affecting product security. An early warning is due within 24 hours of becoming aware; a further notification with general information and an initial assessment follows within 72 hours. This reporting duty is already active, ahead of the CRA’s main obligations on 11 December 2027. ENISA says it also covers in-scope products placed on the market before that later date. Open-source software stewards enter the reporting regime on 11 December 2027.

The CRA reporting deadlines at a glance

Report	Trigger	Deadline
Early warning	Awareness of an actively exploited vulnerability or severe incident	Without undue delay, and no later than 24 hours after awareness
Notification	The same awareness event	Without undue delay, and no later than 72 hours; include general information and an initial assessment
Final report: actively exploited vulnerability	A corrective or mitigating measure becomes available	No later than 14 days after the measure becomes available
Final report: severe incident	The 72-hour notification	Within one month after that notification

The two final-report deadlines start from different events. The 14-day clock is not a general deadline measured from the first discovery of every vulnerability. The European Commission’s reporting guidance and ENISA’s Single Reporting Platform FAQ set out the reporting sequence.

What is reportable—and what the 2026 date means

Article 14 of the CRA focuses on two reportable triggers: actively exploited vulnerabilities and severe incidents that have an impact on the security of a product with digital elements. A routine bug report or a vulnerability that is not actively exploited is not automatically the same as an Article 14 reportable event. Teams still need to assess the facts against the Regulation’s definitions and any other applicable duties.

The first deadline is narrower than “the whole CRA starts in 2026.” Manufacturers’ reporting obligations began on 11 September 2026; the CRA’s main cybersecurity requirements apply from 11 December 2027. ENISA’s FAQ says the Article 14 reporting duty covers products within the CRA’s scope, including products placed on the market before 11 December 2027. That makes legacy product versions part of the readiness review, not just products launched after the main application date.

Open-source software stewards have a different start date: the reporting obligations in Article 24(3), as referenced by Article 71(2), apply from 11 December 2027. Do not assume that stewards and manufacturers share the September 2026 deadline.

How ENISA’s Single Reporting Platform works

ENISA launched the CRA Single Reporting Platform (SRP) on 11 September 2026. A manufacturer submits one notification through the platform and identifies the appropriate coordinating Computer Security Incident Response Team (CSIRT). The Commission says the notification is addressed to the CSIRT for the manufacturer’s main establishment and is, in normal circumstances, made available simultaneously to ENISA. The receiving CSIRT shares it with other relevant national CSIRTs.

The SRP is the common electronic reporting route, not a replacement for product-security work. ENISA described the launch as an initial operating capability and said it would expand platform functionality based on operational experience. Before an incident, confirm who can submit for each manufacturer, how the relevant CSIRT is identified, and which current ENISA instructions apply.

A practical readiness checklist for product teams

Map products and legal roles. Identify product families placed on the EU market, versions still supported or in use, and which legal entity acts as manufacturer for each product. Include products already on the market before 11 December 2027.
Define the reportability triage. Give security staff a route to distinguish an actively exploited vulnerability or severe product-security incident from routine defect intake. Record the facts behind the decision and involve legal or compliance specialists where scope is uncertain.
Start the clock from awareness. Define who receives security reports, how awareness is timestamped, and who is on call to escalate outside office hours. The 24- and 72-hour periods run from becoming aware, so an internal handoff should not leave the start time ambiguous.
Prepare a reusable evidence record. Capture the affected product and versions, what happened, the security impact, the initial assessment, known exploitation, mitigation or corrective measures, and key timestamps. Assign owners for the early warning, 72-hour notification and final report separately.
Test the reporting handoff. Confirm platform access, an authorised submitter and the relevant coordinating CSIRT before a live case. Keep ENISA’s current FAQ and user guidance with the incident-response playbook.
Check parallel obligations. A CRA notification does not, by itself, establish that every other incident-reporting duty has been met. Assess any separate legal or contractual reporting requirements independently.

SignorCrypto analysis: make the reporting path operational

The practical change is not just a new portal. A manufacturer needs a traceable path from a security signal to product identification, reportability assessment, a time-stamped decision and a submitted notification. The short early-warning window rewards an incident process that already connects product, security and compliance owners; assembling those roles after an alert arrives creates avoidable delay.

The CRA is also only one part of a product’s regulatory context. Our EU Digital Product Passport guide covers a separate EU framework for product information, while our EU AI Act transparency guide covers disclosure duties for certain AI systems and outputs. These are distinct regimes; neither should be treated as a substitute for CRA incident reporting.

Frequently asked questions

Does the CRA require a report for every vulnerability?

No. The Article 14 reporting triggers are actively exploited vulnerabilities and severe incidents that affect the security of a product with digital elements. Whether a specific case meets the legal definition depends on its facts; this overview is not a substitute for a scope assessment.

Do the reporting rules cover products already on the market?

ENISA says the reporting obligations apply to products within the CRA’s scope, including products placed on the market before 11 December 2027. Manufacturers should include relevant existing product versions in their inventory.

Do open-source software stewards report from September 2026?

No. The reporting obligations applicable to open-source software stewards under Article 24(3) apply from 11 December 2027. Their position differs from manufacturers’ reporting duties, which began on 11 September 2026.

When is the final report due?

For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, within one month after the 72-hour notification.

Sources

This is an educational operational overview, not legal advice. Confirm product scope and reporting decisions against the applicable legislation and the facts of the case.

If you need to connect product inventory, security triage and CRA reporting into a workable engineering process, contact SignorCrypto to discuss the technical architecture and integrations.