Abstract network of blue nodes with one amber node highlighted, representing a zero-day vulnerability under NIS2

NIS2 Zero-Day Exploit: Why Discovery Doesn’t Start the 24-Hour Clock, and How Article 12 Coordinated Disclosure Actually Works

ByMichael Rewers

Google’s Threat Intelligence Group counted 90 zero-days exploited in the wild during 2025. Forty-three of them — 48%, an all-time high in both count and share — hit enterprise software and appliances rather than phones and browsers, and 21 of those targeted security and networking products, 14 of them edge devices [12]. Those are the boxes sitting at the perimeter of exactly the networks NIS2 regulates.

So the question is operational rather than academic. A researcher emails you, or your pen-test provider hands you a working exploit for something you run in production. Is the 24-hour clock running? Almost always, no — and the reason is a definition in the Directive, not a judgement call about severity.

A Zero-Day Is a Vulnerability Until Someone Uses It

In plain terms: NIS2’s reporting deadlines attach to incidents. A vulnerability is a different legal object, and the Directive attaches no deadline to it at all.

Article 6(15) of Directive (EU) 2022/2555 defines a vulnerability as “a weakness, susceptibility or flaw of ICT products or ICT services that can be exploited by a cyber threat” [1]. Article 6(6) defines an incident as “an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems.”

Free Download

Get the NIS2 Article 21 Compliance Checklist

90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.

✓ Check your inbox — the PDF is on its way.

The difference is a tense. One is a capability — something that can be exploited. The other is an event that has compromised something. Article 23(1) hangs the notification duty on “any incident that has a significant impact on the provision of their services.” Where there is no incident, Article 23 has nothing to bite on, no matter how alarming the CVSS score.

This is where a lot of published guidance goes wrong. Article 23(3) says an incident is significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss.” Some vendor material reads “capable of causing” as meaning a verified, weaponisable zero-day in critical infrastructure is significant by default. It is not. The phrase widens which incidents count as significant; it does not turn a vulnerability into one. You reach the Article 23(3) test only once an event under Article 6(6) has occurred.

There is a third state worth naming, because it is the one most zero-day situations actually land in. Article 6(5) defines a near miss as an event that “could have compromised” those same properties “but that was successfully prevented from materialising or that did not materialise.” A blocked exploitation attempt against an unpatched system is a near miss, not an incident. Article 23 does not require you to report it. Article 30 lets you report it anyway, and expressly protects you for doing so: “voluntary reporting shall not result in the imposition of any additional obligations upon the notifying entity to which it would not have been subject had it not submitted the notification” [1].

Four Scenarios, Four Different Obligations

Almost every zero-day question resolves into one of four fact patterns, and only two variables decide the regime: whether the flaw sits in something you use or something you sell, and whether anyone has actually exploited it.

Situation Legal characterisation What NIS2 requires
You discover, or are told about, an unpatched flaw in a product you operate. No evidence of exploitation. Vulnerability — Art. 6(15) No Article 23 notification. Handle it under Article 21(2)(e). Consider Article 23(2) if your service recipients are potentially affected. Article 30 voluntary notification available.
An exploitation attempt is detected and blocked before anything is compromised. Near miss — Art. 6(5) No mandatory notification. Voluntary notification under Article 30(1)(a), with the no-extra-obligations protection.
The flaw is successfully exploited against your systems. Incident — Art. 6(6) Apply the Article 23(3) significance test. If it passes: 24-hour early warning, 72-hour notification, final report one month after the notification.
A researcher reports a flaw in a product or service you manufacture or provide. Coordinated vulnerability disclosure — Art. 12 route Nothing under Article 23 unless your own systems are compromised. The national CSIRT coordinator is available as an intermediary. From 11 September 2026, CRA Article 14 may impose its own 24-hour clock.

The most commonly missed row is the first one — and specifically Article 23(2), which almost no guidance mentions. It obliges Member States to ensure that, where applicable, entities communicate without undue delay to recipients of their services who are “potentially affected by a significant cyber threat any measures or remedies that those recipients are able to take in response to that threat,” and, where appropriate, inform them of the threat itself [1]. A significant cyber threat is defined in Article 6(11) by its technical characteristics and its potential for severe impact. An unexploited but weaponisable zero-day in a system your customers depend on can meet that description while creating no Article 23(1) duty whatsoever. The obligation that fires is a customer-communication duty, not a regulator-notification duty — and it has no fixed deadline, only “without undue delay.”

What Article 12 Actually Obliges, and Who It Obliges

In plain terms: Article 12 builds national plumbing. It is addressed to Member States, and it places no duty on your organisation.

