EU CRA Cybersecurity

What does the EU Cyber Resilience Act's September 2026 reporting obligation require from manufacturers?

Phillip Stephens 20 May 2026 8 min read Updated 1 June 2026

Starting 11 September 2026, manufacturers of products with digital elements sold into the EU must report actively exploited vulnerabilities and severe incidents to ENISA on a strict three-step timeline: 24 hours, 72 hours, 14 days. Here's what that means operationally.

Starting 11 September 2026, manufacturers of “products with digital elements” sold into the EU must report actively exploited vulnerabilities and severe incidents to ENISA on a strict three-step timeline: 24 hours for an early warning, 72 hours for a substantive notification, and 14 days for a final report. National CSIRTs are notified in parallel through ENISA’s Single Reporting Platform. There is no minimum-revenue threshold, no quiet enforcement period, and no opt-out.

Who has to report?

The reporting obligation applies to any product with digital elements placed on the EU market. Article 3 of the Cyber Resilience Act defines this category broadly: any hardware or software product and its remote data processing solutions (including software or hardware components) whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

That sweep is wide. It captures smart consumer electronics, industrial IoT, embedded SaaS components, standalone software products, and a long tail of products their makers don’t usually think of as “cyber” — smart thermostats, network-connected appliances, even connected toys. If it has digital elements and ships in the EU, the reporting obligation applies. Many of the same connected products face two further EU deadlines the same year — the Digital Product Passport registry launch and the Right to Repair Directive.

A specific set of exclusions exists where products already fall under sector-specific cyber rules:

Medical devices under MDR (Regulation 2017/745) and IVDR (Regulation 2017/746) — excluded by Article 2(2)(a) and (b)
Motor vehicles under the EU type-approval regime (Regulation 2019/2144, incorporating UNECE WP.29 R155/R156) — excluded by Article 2(2)(c). Note: same systems sold separately outside the type-approval regime remain in scope
Civil aviation products certified under Regulation 2018/1139 — excluded by Article 2(3)
Marine equipment within Directive 2014/90 — excluded by Article 2(4)
National security and defence products developed exclusively for those purposes — excluded by Article 2(7). The word “exclusively” is critical; dual-use products remain in scope

The default assumption for any regulated hardware product is that CRA applies until you’ve verified the specific exclusion holds for your product class.

The 24 / 72 / 14 timeline — in detail

The CRA’s reporting cadence has three sequential obligations:

Within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product, you submit an early warning to ENISA’s Single Reporting Platform. The early warning need only identify the product, indicate that an active vulnerability or severe incident has been observed, and provide a means of contact. Detail can be thin — what matters is that the clock has started.

Within 72 hours of becoming aware, you submit a vulnerability notification or incident notification with substantive technical content: severity assessment, affected versions or product batches, available mitigations, indicators of compromise where relevant.

Within 14 days of a corrective measure becoming available (for actively exploited vulnerabilities), or within 1 month after the initial notification (for severe incidents), you submit a final report: the full incident description, response measures taken, root cause analysis where available, and corrective actions implemented. The two cadences are deliberately different — vulnerabilities clock from “corrective measure available” while incidents clock from initial notification.

Note the trigger phrase: “becoming aware.” This is a wide standard. If your support team receives a credible report on a Saturday and the relevant security lead finds out Monday morning, the 24-hour clock started Saturday. Build your runbooks accordingly.

What counts as an “actively exploited” vulnerability?

An actively exploited vulnerability is one where there is reliable evidence the vulnerability is being abused in the wild — not theoretically exploitable, but actually exploited against at least one user or asset. The bar is meaningfully lower than CVE assignment or public disclosure.

Concrete indicators include: confirmed compromises reported by customers, signals from product telemetry, ransomware deployments tied to a specific product flaw, or credible threat-intelligence reports linking activity to your product.

You do not need to wait for a CVE identifier to be assigned. If your incident response team has evidence of exploitation in the wild, the obligation triggers — even if the broader security community hasn’t picked up the signal yet.

What counts as a “severe incident”?

The CRA defines a “severe incident” as one having a significant impact on the security or availability of a product with digital elements. ENISA has not yet published detailed operational guidance establishing concrete thresholds — as of mid-2026 the working interpretation is: an incident is severe if it materially compromises confidentiality, integrity, or availability of the product, or causes substantial economic or material damage to users. Operational guidance is expected from ENISA before the platform goes live on 11 September 2026.

For practical purposes: if your product is exfiltrating data unintendedly, has been rendered unavailable through attack, or is being weaponised to attack other systems, treat it as severe.

