Zero-Day Vulnerability
A zero-day vulnerability is a security flaw that is unknown to the vendor and for which no patch exists at the time of discovery or exploitation. Zero-day vulnerabilities are particularly significant under the CRA because their active exploitation triggers immediate notification obligations to ENISA within 24 hours.
A zero-day vulnerability is a security flaw that is unknown to the vendor and for which no patch exists at the time of discovery or exploitation. Zero-day vulnerabilities are particularly significant under the CRA because their active exploitation triggers immediate notification obligations to ENISA within 24 hours.
Technical SecurityWhat Is a Zero-Day Vulnerability?
A zero-day vulnerability (often written 0-day) is a security flaw in software, firmware, or hardware that is unknown to the party responsible for patching it - the vendor has had 'zero days' to fix it. The term encompasses several related concepts: a vulnerability that is unknown to the vendor, a vulnerability for which a public exploit exists before a patch, and a vulnerability being actively exploited in the wild before any fix is available. These situations often overlap. Zero-days are highly valuable to attackers because defenders have no patch to deploy and must rely on mitigations such as network segmentation, WAF rules, or temporary feature disablement.
Zero-Days and CRA Notification Obligations
Article 14 of the CRA establishes a 24-hour notification requirement when a manufacturer becomes aware that a vulnerability in its product is actively exploited. An actively exploited zero-day is the paradigm case for this obligation. The notification must go to ENISA and the relevant national CSIRT. Within 72 hours, the manufacturer must submit a full vulnerability notification with preliminary findings, and a final report within 14 days. This notification cascade is designed to allow CSIRTs to warn other organisations using the same product. Manufacturers must establish internal processes to detect and escalate zero-day information - including monitoring threat intelligence feeds and maintaining contact with sector-specific ISACs.
Responding to a Zero-Day in Your Product
When a zero-day affecting your product is identified, the response sequence is:
- Confirm and isolate - validate that the vulnerability is real and assess the exploit's reach and reliability.
- Classify - determine CVSS Base Score and assess active exploitation status.
- Notify - if actively exploited, trigger the Article 14 notification to ENISA/CSIRT within 24 hours.
- Develop a mitigation - if a full patch is not immediately available, identify and publish interim mitigations (firewall rules, configuration changes, workarounds).
- Develop and test the patch - prioritise over normal release cycles; consider an out-of-band security release.
- Publish a CSAF advisory - disclose the vulnerability, its severity, and remediation steps.
Zero-Day vs. N-Day: Risk Prioritisation
An N-day vulnerability is one where a CVE and patch exist but systems remain unpatched. In practice, N-days are often more operationally dangerous than zero-days because:
- Exploit code is typically available shortly after CVE publication.
- Most organisations have large unpatched backlogs.
- Attackers systematically scan for unpatched systems using CVE data.
For CRA compliance, manufacturers must address both: zero-days trigger immediate notification; N-days require timely patch releases and advisory publication. The CISA Known Exploited Vulnerabilities (KEV) catalogue is a useful operational signal for identifying N-days with confirmed active exploitation that may also trigger Article 14 notification obligations.
CVD Portal makes Zero-Day Vulnerability compliance straightforward.
Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Receiving and tracking reports is free for all manufacturers placing products with digital elements on the EU market. Article 14 filing with the SRP-ready package is on Pro.
Start your free portalFrequently asked
Does discovering a zero-day in our own product require us to notify ENISA?+
Article 14 notification is triggered by active exploitation, not discovery. If you discover an unpublished vulnerability in your product internally and it is not being actively exploited, you are not required to notify ENISA - you must fix it without undue delay per Article 13. If you discover that the same vulnerability is being actively exploited in the wild, the 24-hour notification clock starts immediately.
What counts as 'actively exploited' under the CRA?+
The CRA does not provide a precise technical definition of 'actively exploited'. In practice, regulators and ENISA treat a vulnerability as actively exploited when there is credible evidence of real-world exploitation - such as threat intelligence reports, CSIRT alerts, CISA KEV listing, customer incident reports, or observed malware using the vulnerability. Theoretical exploitability (even a working PoC without confirmed wild exploitation) does not alone meet the threshold.
Can we delay public disclosure of a zero-day while we develop a patch?+
Yes, limited delay is expected and appropriate. Coordinated vulnerability disclosure norms allow a vendor to request that a researcher hold back public disclosure while a patch is developed - typically up to 90 days. However, if the vulnerability is actively exploited during this period, the ENISA notification obligation takes precedence. Manufacturers should publish mitigations as soon as they are available even if a full patch is not yet ready.
Related terms
Sector checklists covering Zero-Day Vulnerability
Browse the full CRA Compliance Checklist
See how Zero-Day Vulnerability fits into your complete CRA compliance programme.