Summary
TL;DR
By 11 September 2026, the CRA does not require manufacturers to implement full vulnerability handling processes.
The only obligations that apply from that date are the reporting obligations under Article 14, which are triggered only if a manufacturer becomes aware of:
If neither event occurs, no Article 14 action is required. That's it for September 2026.
Article 13 vs Article 14 — The Key Distinction
Widespread anxiety about the September 2026 deadline stems from a misunderstanding of the CRA's structure — specifically the distinction between Article 13 and Article 14. While closely related, they impose different obligations and do not apply at the same time.
Article 14 — from September 2026
Reporting Obligations of Manufacturers
Establishes a duty to report specific cybersecurity events — actively exploited vulnerabilities and severe incidents — to authorities. Event-triggered, not systemic.
Article 13 — from December 2027
Obligations of Manufacturers
Requires manufacturers to implement product-specific essential cybersecurity requirements and process-based requirements for handling vulnerabilities across the product lifecycle.
Part 1
Actively Exploited Vulnerabilities
What Is an "Actively Exploited Vulnerability"?
Not every vulnerability triggers a CRA reporting obligation. Article 14 applies only to vulnerabilities that are actively exploited — a much narrower category than vulnerabilities discovered through testing or disclosure programmes.
Legal definition — Art. 3(42)
"A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner."
In practical terms, a manufacturer must have identified that:
Example: a flaw in an authentication mechanism that is actively being exploited to allow a threat actor to bypass authentication in users' systems.
What Does Not Constitute an Actively Exploited Vulnerability?
The CRA explicitly distinguishes actively exploited vulnerabilities from vulnerabilities discovered without malicious intent. The following are not subject to mandatory notification:
Good-faith testing
Security researchers probing products with authorisation or in good faith.
Coordinated disclosure
Vulnerabilities submitted through responsible disclosure channels.
Bug bounty programmes
Researcher submissions via manufacturer-run or third-party bounty programmes.
This distinction is fundamental to the CRA's approach — it protects legitimate security research activities and encourages responsible disclosure rather than penalising it.
Why Does the CRA Require Reporting?
Because products with digital elements are typically marketed across the EU, "any exploited vulnerability in a product with digital elements should be considered to be a threat to the functioning of the internal market" (recital 66). Reporting ensures that:
EU-wide overview
CSIRTs and ENISA maintain a coherent picture of the vulnerability landscape across Member States.
NIS2 coordination
Authorities can fulfil their roles under the NIS2 Directive effectively.
Enforcement
Market Surveillance Authorities (MSAs) can perform their oversight and enforcement functions.
Timelines and Information Required
When a manufacturer becomes aware of an actively exploited vulnerability, a structured multi-step reporting process begins. Steps 2 and 3 may be omitted if the required information was already provided in an earlier step.
Early warning notification
- The Member States where the product has been made available
Vulnerability notification (not required if already covered in step 1)
- General information about the product concerned
- General nature of the exploit and of the vulnerability concerned
- Any corrective or mitigating measures taken
- Corrective or mitigating measures that users can take
- Level of sensitivity of the notified information
Final report (not required if already covered in earlier steps)
- Description of the vulnerability
- Its severity and impact
- Information concerning any malicious actor that has exploited or is exploiting the vulnerability (if available)
- Details about the security update or other corrective measures that have been made available to remedy the vulnerability
Note: The final report deadline of 14 days runs from when a corrective or mitigating measure becomes available — not from the date of first becoming aware of the vulnerability.
Part 2
Severe Incidents
What Is a "Severe Incident Having an Impact on the Security of the Product"?
Article 14 looks beyond vulnerabilities in released products. It also covers incidents affecting a manufacturer's own infrastructure when those incidents can create downstream risks for users.
Severe incidents — legal definition
An incident is severe where it:
Example from CRA recital 68
An attacker has successfully introduced malicious code into the release channel through which the manufacturer distributes security updates to users. This is a supply chain attack: compromising the manufacturer's update mechanism allows attackers to push malicious code directly to users under the guise of legitimate security patches.
Why Does the CRA Require Reporting of Severe Incidents?
This obligation reflects the reality of software supply chain attacks, where attackers compromise update mechanisms or development pipelines rather than the product itself. Reporting ensures that authorities and users can take timely action when such compromises may affect product security — even before any product-level vulnerability is identified. It extends the protection perimeter beyond the product to include the manufacturer's entire production and distribution chain.
Timelines and Information Required
Similar to actively exploited vulnerabilities, manufacturers must initiate a structured multi-step process when they become aware of a severe incident. Steps 2 and 3 may be omitted if earlier submissions already contained the required information.
Early warning notification
- Whether the incident is suspected of being caused by unlawful or malicious acts
- The Member States in which the product has been made available (where applicable)
Incident notification (not required if already covered in step 1)
- General information about the nature of the incident
- Initial assessment of the incident
- Any corrective or mitigating measures taken
- Corrective or mitigating measures that users can take
- Level of sensitivity of the notified information
Final report (not required if already covered in earlier steps)
- Detailed description of the incident
- Its severity and impact
- The type of threat or root cause that is likely to have triggered the incident
- Applied and ongoing mitigation measures
Note: The deadline for the final report is one month from submission of the incident notification (step 2) — not from the date of becoming aware of the incident.
Part 3
To Whom Must Manufacturers Report?
When a reportable event occurs, manufacturers must notify three parties:
CSIRT designated as coordinator
The national CSIRT of the Member State where the manufacturer has its main EU establishment.
ENISA
European Union Agency for Cybersecurity. Receives all reports as a strategic coordination hub.
Impacted users
Must be informed directly, including available mitigation and corrective measures they can apply.
If a manufacturer fails to inform users in a timely manner, the CSIRT designated as coordinator is empowered to step in and provide the information directly to users — provided it considers this proportionate and necessary to prevent or mitigate impact.
How to Identify the CSIRT Designated as Coordinator
Manufacturers must notify the CSIRT designated as coordinator of the Member State where they have their main establishment in the Union (Art. 14(7)). For non-EU manufacturers this determination is not always straightforward. Use the tool below to find your answer.
CSIRT Finder — identify your designated coordinator
Do you have an establishment in the EU?
A map of all EU Member State CSIRTs is available at csirtsnetwork.eu .
The CRA Single Reporting Platform (SRP) — Where to Submit Reports
Manufacturers must notify their respective CSIRT and ENISA through the CRA Single Reporting Platform (SRP), currently under development by ENISA. It is expected to be operational by 11 September 2026.
Single submission
One notification simultaneously reaches the CSIRT designated as coordinator and ENISA.
Both event types
Handles both Actively Exploited Vulnerability (AEV) and Incident (INC) reports.
Country selection
Manufacturers select the EU Member States where the affected product is available.
Embargo option
Reports can be flagged for non-disclosure for a specified period, with justification (recital 71).
How to Report: Expected SRP Workflow
Since the Single Reporting Platform (SRP) is currently under development, the exact details of the reporting procedure are not yet confirmed. However, the technical specifications provided in ENISA's call for tenders give an indication of what to expect. Based on Annex I Part 2 Technical Specifications (Section 4 Main use-cases), we interpret the expected workflow as follows:
Part 4
How to Prepare Before September 2026
This is the part most manufacturers find surprising: there is very little to prepare for September 2026. Most of the report content can only be gathered after an event occurs — it is impossible to pre-fill a vulnerability report before discovering a vulnerability. Only two things can be prepared upfront:
Where your products are sold
Maintain a list of the EU Member States where each product has been made available. This is required in every detailed report and final report. You likely already have this information somewhere.
Which CSIRT to notify
Work through the decision logic above to determine your main EU establishment and identify the corresponding CSIRT designated as coordinator. This determination only needs to be done once.
That is genuinely it for September 2026. The energy you save here is better spent on what comes next — Article 13, which introduces the comprehensive product security and vulnerability handling requirements applying from December 2027.
Next: Article 13 compliance by December 2027
Article 13 is where the substantial compliance work lies. It requires manufacturers to implement comprehensive vulnerability handling processes, product security controls, and user documentation — all before placing products on the EU market from 11 December 2027.
Many manufacturers begin by conducting a CRA gap analysis to understand their current level of readiness. Zealience's Z-CMS includes a CRA gap analysis feature that supports this assessment — as well as a Vulnerability Handling Policy generator that produces an EN 40000-1-3-compliant policy document tailored to your organisation.
Frequently Asked Questions
Common questions about CRA Article 14, the September 2026 deadline, and what manufacturers must report.