How reporting flows: ENISA’s Single Reporting Platform

ENISA is building the Single Reporting Platform (SRP) as the one electronic channel for all CRA notifications. Manufacturers submit once; the platform automatically routes to the designated CSIRT coordinator (based on the manufacturer’s main establishment) and to ENISA simultaneously. The receiving CSIRT then disseminates information to other relevant member-state CSIRTs and market-surveillance authorities as needed. No separate per-member-state filing required.

The platform is scheduled to be operational by 11 September 2026 — the same date the reporting obligations enter into application. As of mid-2026, registration is not yet open and no public URL has been published; a testing period is expected before go-live. Manufacturers should plan to register an organisational account and designate at least two reporting contacts — primary and backup — as soon as the platform opens, so the 24-hour clock is never starved on a weekend or during a holiday.

What happens if you miss the deadline?

CRA’s Article 64 establishes a three-tier penalty regime:

Tier 1 (highest) — up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. This tier covers non-compliance with the essential cybersecurity requirements in Annex I and the manufacturer obligations in Articles 13 and 14. Reporting failures under Article 14 sit in this top tier.
Tier 2 — up to €10 million or 2% of worldwide turnover. Covers other CRA obligations including importers/distributors and conformity assessment.
Tier 3 — up to €5 million or 1% of worldwide turnover. Covers supplying incorrect, incomplete, or misleading information to authorities or notified bodies.

Individual EU member states implement their own enforcement authorities under CRA, but the penalty ceiling is set by the regulation itself — there is no member-state discretion to lower it. Article 64 also requires regulators to consider proportionality, including the size of the undertaking and whether the offender is a microenterprise, SME, or startup. The EU has demonstrated willingness to enforce digital regulation vigorously under GDPR; CRA is structured similarly and the enforcement pattern is likely to follow.

What to do before 11 September 2026

Five concrete actions, in priority order:

Map your product portfolio against CRA scope — which products are products with digital elements, which exclusions might apply. Document the analysis. This determines whether you have one reporting obligation or many.
Identify the responsible reporting contact in your organisation. Typically a security lead, sometimes a regulatory affairs lead. Designate a backup. The 24-hour clock does not pause for vacations, weekends, or organisational turnover.
Build the trigger procedure into your incident response runbook — when does the 24-hour clock start, who decides, what does the escalation path look like on a weekend. Pre-built procedures with documented decision points dramatically reduce the chance of a reporting failure when an incident actually hits.
Pre-draft your four-stage notification templates — 24-hour early warning, 72-hour notification, 14-day vulnerability final report, and 30-day severe-incident final report. Composing notifications under a 24-hour deadline with a live incident in flight is the worst time to figure out what goes in them. The elements required by CRA’s reporting articles are known — draft once, refine as ENISA publishes operational templates ahead of platform go-live.
Establish your ENISA Single Reporting Platform account as soon as the platform goes live (expected by 11 September 2026). Verify your reporting contacts have access. Validate the technical channel works before you need it.

ForgeComply’s compliance pathway and evidence-assembly modules are designed to automate steps 1, 3, and 4 — mapping product scope against regulation, building incident-response runbooks with built-in regulatory triggers, and pre-drafting notification templates from a verified clause library. If you’re a small team facing the September deadline without dedicated compliance staff, software can carry meaningful load. The EU Cyber Resilience Act deadline tracker sets the 11 September 2026 reporting date within the full phased timeline through the December 2027 main obligations. The same evidence-assembly-under-deadline pattern drives the US analogue — the cybersecurity documentation FDA Section 524B requires in a premarket submission.

Key takeaways

11 September 2026 — EU CRA reporting obligations enter into application. Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents. Main CRA compliance obligations follow on 11 December 2027.
Four-stage cadence — 24 hours (early warning) → 72 hours (substantive notification) → 14 days (vulnerability final report, from corrective measure availability) → 30 days (severe-incident final report, from initial notification).
Single Reporting Platform — automatically routes notifications to the manufacturer’s main-establishment CSIRT and ENISA simultaneously. No separate per-member-state filing.
“Becoming aware” — a wide standard. Build runbooks to start the 24-hour clock from first credible internal report, not from formal escalation.
Article 64 penalties — Article 14 violations sit in the top tier (up to €15 million or 2.5% of worldwide annual turnover, whichever is higher). Tier 2 (€10M / 2%) and Tier 3 (€5M / 1%) cover other infringements.
Before the deadline — build incident-response procedures, designate reporting contacts, and pre-draft templates. The clock does not pause for organisational unpreparedness.