Read the operative words: “Each Member State shall designate one of its CSIRTs as a coordinator for the purposes of coordinated vulnerability disclosure” [2]. Every task that follows belongs to that CSIRT, not to you — identifying and contacting the entities concerned, assisting the person reporting a vulnerability, and “negotiating disclosure timelines and managing vulnerabilities that affect multiple entities” [1]. Member States must also let people report anonymously, and the coordinator must preserve that anonymity and carry out diligent follow-up. That is what makes the coordinator useful in the two cases you cannot handle alone: an unsolicited report from a researcher who will not identify themselves, and a flaw in a widely deployed third-party component that needs to reach every affected vendor at once. Where a vulnerability could significantly affect entities in more than one Member State, coordinators cooperate through the CSIRTs network.

The European vulnerability database created by Article 12(2) is frequently misdescribed as a reporting channel for new discoveries. It is not. The text confines it to disclosing and registering, “on a voluntary basis, publicly known vulnerabilities in ICT products or ICT services” [1]. ENISA’s database became operational on 13 May 2025 and aggregates description, affected products and severity, and patch or mitigation guidance [7][8]. Nothing in it creates a filing obligation for an unpublished zero-day.

So where does a Member State’s Article 12 policy actually reach into your own paperwork? Through Commission Implementing Regulation (EU) 2024/2690. Annex section 6.10.2 requires relevant entities to monitor vulnerability information through channels such as CSIRT and competent-authority announcements, to address vulnerabilities critical to their operations without undue delay, and — the clause that closes the loop — to “lay down a procedure for disclosing vulnerabilities in accordance with the applicable national coordinated vulnerability disclosure policy” [3]. One limit matters: the CIR binds only the eleven digital-provider categories listed in its Article 1 (DNS, TLD registries, cloud, data centres, CDNs, managed service and managed security service providers, marketplaces, search engines, social platforms, trust services). For everyone else it is an interpretive benchmark, while the underlying Article 21(2)(e) duty on vulnerability handling and disclosure applies regardless. Our guide to vulnerability management under CIR Annex 6 covers the patching side, and the vulnerability disclosure policy guide covers drafting the document itself.

The 90-Day Window That Is Not in the Directive

In plain terms: NIS2 sets no disclosure deadline. The 90-day figure people quote comes from industry practice, and the national coordinator you would actually deal with may run a much shorter clock.

Article 12(1)(c) makes “negotiating disclosure timelines” a coordinator task. Negotiation is the mechanism — there is no statutory default to fall back on. Recital 62, which is interpretive and non-binding, asks ENISA to establish a publication procedure that gives entities time to take mitigating measures, but attaches no number [1]. The practical windows come from elsewhere, and they disagree:

Source Default window Status
NIS2 Directive None Binding law, but silent — timelines are negotiated per case under Art. 12(1)(c)
CIRCL (Luxembourg CSIRT) 30 days from notification, extensions on justified request National CSIRT’s own published policy; on expiry without an acceptable response, CIRCL or the reporter publishes [5]
Centre for Cyber Security Belgium “within 90 calendar days at the latest”, to the extent possible National authority good practice, not a legal deadline [6]
Google Project Zero 90 days to patch, plus 30 days after the patch; 14-day grace to day 104 Industry practice; drops to 7 days where exploitation in the wild is evidenced [4]

The spread between 30 and 90 days is the point. If you build a disclosure SLA around the 90-day number because it is the one you have heard, and your national coordinator runs 30, you have designed a process that misses by two months. The Belgian guidance also carries a qualifier worth copying into your own policy: those deadlines “should be kept to the strict minimum if users of the affected systems are at risk or if there are risks to the protection of personal data” [6].

One caution for anyone planning to lean on researcher goodwill. Recital 60 encourages Member States to adopt guidelines on non-prosecution of security researchers and an exemption from civil liability — but it is a recital, it addresses Member States, and it creates no Union-wide safe harbour. The Belgian authority’s own guide is blunt that unauthorised intrusion “even with good intentions, is a criminal offence” [6]. Protection, where it exists, comes from national law and from the terms of your own published policy — not from NIS2.

When the Zero-Day Is in a Product You Make: CRA Article 14 from 11 September 2026

In plain terms: if you manufacture or brand software or connected products, a real 24-hour clock starts in September 2026 — and it is a different clock from the NIS2 one.

The Cyber Resilience Act, Regulation (EU) 2024/2847, applies in full from 11 December 2027, but Article 71 brings Article 14 forward to 11 September 2026 [11]. From that date, manufacturers must notify an actively exploited vulnerability in a product with digital elements to the CSIRT designated as coordinator and ENISA simultaneously: early warning within 24 hours, vulnerability notification within 72 hours, final report within 14 days after a corrective measure becomes available. A severe incident affecting product security follows the same 24- and 72-hour steps, with a final report one month after the notification. Manufacturers must also inform impacted users, and where they fail to, the CSIRT may do it for them [9].

