Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How do you handle a zero-day vulnerability?
Last verifiedHandling a zero-day is emergency triage: mitigate now, patch, or isolate, chosen by whether a fix exists and whether exploitation is confirmed. Confirmed exploitation hands off to incident response, not just to vulnerability management. Not legal advice; does not start a reporting clock.
Zero-day and actively-exploited vulnerability handling, last verified 10 September 2026, against CISA's Known Exploited Vulnerabilities (KEV) catalog and emergency directives and advisories, NIST SP 800-61 Revision 3 (April 2025, the current final revision, superseding Revision 2), FIRST EPSS, and vendor security advisories. It is not legal advice, does not determine that any legal reporting duty applies to YOU, and does not start a clock.
This is emergency triage, not YOUR incident response plan
Audience: a CISO, incident commander, or on-call engineer who just learned about a zero-day or a newly weaponized CVE affecting something they run. This page is not legal advice. It does not run YOUR triage, does not decide that YOUR organization has a legal reporting duty, and does not start a reporting clock. If exploitation against YOUR systems is confirmed or suspected, this page hands off to incident response rather than trying to be one.
A zero-day, in common usage, is a vulnerability being exploited, or for which exploit code is public, before or without a vendor patch being generally available. 'Newly weaponized' extends the same urgency to a CVE that already had a patch but just gained a public working exploit. Either way, the response question changes: this is not 'when should we schedule the fix,' it is 'what do we do in the next few hours.' Last verified 10 September 2026.
- Best practice versus a legal reporting trigger: CISA KEV entries and emergency directives are CISA guidance for most organizations, binding only on U.S. federal civilian executive branch agencies under Binding Operational Directive 26-04 (issued 10 June 2026, which revoked and replaced BOD 22-01 the same day). Whether YOUR organization also has a separate legal reporting duty — under a breach-notification statute, a sector regulator, or a contract — is a different question this page does not answer. See the incident-response and breach-reporting docs hubs on this site for that separate track.
- The what-is-KEV, how-to-prioritize-vulnerabilities, and remediation-SLAs guides on this site are live. A dedicated program-checklist, vulnerability-vs-exploit-vs-risk, CVE-vs-CWE-vs-CVSS, exploitability-vs-severity, remediation-timeframes, detect-vulnerable-open-source-packages, prove-remediation, track-accepted-risk, and how-ShipReadyMetrics-prioritizes-risk guide either ships alongside this page or is not on this site yet; naming any that are not yet live is not a link.
- This page does not restate incident-response procedure. The incident-response docs hub on this site is the live IR cluster, and the we've-been-breached guide on this site is the live first-response page. Read those for the response itself; this page is the vulnerability-management entry point into that handoff.
Emergency decision tree: mitigate now, patch, or isolate
The table below is an accessible decision aid — three columns, no diagram widget — for the first triage call on a zero-day or newly weaponized CVE. It is a starting framework, not YOUR incident commander's decision, and answering a row is not a determination that any specific action is required or sufficient for YOUR situation. Last verified 10 September 2026. Not legal advice.
| Situation observed | Likely first move | Why | What this page does not do |
|---|---|---|---|
| A vendor patch exists and the asset can be taken down for maintenance without unacceptable disruption. | Patch, on an emergency change window rather than the normal cycle. | A real fix beats a workaround once one exists. Emergency doesn't mean skip your rollback plan. | Does not pick YOUR maintenance window or approve YOUR change. |
| No patch is available yet, but a vendor or CISA advisory names a specific mitigation (a config change, a WAF rule, disabling a feature). | Mitigate now using the documented workaround, then patch when one ships. | A documented mitigation closes the specific exploited path faster than waiting for a full fix, and with less disruption than isolation. | Does not validate that the workaround fully closes the path for YOUR configuration. |
| No patch and no documented mitigation exist, and the asset is internet-facing or otherwise highly exposed. | Isolate: take the asset off the exposed network path, behind additional access controls, or offline, until a fix or mitigation exists. | When there is nothing to apply, removing exposure is the only lever left that doesn't just hope the exploit isn't used against you. | Does not decide whether isolation is operationally feasible for YOUR system, and does not perform the isolation. |
| Exploitation against YOUR own systems is confirmed or reasonably suspected, regardless of which column above applies. | Hand off to incident response immediately, in parallel with any patch, mitigation, or isolation action. | A confirmed or suspected compromise is an incident, not a pending vulnerability. Response and forensic activity now run alongside remediation. | Does not run YOUR incident response. The we've-been-breached guide on this site is the live first-response page. |
| The affected component is present but not on the KEV catalog and exploitation against anyone, including YOU, is unconfirmed. | Mitigate or patch on an accelerated, but not necessarily emergency, timeline; monitor for KEV addition and exploitation reports. | Absence from KEV is not evidence of safety — KEV is a lagging indicator — but it does change the urgency calculus versus confirmed exploitation. | Does not tell YOU when the urgency threshold is crossed; that call belongs to a named owner. |
Best practice versus a legal reporting trigger — do not conflate them
Handling a zero-day well and having a legal duty to report an incident are two different questions running on two different clocks. Mitigating, patching, or isolating an affected asset is operational best practice regardless of what, if anything, a statute requires. Whether the underlying event also triggers a breach-notification law, a sector regulator's reporting rule, or a contractual disclosure obligation is a separate legal question this page does not answer and does not start a clock on. Last verified 10 September 2026. Not legal advice.
If a zero-day response escalates into a confirmed compromise involving unauthorized access to data, walk the reporting-obligation material on this site's breach-reporting and incident-response clusters rather than trying to infer a reporting duty from this page. This page's cross-reference to those clusters is a handoff, not a restatement of their content.
- Best practice: patch, mitigate, or isolate promptly; document the decision and the timeline; monitor CISA KEV and vendor advisories for updates.
- Legal reporting trigger, if any: a separate determination under whichever breach-notification statute, sector regulation, or contract may apply to YOUR facts — not something this page or a fast mitigation response decides.
- Do not treat 'we mitigated it fast' as evidence that no reporting duty exists, and do not treat 'we have a reporting duty' as a reason to delay mitigation. They are independent tracks that can both be true at once.
- If a sector-specific regulator or a contract sets its own timeline, that timeline runs independently of any general best-practice guidance named on this page.
KEV and emergency directives versus your own monitoring
CISA's Known Exploited Vulnerabilities (KEV) catalog adds a CVE once there is reliable evidence of active exploitation. Binding Operational Directive 26-04, issued 10 June 2026, requires U.S. federal civilian executive branch agencies to remediate KEV catalog entries on a risk-based schedule; it superseded and revoked BOD 22-01's flat remediation timelines the same day. For organizations outside that mandate, KEV is a strong, publicly available prioritization signal, not a binding directive. This page does not restate the specific day-counts in BOD 26-04's remediation tiers; consult the directive itself for those figures, because they vary by risk factors CISA defines and are outside the scope of a vendor-neutral explainer. Last verified 10 September 2026. Not legal advice.
CISA also issues emergency directives and advisories outside the standard KEV cadence for the most severe, actively exploited situations — these carry their own scope and deadlines, distinct from the general KEV catalog additions. Treat any such directive or advisory as authoritative for its own scope; this page does not reproduce directive-specific deadlines.
- KEV presence: strong evidence to act now. KEV absence: weak evidence, not proof of safety — it lags observed exploitation.
- FIRST EPSS supplements KEV for vulnerabilities not yet confirmed exploited, estimating a probability of exploitation in the near term rather than a confirmed fact.
- A CISA emergency directive or advisory, when one is issued for a specific event, supersedes general guidance for its own scope. This page does not track or reproduce any specific directive's deadlines.
- Vendor security advisories for the specific affected product are often the fastest source of a documented workaround, and should be checked alongside CISA material rather than instead of it.
Document the decision — a timeline an auditor or a post-incident review will ask for
Whatever the first move is, write it down at the time, not from memory afterward. The table below is a minimal record for a zero-day response, not a substitute for your incident-management tooling. Last verified 10 September 2026. Not legal advice.
| Field | What it captures |
|---|---|
| First awareness | When and how the organization first learned of the zero-day or newly weaponized CVE — an advisory, a KEV addition, or internal detection. |
| Exposure assessment | Which assets were checked for the affected component, and by what method — blast radius, manual inventory review, or a scanner sweep. |
| Decision and rationale | Which of mitigate, patch, or isolate was chosen for each affected asset, and why — tied to the decision-tree table above where it applies. |
| Escalation, if any | Whether the situation was handed off to incident response, and when — the trigger being confirmed or suspected exploitation, not merely the existence of the vulnerability. |
The incident-response handoff — cross-referenced, not restated
This page does not walk the incident-response playbook. The incident-response docs hub on this site is the live cluster for that work, and the we've-been-breached guide on this site is the live entry point for a confirmed or suspected compromise. If triage on a zero-day surfaces evidence that an attacker actually used it against YOUR systems, that evidence moves the situation into that cluster's process, in parallel with — not instead of — patching, mitigating, or isolating the vulnerability itself. Last verified 10 September 2026. Not legal advice.
The handoff signal is evidence of actual or suspected compromise, not merely the existence of an unpatched zero-day. A vulnerable, unpatched, and never-yet-exploited-against-you asset stays a vulnerability-management problem until there is a reason to believe otherwise.
What to do now
The list below is operational preparation, not a determination of what YOUR specific situation requires. Walk it with your incident commander and, where a reporting question arises, with counsel. Last verified 10 September 2026. Not legal advice.
- Confirm whether a vendor patch, a documented mitigation, or neither is currently available, and use the decision-tree table above as a starting frame, not a final answer.
- Check the CISA KEV catalog and any CISA emergency directive or advisory for the specific CVE; treat KEV presence as strong evidence to act and KEV absence as inconclusive, not as safety.
- If exploitation against YOUR own systems is confirmed or reasonably suspected, open the incident-response process now, in parallel with any technical mitigation. See the we've-been-breached guide on this site.
- Document the decision and its timeline: what was known, what action was taken, and when — this record is the evidence a later audit, review, or reporting determination will look for.
- Do not treat a fast technical response as a substitute for the separate legal-reporting question, and do not treat that separate question as a reason to delay technical mitigation.
Where this shows up in ShipReady Metrics
If you already have a session: signed-in app → Security → Findings flags findings that appear on the CISA KEV catalog so a confirmed-exploited component surfaces above a purely severity-sorted list, alongside FIRST EPSS enrichment for components not yet on KEV. Signed-in app → Security → Blast radius can help scope exposure quickly for a named package, from npm lockfiles resolved transitively when the GitHub scan fetched them; other ecosystems and unresolved npm repositories remain what the manifest declares. First-party SAST and DAST findings, where those scanners are connected, can help validate whether a specific code path or endpoint is exposed.
None of that is emergency-response automation. This product does not apply patches, does not isolate assets, does not declare an incident, and does not file with CISA, a market-surveillance authority, or any other regulator. A named human still owns the mitigate-now, patch, or isolate decision, and a named human still owns the incident-response handoff. This page does not document a public demo URL.
Primary sources (last verified 10 September 2026)
Every claim on this page is taken from one of these. If a later revision of a source changes the rule, the date above is how you can see we have not re-checked yet.
CISA's Known Exploited Vulnerabilities (KEV) catalog and CISA emergency directives and advisories are CISA materials: Binding Operational Directive 26-04 (issued 10 June 2026) is a legal requirement for U.S. federal civilian executive branch agencies and superseded and revoked BOD 22-01 the same day; the KEV catalog itself is guidance for everyone else. NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025), is the current final NIST incident-handling publication and formally superseded Revision 2 (2012); it is guidance, not law, unless a policy or contract adopts it. FIRST's Exploit Prediction Scoring System (EPSS) publishes a daily exploitation-probability score, guidance and data, not law. Vendor security advisories are each vendor's own material for its own product. These are not a complete world list. Not legal advice.
The what-is-KEV, how-to-prioritize-vulnerabilities, and remediation-SLAs guides on this site are live. The incident-response docs hub and the we've-been-breached guide on this site are live. A dedicated handle-zero-day-specific IR sibling beyond those two pages is not on this site. Naming any HC11 sibling not yet live is not a link.