What Article 14 Requires
Article 14 imposes mandatory notification obligations on manufacturers of products with digital elements. If you discover an actively exploited vulnerability or a severe incident affecting your product, you must notify the relevant national CSIRT — and through them, ENISA — within strict deadlines.
When Does This Apply?
- Actively exploited vulnerabilities in your product (Article 14(1))
- Severe incidents with impact on the security of your product (Article 14(3))
- Reporting starts: 11 September 2026 (earlier than the full CRA date of December 2027)
Key Deadline: September 2026
Reporting obligations under Article 14 apply from 11 September 2026 — over a year before the full CRA compliance deadline of December 2027. You need reporting infrastructure in place by then regardless of your product's overall CRA readiness.
The 3-Stage Notification Process
Reporting is not a single event — it is a structured 3-stage process with different deadlines and different information requirements at each stage.
Stage 1: Early Warning
Submit an early warning to your national CSIRT within 24 hours of becoming aware of an actively exploited vulnerability or severe incident.
What to include:
- Indication that an actively exploited vulnerability or incident has occurred
- Whether the incident is suspected to be caused by unlawful or malicious activity
- Product name and version(s) affected
- Initial assessment of severity (where available)
Note: At 24 hours you may not have full information — a partial early warning is acceptable and expected. The purpose is to alert authorities promptly, not to provide a complete technical analysis.
Stage 2: Vulnerability / Incident Notification
Submit a full notification within 72 hours of becoming aware. This replaces the early warning with more complete information.
What to include:
- Updated severity assessment and initial impact analysis
- Indicators of compromise (if available)
- Status of the fix / mitigation (in progress, available, not yet started)
- Any affected users or other products that may be impacted
- Whether the vulnerability is already publicly known
- Any corrective measures already taken or underway
Stage 3: Final Report
Submit a final report no later than 14 days after a fix or mitigation is available, or — where the issue is not resolved — as soon as practicable with a progress update.
What to include:
- Detailed description of the vulnerability or incident
- Severity level (using CVSS or equivalent scoring)
- Root cause analysis (if complete)
- Fix / patch / mitigation details and how users will receive it
- Corrective and preventive actions taken
- Cross-border impact where relevant
- Reference to any CVE ID assigned
If unresolved at 14 days: Submit a progress report and agree an updated timeline with your national CSIRT. The 14-day clock starts when the fix is available, not from initial awareness.
Reporting Timeline at a Glance
You become aware of an actively exploited vulnerability or severe incident. The clock starts now.
Submit initial alert to national CSIRT via ENISA Single Reporting Platform. Partial information is acceptable.
Submit detailed notification with severity assessment, impact, and status of fix.
Once a patch or mitigation is available, the 14-day final report window opens.
Submit full final report with root cause analysis, fix details, and preventive actions.
Who Do You Notify? The ENISA Single Reporting Platform
Submit once through the ENISA Single Reporting Platform. The designated national CSIRT initially receives the notification, while ENISA receives it simultaneously; relevant CSIRTs in other Member States can receive it through the platform's dissemination flow.
Step 1: Identify Your National CSIRT
You must notify the CSIRT of the EU Member State where your company is established (i.e., where your legal entity is registered for EU purposes).
If you are established in multiple Member States, you may notify the CSIRT of the Member State where your principal establishment is.
Non-EU manufacturers: Notify via your EU Authorized Representative's Member State CSIRT. See Authorized Representative guide →
Step 2: Use the Single Reporting Platform
ENISA has published official registration and notification guidance for the Single Reporting Platform. Assigned Representatives authenticate with EU Login, select the designated CSIRT, and submit each notification through the SRP.
ENISA advises registering when you need to submit a specific notification rather than creating an account pre-emptively. CSIRT validation of the representative can continue in parallel and does not block submission.
What Information Is Transmitted to ENISA?
Your national CSIRT forwards relevant notification information to ENISA. ENISA may share non-sensitive technical details with other EU CSIRTs (the CSIRT Network) to facilitate coordinated response across Member States. Commercially sensitive information you provide is protected under confidentiality obligations.
Notifying Affected Users (Article 14(8))
In addition to notifying authorities, Article 14(8) requires you to inform users of your product who may be affected and provide them with mitigation guidance where needed.
Notify Affected Users
Inform users that a vulnerability or incident has been identified that may affect the security of their product/device.
Provide Mitigation Guidance
Tell users what they can do to protect themselves — apply update, change settings, restrict usage — until a permanent fix is available.
Deliver the Fix
Provide a security update without undue delay once available. Update delivery must reach users clearly and without requiring manual steps where possible.
What Does and Does Not Trigger Reporting
Triggers Reporting
- Vulnerability in your product that is actively exploited in the wild
- Security incident that has a significant impact on the security of your product (e.g., a breach of your update delivery pipeline, compromise of your build environment)
- Incident caused by your product that impacts critical infrastructure or essential services
Does NOT Trigger Reporting
- Vulnerabilities discovered internally or via responsible disclosure that are not yet exploited
- General security research findings with no active exploitation
- Minor bugs or issues with no security impact
- Vulnerabilities in third-party components you don't control (unless actively exploited in your product's context)
Voluntary Reporting (Article 15)
Manufacturers may voluntarily report non-exploited vulnerabilities and incidents under Article 15 using the same platform. Voluntary reports are encouraged and may help demonstrate a proactive security posture to authorities, but are not mandatory.
Building the Internal Reporting Process
Meeting the 24-hour early warning deadline requires having processes already in place before a vulnerability is discovered. You cannot build a notification workflow from scratch in 24 hours.
Establish a PSIRT or Equivalent Function
A Product Security Incident Response Team (PSIRT) is the internal function responsible for receiving, triaging, and coordinating response to vulnerabilities. CRA doesn't mandate the name, but the function is required by Article 13(5).
PSIRT Obligations Checklist →Register With Your National CSIRT
Contact your national CSIRT before an incident occurs to understand the local submission process, portal URL, required formats, and contact details. Do not wait until you have an incident to set up the reporting channel.
Define Internal Escalation Triggers
Document criteria internally for what constitutes "active exploitation" or a "severe incident" so your team can make the reporting decision quickly under pressure, without ambiguity.
Prepare Notification Templates
Draft and store blank templates for each stage (24h, 72h, 14-day reports) so that under incident conditions your team fills in fields, not writes from scratch.
Incident Reporting Guide & Templates →Special Provisions for Small Businesses (Article 14(10))
Article 14(10) provides limited exceptions for microenterprises and small and medium-sized enterprises (SMEs) in relation to the format and submission requirements for Article 14(2)(a) early warnings and Article 14(4)(a) notifications.
These exceptions are procedural (e.g., format flexibility) rather than substantive — SMEs are still required to report and still bound by the same deadlines. The European Commission will publish guidance on how SME exceptions apply in practice.
Check if your company qualifies as an SME or microenterprise under EU definitions.
CRA for Startups & SMEs →Related Tools and Guidance
Incident Reporting Guide
Step-by-step workflow tool for managing the 3-stage reporting process with deadline calculator.
PSIRT Checklist
51-item checklist of PSIRT obligations under CRA to ensure your response function is compliant.
Vulnerability Management
CVD policies, responsible disclosure, and the full vulnerability handling lifecycle.
Authorized Representative
Non-EU manufacturers: how to appoint an EU authorized representative for reporting purposes.
Article 13 Overview
Full picture of manufacturer obligations including Article 14 reporting in context.
Penalties
Failure to report as required by Article 14 carries penalties up to €10M or 2% global turnover.