What starts that clock is narrower than a CVE. Article 3(42) defines an actively exploited vulnerability as one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner” [10]. Publication alone is not exploitation, and proof-of-concept code is not evidence of exploitation in a live system.

Plan now for the dual-filing case. An organisation that is both an in-scope NIS2 entity and a manufacturer under Article 3(13) can face both regimes from a single event — a compromised update server, say, which is at once an incident affecting its own services and a security incident affecting a product it ships. Neither obligation displaces the other, and the tail ends diverge:

Step NIS2 Art. 23 (you as an entity) CRA Art. 14 (you as a manufacturer)
Trigger Significant incident affecting your services Actively exploited vulnerability, or severe incident affecting product security
Recipient National CSIRT or competent authority CSIRT coordinator and ENISA, simultaneously
Early warning 24 hours 24 hours
Notification 72 hours 72 hours
Final report One month after the 72-hour notification 14 days after a corrective measure is available (exploited vulnerability); one month (severe incident)

If you ship software to customers in the EU, map both paths before September. Our Cyber Resilience Act compliance guide and the software vendor obligations guide go into the manufacturer side in detail.

The First 24 Hours, by Role

The same zero-day produces genuinely different first moves depending on who you are.

CISO or IT security manager. Your first task is evidential, not administrative: establish whether exploitation occurred, because that single fact decides which regime applies. Pull authentication logs, privileged-activity logs and egress telemetry for the affected asset before containment destroys them. Under Article 11(3)(e) you can ask your national CSIRT for proactive scanning to detect vulnerabilities with potential significant impact [1] — a free capability most entities never use. If you cannot yet rule exploitation in or out, treat the incident path as live and the notification as pending rather than declining to report.

Compliance officer or legal counsel. Write down the classification and the reasoning at the time you make it, not afterwards. The record you want is: the date and source of the report, whether exploitation evidence existed, which Article 6 definition you applied, and what you did next. Where you decide not to notify, that reasoning is the evidence that the decision was made rather than missed. Consider Article 23(2) separately from Article 23(1) — the customer-communication duty can fire when the regulator-notification duty does not. And note that Article 23(1) states expressly that “the mere act of notification shall not subject the notifying entity to increased liability” [1], which removes the usual argument for staying silent.

SME owner or non-technical decision-maker. Establish whether anyone actually got in — that is the fact that changes your legal position — and find out who your national CSIRT coordinator is before you need them. Article 23(5) obliges the CSIRT to respond to an early warning within 24 hours with initial feedback and, on request, operational advice on mitigation, including guidance on reporting to law enforcement where a criminal act is suspected [1]. Filing early buys you technical help you would otherwise pay for. Penalties under Article 34 reach €10 million or 2% of worldwide turnover for essential entities and €7 million or 1.4% for important entities, whichever is higher — but they attach to failures of the Article 21 and 23 duties, not to having had a vulnerability.

Frequently Asked Questions

Does a critical CVE in software we run have to be reported within 24 hours? No. A published vulnerability in a product you operate is a vulnerability under Article 6(15), not an incident under Article 6(6), so Article 23’s clock does not start. Your duty is to handle it under Article 21(2)(e) and, where the CIR applies to you, in line with Annex 6.10 and 6.6.

We blocked an exploitation attempt. Is that reportable? Not mandatorily. A prevented compromise is a near miss under Article 6(5). Article 30 allows a voluntary notification, and protects you from picking up additional obligations by making it.

Can we submit a zero-day to the European vulnerability database instead of telling the vendor? No. Article 12(2) confines the database to publicly known vulnerabilities, submitted voluntarily. An undisclosed flaw belongs in a coordinated disclosure process through the vendor or your national CSIRT coordinator.

Is 90 days the legal disclosure deadline in the EU? No. NIS2 sets no deadline; Article 12(1)(c) makes disclosure timelines a matter for negotiation via the coordinator. National coordinators publish different defaults — 30 days at CIRCL in Luxembourg, 90 calendar days as good practice in the Belgian authority’s guide.

We are an essential entity and we also sell a SaaS product. Which regime applies? Potentially both, from 11 September 2026. NIS2 Article 23 covers incidents affecting your own service provision; CRA Article 14 covers actively exploited vulnerabilities and severe incidents in the product you place on the market. Build one detection process feeding two notification paths with different final-report deadlines.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

Free Download

Get the NIS2 Article 21 Compliance Checklist

90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.

✓ Check your inbox — the PDF is on its way.

Don't miss: