EU CRA Reporting Deadline: 11 September 2026

The first operational deadline under the EU Cyber Resilience Act (CRA) arrives on 11 September 2026. From that date, manufacturers must report two defined classes of product-security event: an actively exploited vulnerability contained in a product with digital elements and a severe incident affecting the security of such a product.

This deadline is separate from the CRA's main product cybersecurity and conformity requirements, which apply from 11 December 2027. Waiting for the later date is a serious planning error. The reporting duty applies to in-scope products already made available on the EU market before full application, and the first submission may be due within 24 hours of awareness.

This guide is for product-security, incident-response, engineering, legal, and compliance teams deciding whether they can identify, approve, and submit a reportable event on time. For the wider regulatory overview, see the EU CRA standard page.

At a Glance

Question	Current answer as of 6 September 2026
Controlling law	Regulation (EU) 2024/2847, principally Articles 14–17 and Article 24
Reporting start	11 September 2026
Main reporter	Manufacturer of the in-scope product with digital elements
Other reporter	An open-source software steward where Article 24 conditions apply
Reportable vulnerability	An actively exploited vulnerability contained in the product
Reportable incident	An incident having a severe impact on the product's security
First deadline	Without undue delay and within 24 hours of awareness
Second deadline	Without undue delay and within 72 hours of awareness
Final report: vulnerability	No later than 14 days after a corrective or mitigating measure becomes available
Final report: severe incident	Within one month after the 72-hour notification
Submission route	ENISA Single Reporting Platform (SRP)
Full CRA application	11 December 2027

Does the 2026 Reporting Duty Apply to Your Product?

Use a product-and-event test, not a company-wide assumption.

1. Is there a product with digital elements?

The CRA generally covers software or hardware products and their remote data-processing solutions when the intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Standalone software distributed as a product can be covered; a service label does not automatically remove a connected product or its remote processing from scope.

The regulation also contains exclusions and sector boundaries, including specified medical-device, motor-vehicle, aviation, marine, national-security, and non-commercial free and open-source situations. Apply the legal definition and exclusions to the exact product and commercial model. “We are a SaaS company” or “our code is open source” is not a complete scope analysis.

Maintain a product register with the legal manufacturer, version, distribution model, EU market route, remote processing, commercial context, exclusions considered, and a reasoned scope decision.

2. Has the product been made available on the EU market?

The European Commission's CRA summary confirms that the reporting obligation applies to covered products already made available on the Union market before 11 December 2027. An older release cannot be excluded merely because the main conformity regime has not yet started.

This creates an immediate inventory problem. Product-security teams often monitor current supported versions while legal entities, distributors, and customers may still have earlier versions in the EU. The reporting register should reconcile product versions, support status, distribution records, and the entity acting as manufacturer.

3. Is the event one of the two mandatory categories?

An actively exploited vulnerability requires reliable evidence that a malicious actor exploited the vulnerability in a system without the system owner's permission. A vulnerability being publicly known, assigned a Common Vulnerabilities and Exposures identifier, or rated critical is not by itself the statutory trigger.

A severe incident is an incident affecting a product's ability to protect the availability, authenticity, integrity, or confidentiality of data or functions and meeting the severity criteria in Article 14(5). Product impact, disruption, duration, user effects, geographic spread, and economic or societal effects can matter.

Write a short decision tree that preserves both sides of the conclusion:

What product and versions are affected?
What evidence supports actual malicious exploitation or severe product-security impact?
When did the manufacturer become aware of the reportable facts?
Who made the reportability decision, at what time, and from which evidence?
What information remains uncertain but can be supplied at the next stage?

Do not wait for root-cause certainty before escalating. The staged process exists because complete facts are rarely available within the first 24 hours.

Who Must Submit the Notification?

For Article 14, the legal duty sits with the manufacturer. The operational submitter is an assigned representative using the SRP. A manufacturer may delegate tasks, but its accountability and internal authority need to be documented.

ENISA's September 2026 FAQ adds an important group-company rule: only one notification is required for a reportable vulnerability or severe incident even when the manufacturer has multiple branches or subsidiaries in the EU or a parent outside the EU. The manufacturer must coordinate internally and prevent duplicate or inconsistent submissions.

Open-source software stewards have related reporting duties under Article 24 to the extent they are involved in developing products with digital elements. That is distinct from treating every non-commercial contributor as a manufacturer. Record the project, legal entity, commercial context, deployment involvement, and the provision used for the role decision.

