How should you respond to a zero-day vulnerability?

A zero-day is a flaw being exploited, or ready to be, before a fix exists. Respond in this order: find every place you run the affected software, reduce its exposure, watch for signs of exploitation, apply vendor mitigations, then patch as soon as a fix ships, starting with internet-facing systems.

What makes a zero-day different?

There is no patch to apply, so the usual vulnerability queue does not work. You are managing risk with partial information. The vendor may publish a workaround first, a fix later. Details change by the hour.

Calm and order matter more than speed of announcement. Most of the work is dull: inventory, access rules, log search.

What do the federal rules say about priority?

CISA's BOD 26-04, issued 10 June 2026, replaces the earlier BOD 22-01. It sets urgency using four questions: is the vulnerable asset publicly exposed, is the CVE on the Known Exploited Vulnerabilities catalog, can an adversary automate every exploitation step, and does exploitation give partial or total control. The directive binds federal civilian agencies, but the four questions are a sound way to rank your own work.

Two public data sets help. The KEV catalog lists vulnerabilities with known exploitation. FIRST's Exploit Prediction Scoring System publishes a daily probability that a CVE will be exploited in the next 30 days. A fresh zero-day will often have neither yet, so your own exposure facts carry more weight.

What should the first hours look like?

Constructed example: a vendor announces an actively exploited flaw in a file transfer product. Your team finds it runs in two places, one on the internet and one inside. Hour one: pull the internet-facing server's inbound rule down to known partner addresses. Hour two: search logs back through the exposure window for the request patterns the vendor lists. Hour three: apply the vendor's workaround, and write down the time. When the patch lands, the exposed server goes first.

NIST SP 800-61 Revision 3 places incident response inside the Cybersecurity Framework 2.0, so preparation, detection, response and recovery are linked. Your plan for a zero-day should already exist before the day it happens.

How do you communicate while it unfolds?

Pick one person to own updates, and send them on a fixed rhythm, for example every four hours, even when the news is "no change". Say what you know, what you do not, and what you are doing next. Leadership wants to hear the exposure in plain terms: which systems, which data, and whether you see signs of use. Avoid guesses about attackers. If customers could be affected, involve legal and communications early, and check your contracts for notice duties before anyone drafts a statement.

How to check or apply this

1. Confirm the advisory from the vendor and from CISA or your national CERT. Ignore social media rumours.
2. Search your software inventory or SBOMs for the affected product and version, including inside other products and containers.
3. Rank by exposure: internet-facing first, then systems with sensitive data, then the rest.
4. Reduce exposure now: restrict access, disable the feature, put the service behind authentication.
5. Hunt back through logs for signs of use. Look from the date the flaw was first reported, not the date you learned of it.
6. Apply vendor mitigations and record the time.
7. Patch the moment a fix is released, and test quickly.
8. Afterward, note what you could not answer fast. That gap is your next investment.

Safeguard supports SBOM and dependency scanning and reachability analysis, which help answer "where do we use this, and is the vulnerable code called". Autonomous remediation with fix pull requests exists as an option, and it is off by default.

Quick check

Sources

• CISA BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA Known Exploited Vulnerabilities Catalog
• FIRST, Exploit Prediction Scoring System
• NIST SP 800-61 Rev. 3, Incident Response Recommendations

Last reviewed: 18 October 2026.