EU Cyber Resilience Act 2026: Reporting Deadlines, Scope and Compliance Checklist
The EU Cyber Resilience Act (CRA) reaches an important operational milestone on 11 September 2026.
From that date, manufacturers of covered products with digital elements must begin reporting:
- actively exploited vulnerabilities; and
- severe incidents affecting the security of those products.
The reporting obligations start well before the CRA’s broader requirements become fully applicable on 11 December 2027. The Act itself entered into force on 10 December 2024, while provisions concerning notification of conformity-assessment bodies began applying on 11 June 2026.
That means 2026 is not simply a preparation year.
For many manufacturers, the CRA is already becoming an operational incident-response and vulnerability-management requirement.
The European Commission’s current reporting guidance states that an early warning must be submitted within 24 hours of becoming aware of a reportable actively exploited vulnerability or severe incident, followed by a full notification within 72 hours.
For companies selling software, connected devices, embedded systems, or other digital products into the EU, the key question is therefore no longer only:
“Will the CRA affect us in 2027?”
It is:
“Could we identify, assess, and report a CRA event within 24 and 72 hours today?”
Executive Summary
The most important CRA milestones are:
| CRA requirement | Date / deadline |
|---|---|
| CRA entered into force | 10 December 2024 |
| Conformity-assessment-body provisions apply | 11 June 2026 |
| Commission practical guidance published | 27 July 2026 |
| Mandatory Article 14 reporting begins | 11 September 2026 |
| Early warning | Within 24 hours |
| Main notification | Within 72 hours |
| Final report for actively exploited vulnerability | No later than 14 days after corrective/mitigating measure is available |
| Final report for severe incident | Within one month after the 72-hour notification |
| Full CRA application | 11 December 2027 |
The Commission confirms this staged implementation timeline.
Table of Contents
What Is the EU Cyber Resilience Act?
The Cyber Resilience Act is the EU’s horizontal cybersecurity law for products with digital elements.
Its purpose is to establish mandatory cybersecurity requirements across the lifecycle of hardware and software products made available on the EU market.
The CRA requires manufacturers to address cybersecurity not only at product launch but throughout the support period.
The Commission says the obligations span the value chain and include vulnerability handling throughout the lifecycle. Products meeting the applicable CRA requirements will carry the CE marking, while national market-surveillance authorities will enforce the rules.
This means the CRA affects more than legal and compliance departments.
It can involve:
- product engineering;
- secure development;
- vulnerability management;
- incident response;
- supplier management;
- patching;
- product documentation;
- customer communications;
- conformity assessment;
- executive governance.
What Are “Products With Digital Elements”?
The CRA applies broadly to products with digital elements placed on the EU market.
This can include hardware and software products, as well as certain remote data-processing solutions that are integral to how the product functions.
Depending on the facts, examples may include:
- connected consumer devices;
- business software;
- operating systems;
- security software;
- network appliances;
- industrial technology;
- embedded software;
- smart devices;
- enterprise applications;
- software components.
The Commission’s July 2026 practical guidance gives additional clarification on scope, including how the rules apply in real-world product scenarios.
The safest approach for businesses is not to assume that “software” or “cloud-connected product” automatically falls outside the CRA.
Instead, perform a documented scope assessment.
Cybersecurity Time CRA Scope Checklist
Ask these questions for each product sold into the EU:
| Question | Why it matters |
|---|---|
| Is the product hardware or software? | Core CRA scope question |
| Is it made available on the EU market? | Territorial relevance |
| Does it contain digital functionality? | Helps establish product-with-digital-elements status |
| Does it rely on remote data processing? | May affect scope |
| Who is the manufacturer? | Determines primary obligations |
| Are third-party components included? | Important for vulnerability visibility |
| Is the product already on the market? | Reporting duties may still matter from Sept 2026 |
| What is the support period? | Determines vulnerability-handling obligations |
| Is the product important or critical? | May change conformity-assessment route |
This is a practical screening framework, not a substitute for legal advice.
What Starts on 11 September 2026?
The major operational change is mandatory Article 14 reporting.
The European Commission states that manufacturers must report:
- actively exploited vulnerabilities; and
- severe incidents having an impact on the security of products with digital elements.
These notifications must be submitted through the CRA Single Reporting Platform, established and operated by ENISA.
The platform is designed to let manufacturers report once rather than sending separate reports to multiple national authorities.
The CRA Single Reporting Platform
The Single Reporting Platform (SRP) is the central technical mechanism for mandatory CRA reporting.
ENISA’s September 8, 2026 FAQ says the SRP is used by manufacturers to report actively exploited vulnerabilities and severe incidents under the CRA. The platform is scheduled to be operational from 11 September 2026.
Manufacturers submit notifications electronically and select the relevant CSIRT designated as coordinator.
In general, that CSIRT is determined primarily by the manufacturer’s main place of establishment. Once submitted, the notification is also made available to ENISA, while the receiving CSIRT handles further dissemination according to the CRA framework.
ENISA has also published a current list of designated coordinator CSIRTs for Member States.
For manufacturers, this means CRA readiness should include more than knowing the legal deadline.
It should also include:
- identifying the correct reporting entity;
- registering appropriate representatives;
- identifying the coordinator CSIRT;
- testing access to the platform;
- defining backup reporting ownership.
The CRA Reporting Timeline
The CRA reporting deadlines are short.
Within 24 Hours — Early Warning
Manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident.
The early warning does not necessarily require every technical fact to be known.
The purpose is to establish an initial notification quickly.
ENISA’s current guidance notes that some data fields may not be required during the 24-hour phase but become required later in the process.
Within 72 Hours — Full Notification
A fuller notification is due within 72 hours.
At this stage, the manufacturer should normally have more information about:
- affected product;
- severity;
- likely impact;
- exploitation;
- incident characteristics;
- mitigation activity;
- probable root cause.
The Commission confirms the 24-hour and 72-hour stages in its current CRA reporting guidance.
Final Report — Actively Exploited Vulnerability
For an actively exploited vulnerability, the final report must be submitted no later than 14 days after a corrective or mitigating measure becomes available.
That creates a strong link between:
vulnerability discovery → remediation → reporting evidence
Organizations with weak patch governance may therefore also struggle with CRA reporting.
For practical remediation governance, see Patch Management SLA Template.
Final Report — Severe Incident
For a severe security incident, the final report must be submitted within one month after the 72-hour notification.
This means organizations need both:
- rapid early escalation; and
- disciplined follow-through.
CRA Reporting Timeline at a Glance
| Stage | Deadline | Main objective |
|---|---|---|
| Awareness | T0 | Identify potentially reportable event |
| Early warning | ≤24h | Notify quickly with available information |
| Full notification | ≤72h | Provide fuller technical and impact detail |
| AEV final report | ≤14 days after corrective measure available | Confirm remediation and final facts |
| Severe-incident final report | ≤1 month after 72h notification | Close incident reporting lifecycle |
The exact information required depends on the notification stage and event type. ENISA’s SRP guidance should be checked before submission.
What Counts as an Actively Exploited Vulnerability?
The CRA reporting obligation is not triggered simply because a vulnerability exists.
The key concept is active exploitation.
That means security teams need a process capable of distinguishing between:
- vulnerability disclosed;
- exploit publicly available;
- exploitation suspected;
- active exploitation confirmed.
This creates a practical requirement for threat intelligence and vulnerability triage.
Sources may include:
- vendor security advisories;
- ENISA;
- CISA KEV;
- CERT/CSIRT reporting;
- internal telemetry;
- trusted security research.
For vulnerability-priority methodology, see KEV vs CVSS Patch Priority.
What Is a Severe Incident?
The CRA also requires reporting of severe incidents having an impact on the security of a product with digital elements.
Determining severity may require analysis of:
- operational impact;
- product availability;
- confidentiality;
- integrity;
- affected customers;
- geographic reach;
- exploitation;
- business consequences.
Organizations should define internal escalation criteria before an incident occurs.
Do not wait until the first serious event to decide which team interprets the reporting threshold.
Why 24 Hours Is the Hardest Deadline
The 24-hour deadline is operationally demanding because the organization may still be investigating the event.
Within the first day, responders may not yet know:
- exact affected versions;
- complete exploitation scope;
- attacker identity;
- final root cause;
- all impacted customers;
- whether the supplier is involved.
The company therefore needs a process that can report what is known, distinguish it from what is still being investigated, and update the notification later.
This is why good CRA readiness depends heavily on incident-management discipline.
For a broader response structure, see the Data Breach Timeline Template.
CRA Reporting Decision Workflow
A practical decision process can look like this:
Step 1 — Detect
Security team identifies:
- vulnerability exploitation;
- suspicious product behavior;
- security incident.
Step 2 — Confirm Scope
Determine:
- affected product;
- affected versions;
- EU market exposure;
- customer impact.
Step 3 — Classify
Ask:
- Is the vulnerability actively exploited?
- Does the incident meet the severe-incident threshold?
Step 4 — Escalate
Notify:
- product security;
- incident response;
- legal/compliance;
- executive owner.
Step 5 — Start the Reporting Clock
Document:
- time of awareness;
- evidence;
- decision owner.
Step 6 — Submit 24-Hour Warning
Provide available information through the SRP.
Step 7 — Continue Investigation
Collect:
- technical evidence;
- impacted versions;
- corrective measures;
- root-cause data.
Step 8 — Submit 72-Hour Notification
Update the regulator-facing record.
Step 9 — Complete Remediation and Final Reporting
Submit the applicable final report.
Products Already on the Market Can Still Matter
One important clarification from ENISA’s current FAQ is that Article 14 reporting obligations apply from 11 September 2026 to products within CRA scope, including products that were placed on the market before the main CRA application date of 11 December 2027.
That is important because some organizations may incorrectly assume:
“Our existing product was launched before 2027, so reporting does not apply yet.”
That assumption can be dangerous.
Manufacturers should review existing supported product lines now.
Open-Source Software: Important Distinction
The CRA contains specific treatment for open-source software and open-source software stewards.
ENISA’s current FAQ clarifies that the Article 14 manufacturer reporting obligations begin on 11 September 2026, while the corresponding reporting obligations for open-source software stewards under Article 24(3) apply from 11 December 2027.
This distinction should be handled carefully.
Not every open-source project has the same CRA obligations as a commercial manufacturer.
Organizations relying heavily on open-source components should still maintain:
- component inventories;
- vulnerability monitoring;
- supplier/dependency visibility;
- patch processes.
Support Periods Matter
The CRA requires manufacturers to define a support period for covered products.
During that period, the manufacturer must handle vulnerabilities effectively.
The Commission’s summary explains that the end date of the support period must be communicated clearly to users, including month and year.
The July 2026 guidance provides further clarification on how support periods should be understood and applied.
This means support-period design should involve:
- product management;
- engineering;
- security;
- legal/compliance;
- customer support.
Substantial Modification
The Commission’s July 2026 practical guidance also clarifies the CRA concept of substantial modification.
This matters because significant post-market changes can affect the product’s compliance position.
Organizations should therefore document:
- product changes;
- security-relevant updates;
- changes in intended purpose;
- major functionality changes;
- major architectural changes.
Change management can become part of CRA evidence.
Important and Critical Products
Not every covered product follows exactly the same conformity-assessment path.
Certain products with particular cybersecurity relevance are classified as important or critical products.
Some products may require third-party conformity assessment by a notified body before being placed on the EU market. The Commission notes that products of particular cybersecurity relevance may need third-party assessment.
Manufacturers should classify product categories early because conformity requirements can affect:
- planning;
- testing;
- documentation;
- certification timelines;
- launch dates.
CE Marking Under the CRA
Covered products that meet the applicable CRA requirements will carry the CE marking.
This indicates conformity with the relevant EU product requirements.
CRA compliance therefore becomes part of the broader product-access framework for the EU market rather than a purely internal security exercise.
Manufacturers should integrate cybersecurity evidence into their conformity process rather than treating security documentation as an isolated SOC activity.
Cybersecurity Time CRA Readiness Matrix
| Area | Key question | Evidence to maintain |
|---|---|---|
| Product inventory | What covered products do we sell in EU? | Product register |
| Software inventory | What components are included? | SBOM/component inventory |
| Vulnerability intake | How are vulnerabilities received? | PSIRT/Vulnerability process |
| Exploitation assessment | Can we determine active exploitation? | Threat intel records |
| Incident response | Can we classify severity quickly? | IR procedures |
| Reporting | Who submits to SRP? | RACI / reporting SOP |
| Patch management | How fast can fixes be delivered? | SLA / release evidence |
| Support period | How long will vulnerabilities be handled? | Product support policy |
| Supplier risk | Which dependencies affect product security? | Supplier inventory/contracts |
| Documentation | Can we demonstrate compliance? | Technical documentation |
This is a practical readiness model, not an official Commission checklist.
Supplier Visibility Is a CRA Issue
Modern products often depend on third-party:
- libraries;
- frameworks;
- firmware;
- cloud services;
- SDKs;
- embedded components.
A vulnerability in a supplier component can become a vulnerability in your product.
Manufacturers therefore need reliable dependency visibility.
Useful controls include:
- SBOMs;
- dependency inventories;
- supplier notification clauses;
- patch obligations;
- vulnerability disclosure requirements;
- support commitments.
For supplier governance, see the Third-Party Risk Assessment Checklist and Supplier Cybersecurity Contract Template.
CRA 90-Day Readiness Checklist
Organizations preparing for the reporting regime should prioritize the following.
Product Scope
- inventory products sold in the EU;
- identify products with digital elements;
- document excluded products;
- classify important/critical products where relevant.
Reporting Ownership
- appoint CRA reporting owner;
- appoint backup representative;
- identify coordinator CSIRT;
- register for the SRP.
Vulnerability Management
- define active-exploitation assessment;
- monitor vendor/CERT/CSIRT intelligence;
- connect PSIRT and incident-response teams.
Incident Management
- define severe-incident criteria;
- record exact awareness time;
- establish 24-hour escalation procedure.
Supplier Visibility
- inventory third-party components;
- obtain vulnerability-notification commitments;
- establish emergency supplier contacts.
Patch Readiness
- define emergency patch process;
- record corrective-measure availability;
- retain remediation evidence.
Documentation
- maintain version history;
- preserve assessment evidence;
- document decisions not to report.
Executive Governance
- define approval authority;
- establish legal review;
- test escalation outside normal business hours.
Run a CRA Reporting Exercise
One of the most useful readiness activities is a tabletop exercise.
Example scenario:
A supplier notifies your security team that a vulnerability in a library embedded in three supported products is being exploited in the wild.
The exercise should answer:
- When does the organization become “aware”?
- Which products are affected?
- Are they in CRA scope?
- Does the event meet the active-exploitation threshold?
- Who owns the decision?
- Which CSIRT is the coordinator?
- Who accesses the SRP?
- Can an early warning be submitted within 24 hours?
- What information is available by 72 hours?
- When will a corrective measure become available?
A tabletop will expose governance gaps much faster than simply reading the Regulation.
How the CRA Relates to NIS2
CRA and NIS2 address different but related areas.
The CRA focuses on cybersecurity requirements for products with digital elements.
NIS2 focuses primarily on cybersecurity risk management and incident reporting for covered entities in designated sectors.
A company may therefore encounter both regimes depending on its:
- business sector;
- products;
- role in the supply chain.
For the broader European entity-level framework, see NIS2 by Country.
Do not assume CRA compliance automatically satisfies NIS2 obligations or vice versa.
Frequently Asked Questions
When do CRA reporting obligations begin?
11 September 2026 for manufacturers under Article 14.
When does the full Cyber Resilience Act apply?
The CRA’s main obligations apply from 11 December 2027.
What must manufacturers report?
They must report:
- actively exploited vulnerabilities; and
- severe incidents having an impact on the security of covered products.
How quickly must a manufacturer report?
The reporting sequence begins with:
- 24 hours: early warning;
- 72 hours: fuller notification.
Where are CRA reports submitted?
Through ENISA’s Single Reporting Platform.
Does the CRA apply only to products launched after December 2027?
No.
ENISA states that the Article 14 reporting obligations from September 2026 apply to in-scope products including products already placed on the market before the 2027 full-application date.
Does the CRA apply to open-source software?
The CRA contains special provisions for open-source software.
Open-source software steward reporting obligations under Article 24(3) apply from 11 December 2027, according to ENISA’s current FAQ.
Is the Commission’s July 2026 CRA guidance legally binding?
The Commission describes the July 2026 guidance as non-binding, but it provides practical clarification intended to help organizations implement the Act.
What is the biggest practical CRA reporting risk?
For many organizations, it is likely to be slow internal decision-making.
The 24-hour deadline means teams cannot spend days deciding:
- who owns the event;
- whether the product is in scope;
- who can access the reporting platform.
Those questions should be settled before an incident occurs.
Final Takeaway
The most important CRA date for security operations in 2026 is:
11 September 2026.
That is when mandatory reporting begins for manufacturers under Article 14.
The wider CRA framework becomes fully applicable on:
11 December 2027.
Between those dates, organizations need to do more than prepare documentation.
They should build an operational process capable of:
detecting → classifying → escalating → reporting → remediating → documenting
a security issue under strict deadlines.
The strongest CRA program will connect:
- product security;
- vulnerability management;
- supplier visibility;
- incident response;
- legal analysis;
- patch management;
- executive governance.
The reporting form is only the final step.
CRA readiness starts with knowing what products you have, what is happening to them, and who can act when the 24-hour clock begins.
Primary Sources
I recommend this source section at the bottom of the WordPress article:
- European Commission — Cyber Resilience Act
- European Commission — CRA Reporting Obligations
- European Commission — CRA Implementation Timeline
- European Commission — July 2026 CRA Implementation Guidance
- ENISA — CRA Single Reporting Platform
- ENISA — CRA SRP Frequently Asked Questions
- EUR-Lex — Regulation (EU) 2024/2847
These are the strongest primary sources for this article.