Importers and distributors are not substituted as the Article 14 reporter merely because they are established in the EU. They still need an escalation process for suspected non-conformity and should have current manufacturer contact and product identifiers.

The Three Reporting Stages

The European Commission's reporting page and ENISA's SRP FAQ describe a staged notification rather than one complete incident report.

Stage	Deadline	Practical purpose	Prepare in advance
Early warning	Without undue delay and within 24 hours of awareness	Alert the coordinator and identify the affected Member States where known	Product identity, event type, awareness time, markets, assigned representative, initial sensitivity view
Vulnerability or incident notification	Without undue delay and within 72 hours	Provide the fuller event, product, severity, impact, exploit or cause, and mitigation assessment	Version scope, CVE or EUVD identifiers where available, evidence, affected users, controls, mitigation, expected corrective action
Final report: actively exploited vulnerability	No later than 14 days after a corrective or mitigating measure becomes available	Close the vulnerability record with severity, impact, remediation, and handling information	Patch or mitigation release evidence, user communication, root cause, affected versions, validation
Final report: severe incident	Within one month after the 72-hour notification	Close the incident record with cause, mitigation, and preventive measures	Investigation findings, recovery evidence, user impact, corrective actions, lessons learned

The deadline runs from the manufacturer's awareness of facts meeting the relevant threshold. A defensible workflow timestamps incoming evidence, escalation, the reportability decision, approval, submission, and later updates. It should also retain the platform receipt and exact content sent at each stage.

What Changed for the ENISA Platform?

The Single Reporting Platform is the mandatory electronic route. As of the 6 September 2026 review cutoff, ENISA says:

the platform is scheduled to be operational on 11 September 2026;
its dedicated public URL will be published before go-live;
assigned representatives need an EU Login account with multi-factor authentication;
validation can run in parallel and does not prevent initial submissions, subject to ENISA's stated limits;
the launch version supports mandatory CRA reports, while voluntary Article 15 reporting will come later;
no application programming interface (API) is available at launch, so assigned representatives must use the web interface;
the submitter selects the relevant Computer Security Incident Response Team (CSIRT) designated as coordinator.

ENISA published its current list of coordinating CSIRTs on 4 September 2026. Select the coordinator under the CRA location rules and document the reasoning rather than choosing whichever contact is familiar from another incident regime.

Creating an EU Login account now is useful. ENISA advises assigned representatives to initiate SRP registration and validation when they need to submit, so the runbook should distinguish advance identity preparation from the platform registration step available at go-live.

Evidence to Prepare Before an Event

The 24-hour warning cannot depend on reconstructing product ownership from scratch. Build a minimum reporting record for every in-scope product.

Evidence layer	Minimum controlled fields	Owner
Product	Product name, versions, identifiers, legal manufacturer, EU markets, release and support status	Product compliance
Components	Component inventory, supplier, version, dependency path, vulnerability identifiers	Engineering or product security
Signal	Source, received time, analyst, exploitation or incident evidence, confidence	Security operations
Decision	CRA category, awareness time, threshold rationale, approver, sensitivity	Legal and product security
Response	Containment, mitigation, patch plan, affected-user action, owner and target time	Incident response and engineering
Submission	Assigned representative, coordinator, stage, content, timestamp, receipt, updates	Regulatory reporting owner

Third-party components require special attention. A product can contain a reportable vulnerability originating in a library, module, firmware package, or supplied component. Feed supplier advisories, security-research reports, vulnerability databases, and internal telemetry into the same product-level decision process. Do not assume that a supplier's report completes the manufacturer's obligation for the finished product.

A Five-Day Readiness Checklist

1. Freeze the reporting scope

Produce the list of products that can trigger Article 14 reporting on 11 September, including supported and older products already made available in the EU. Record exclusions and unresolved cases with an accountable decision owner.

2. Name the people who can act

Assign a primary and backup representative, legal manufacturer contact, incident commander, legal reviewer, executive escalation point, user-communications owner, and the person authorised to submit without waiting for a full investigation.

3. Create access prerequisites

Create EU Login accounts with multi-factor authentication for assigned representatives. Add the ENISA SRP page, glossary, user guidance, helpdesk, and current CSIRT list to the controlled runbook. Do not invent a platform URL before ENISA publishes it.

