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.
A note on misleading advice. You may hear that "vulnerability handling obligations start from September 2026" or that manufacturers must have a coordinated vulnerability disclosure (CVD) policy and SBOM-driven monitoring in place by that date to comply with Article 14. These claims conflate two distinct provisions of the CRA.
Article 14(1) and 14(3) trigger reporting obligations on the condition that a manufacturer "becomes aware of" an actively exploited vulnerability or severe incident. The Article itself contains no duty to publish a CVD policy, maintain an SBOM, or actively monitor for vulnerabilities. Those obligations exist — but they sit in Article 13 and Annex I Part II, which apply from 11 December 2027.
To be fair to the practical argument: having some intake channel and watching feeds like CISA KEV is operationally sensible, and it helps manufacturers actually operationalise Article 14 reporting when an event occurs. We recommend it. But there's a difference between what is sensible practice and what is legally mandated by Article 14 from September 2026 — and the regulation only goes as far as making it sensible practice, not a legal requirement.
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.
CSIRT and ENISA are notified through a single submission
Manufacturers do not submit separate reports to CSIRT and ENISA. Both are reached through one submission via the ENISA Single Reporting Platform (SRP). The SRP automatically routes the report to the CSIRT designated as coordinator and to ENISA simultaneously.
Notifying impacted users
Article 14 does not specify a deadline for notifying users, nor does it prescribe a format. However, several points 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
Article 14 does not mandate upfront preparation. What it mandates is reporting — specific information, within specific deadlines, when an actively exploited vulnerability or severe incident occurs. Most of that information is about the event itself, which means most of it cannot be gathered in advance. You cannot pre-fill a vulnerability report for a vulnerability you haven't discovered.
What manufacturers should do before September 2026, therefore, is not a compliance checklist but a readiness check:
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.
Neither of these is mandated by Article 14 as an upfront obligation. They are the minimum groundwork that lets a manufacturer actually meet the Article 14 deadlines when they apply. 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.
Resource
Download the One-Pager
We have summarised the Article 14 reporting obligations on a single printable page — both triggers, the 24h / 72h / final-report timelines, the information required at each step, and the parties to notify. It is designed to be kept on hand by the team that will handle a qualifying event, so they can act quickly without reading the regulation under time pressure.
Download it, print it, and fill in two fields by hand: your CSIRT designated as coordinator (use the CSIRT Finder above to determine it), and the EU Member States where your product has been made available. Then store it somewhere your incident response team will find it when they need it.
Summary One-Pager
Print or save as PDF for a quick reference of your CRA Article 14 obligations.
ENISA
Impacted users
- Member States where the product has been made available
- General information about the product concerned
- General nature of the exploit and the vulnerability
- Any corrective or mitigating measures taken
- Corrective or mitigating measures that users can take
- Level of sensitivity of the notified information
- Description of the vulnerability
- Its severity and impact
- Information concerning any malicious actor (if available)
- Details about the security update or corrective measures made available
- Whether the incident is suspected of being caused by unlawful or malicious acts
- Member States where the product has been made available (where applicable)
- 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
- Detailed description of the incident
- Its severity and impact
- Type of threat or root cause likely to have triggered the incident
- Applied and ongoing mitigation measures
Note: This one-pager reflects Article 14 as of the date shown in the footer. If the CRA introduces changes, the content may become outdated.
Frequently Asked Questions
Common questions about CRA Article 14, the September 2026 deadline, and what manufacturers must report.