CRA Article 14 requires manufacturers to notify ENISA of actively exploited vulnerabilities within 24 hours. Learn the full 24h/72h/14-day workflow and what must be operational by 11 September 2026.
The short answer
CRA Article 14 requires manufacturers of products with digital elements to notify ENISA — via their national competent authority — within 24 hours of becoming aware of an actively exploited vulnerability in their product. A 72-hour technical report follows, then a 14-day final report. This obligation applies from 11 September 2026, more than a year before full CRA enforcement in December 2027.
Why Article 14 matters more than the 2027 deadline
The full CRA enforcement date is 11 December 2027. But Article 14 creates an earlier hard deadline:
"Manufacturers shall, without undue delay and in any event within 24 hours of becoming aware of it, notify any actively exploited vulnerability contained in the product with digital elements to ENISA."
— CRA Art. 14(1)
Article 14 becomes applicable on 11 September 2026 (36 months after entry into force minus the 12-month delay on vulnerability reporting obligations under Art. 71). If your product has network connectivity and is placed on the EU market, you need a documented, tested notification workflow before that date.
Stage 1 — Early warning (within 24 hours)
Trigger: You become aware that a vulnerability in your product is actively being exploited in the wild.
What to submit:
Where: ENISA single reporting platform → your national competent authority (MSA) forwards to ENISA. In practice, use your national MSA's incident reporting portal until the ENISA platform is operational.
Note: The 24-hour clock starts when your organisation becomes aware — not when a CVE is published or a researcher reports it. Your internal triage process must have a defined "awareness moment" trigger.
- Product identification (name, version, CPE or PURL if available)
- Nature of the vulnerability (brief description — no full technical detail required at this stage)
- Whether the vulnerability affects other products (cross-component impact)
- Initial assessment of severity
Stage 2 — Intermediate report (within 72 hours)
Trigger: 72 hours after initial awareness.
What to submit:
Format: Structured report via national MSA portal. ENISA will publish a standardised template; until then, follow your national authority's format.
- Updated severity assessment (CVSS v3.1 or v4.0 score + vector)
- Affected versions and configurations
- Initial mitigation available (yes/no; patch status)
- Whether exploitation has been observed in your customer base
Stage 3 — Final report (within 14 days)
Trigger: 14 days after initial awareness (or later if the vulnerability is still being handled, with justification).
What to submit:
After submission: The vulnerability enters the European Vulnerability Database (EVDB), operated by ENISA under Art. 12.
- Full technical description of the vulnerability
- Root cause analysis
- Patch or mitigation status
- Disclosure timeline (coordinated or unilateral)
- Lessons learned / process improvements
What must be operational by 11 September 2026
| Requirement | Description |
|---|---|
| CVD policy | A public coordinated vulnerability disclosure policy with a contact channel, acknowledgement process, and triage timeline |
| Internal triage process | A documented process defining who is responsible, what "awareness" means, and how the 24h clock is started |
| ENISA notification workflow | A tested process for submitting 24h/72h/14-day reports via your national MSA |
| Designated responsible person | At least one named individual (with backup) responsible for receiving vulnerability reports and initiating notifications |
| Logging and evidence | Records of all notifications submitted (timestamp, content, recipient) for audit purposes |
You do not need a patch available to submit the 24-hour early warning. The notification is independent of remediation status.
Relationship to NIS2 incident notification
CRA Art. 14 and NIS2 Art. 21 both require incident/vulnerability notification, but to different recipients:
| | CRA Art. 14 | NIS2 Art. 21 |
|---|---|---|
| Subject | Actively exploited vulnerability in a product | Significant incident affecting service continuity |
| Recipient | ENISA (via national MSA) | National CSIRT + NCA |
| 24h deadline | ✅ Early warning to ENISA | ✅ Early warning to CSIRT |
| Final report | 14 days | 1 month |
If you are dual-regulated (both a manufacturer under CRA and an essential/important entity under NIS2), you must run both notification tracks in parallel for qualifying events. See NIS2 × CRA overlap.
CVD policy: minimum required elements
Before 11 September 2026, your CVD policy must include at minimum:
ENISA publishes a CVD guidance document; CRA Annex I Part II §1 sets the minimum requirement.
- Public contact channel — a dedicated email address or web form (e.g. security@yourcompany.com) listed on your website and in your product documentation
- Acknowledgement commitment — you will acknowledge receipt within a defined period (typically 5 business days)
- Triage timeline — you will assess severity and respond with an initial verdict within a defined period (typically 30 days)
- Disclosure timeline — you will coordinate disclosure with the reporter and publish within a defined period (typically 90 days), or provide a justified extension
- Safe harbour statement — good-faith researchers acting under your CVD policy will not face legal action
SBOM and Article 14
Your SBOM directly supports the 24-hour notification process:
Integrating SBOM generation into your release pipeline — rather than producing it on demand — is the only sustainable approach to meeting the 24h notification timeline in practice.
- An up-to-date SBOM allows you to identify affected versions and configurations quickly
- A machine-readable SBOM (SPDX 2.3+ or CycloneDX 1.5+) enables automated vulnerability matching against known CVEs
- Without a current SBOM, the 24-hour deadline creates severe operational pressure
What NexCyber provides
→ Start your CRA gap assessment
→ CRA Scope Checker — confirm applicability
- Gap assessment — maps your current CVD, SBOM, and notification workflow against CRA Art. 14 requirements (144-obligation assessment)
- CVD policy template — draft policy aligned with ENISA guidance and CRA Annex I
- ENISA workflow documentation — internal runbook template for the 24h/72h/14-day process
- MRCC — Machine-Readable Compliance Certificate issued when your readiness evidence is collected and verified
Further reading
This page provides regulatory guidance for informational purposes. It is not legal advice. CRA implementation details may change as delegated acts and ENISA guidance are published. For compliance decisions, consult the applicable national competent authority or a qualified legal adviser.
NexCyber — EU Market Access Compliance Platform
- NIS2 × CRA overlap — dual compliance programme
- SBOM requirements under CRA Annex I
- CRA regulations overview
This is an educational explainer. For the canonical regulation reference, see the dedicated CRA page — or run an assessment to see how it applies to your product.