4. Approve the decision criteria

Turn the legal definitions into a one-page triage aid. Cover reliable evidence of exploitation, severe security impact, awareness time, third-party component signals, version scope, duplicate group reports, and the path for borderline cases.

5. Pre-build each submission stage

Use ENISA's field glossary to map data owners for the 24-hour, 72-hour, and final-report fields. Mark which fields are required immediately, required later, mandatory when available, or optional. The 24-hour template should work with incomplete facts.

6. Test one timed scenario

Run a tabletop exercise in which a researcher reports exploitation in a third-party component affecting several product versions and EU countries. Stop the clock at 24 hours and 72 hours. Capture delays caused by ownership, evidence, approval, access, translation, user communication, or group coordination.

7. Map overlapping notices

A CRA submission does not replace a NIS2, GDPR, sector-regulator, contractual, customer, insurer, or law-enforcement notice. Create a matrix of event trigger, legal entity, recipient, deadline, data fields, confidentiality, and decision owner. One incident may activate several clocks.

Common Failure Modes

Using 11 December 2027 as the only deadline. Article 14 reporting starts 15 months earlier.
Monitoring only products released after September 2026. Earlier in-scope products already on the EU market are included.
Equating severity scores with active exploitation. The legal trigger requires reliable evidence of malicious exploitation, not only a high vulnerability score.
Waiting for complete facts. The first warning is deliberately limited; the 72-hour and final stages add information.
Letting subsidiaries report independently. ENISA expects one coordinated notification per event for the manufacturer.
Depending on an API. ENISA says no API is available at the platform's initial release.
Treating a CRA report as universal notification. Other legal and contractual regimes remain separate.

Frequently Asked Questions

When do CRA reporting obligations start?

Article 14 reporting obligations apply from 11 September 2026. The CRA's main product cybersecurity and conformity obligations apply from 11 December 2027, but reporting is an earlier operational deadline.

What must be reported under the CRA?

Manufacturers must report actively exploited vulnerabilities contained in an in-scope product and severe incidents affecting the security of that product. Open-source software stewards have related duties under Article 24 when its conditions apply.

What are the CRA reporting deadlines?

Submit an early warning without undue delay and within 24 hours of awareness, then a fuller notification within 72 hours. The final report is due within 14 days after a corrective or mitigating measure becomes available for an actively exploited vulnerability, or within one month after the 72-hour notification for a severe incident.

Do products sold before December 2027 fall under the reporting duty?

Yes. The reporting obligations apply to in-scope products with digital elements already made available on the EU market before 11 December 2027. A manufacturer does not retrospectively report active exploitation it already knew about before 11 September 2026, but awareness after that date can trigger reporting even for an older vulnerability.

How is a CRA report submitted?

The assigned representative submits one notification through ENISA's Single Reporting Platform and selects the appropriate CSIRT designated as coordinator. ENISA says the initial release requires the web interface and EU Login with multi-factor authentication; no reporting API is available at launch.

Research and Review

This guide was materially updated from Regulation (EU) 2024/2847, the European Commission's July 2026 CRA guidance and reporting materials, and ENISA's Single Reporting Platform guidance, FAQ, glossary, and coordinating-CSIRT list. Legal status, dates, platform readiness, and published operating instructions were reviewed on 6 September 2026.

The regulation is binding law. The Commission and ENISA materials explain implementation but do not replace the legal text; ENISA also states that its platform guidance may change. The SRP had not yet reached its statutory go-live date at the research cutoff, so teams should recheck the platform URL and current instructions on 11 September. This article is an implementation aid, not legal advice. See our editorial policy for sourcing, automation, review, and corrections.

Official Sources

Regulation (EU) 2024/2847 — controlling CRA text, including scope, reporting stages, user information, dates, and penalties
European Commission CRA reporting obligations — reporting timetable, Single Reporting Platform, and coordinating-CSIRT flow
European Commission CRA implementation guidance — non-binding July 2026 guidance on scope, substantial modification, support periods, risk assessment, and reporting
ENISA Single Reporting Platform — current platform resources and operating status
ENISA SRP frequently asked questions — assigned representatives, access, deadlines, older products, one-report rule, and launch limitations
ENISA list of CSIRTs designated as coordinators — national coordinator contacts, updated 4 September 2026

EU CRA Reporting Starts 11 September 2026: A 24-Hour Readiness Guide