What is a zero-day vulnerability, and how do you prepare for one?

A zero-day vulnerability is a flaw in hardware, firmware or software that the vendor has not fixed, and often does not know about, so no patch exists when attackers start using it. You cannot patch your way out on day zero. You protect yourself by reducing exposure, limiting damage and patching fast once a fix ships.

What does the term mean precisely?

NIST's glossary, citing CNSSI 4009, defines a zero-day attack as one that exploits a previously unknown hardware, firmware or software vulnerability. In everyday use, people also call the flaw itself a zero-day. Once a vendor ships a fix, the same flaw is usually described as a known or n-day vulnerability, even though unpatched systems stay just as exposed.

That shift matters for planning. Most of your risk, most of the time, comes from known flaws you have not patched yet, not from true zero-days. The two need different responses.

How long do vendors get to fix one?

There is no universal clock, but a published policy shows how researchers handle it. Google Project Zero follows a 90+30 policy: the vendor has 90 days after notification to make a patch available, and if it does, details are published 30 days after the patch. If a vendor cannot patch in 90 days, details are published at day 90, with a possible grace period of up to 14 extra days on request.

When there is evidence of active exploitation against real users, Project Zero's policy replaces the 90-day deadline with a 7-day one, and the grace period is 3 days. The point is that the window between "known to someone" and "patch available" is measured in days, and it is not under your control.

How do you decide what to do first?

CISA's June 2026 directive BOD 26-04 gives a useful model, although it binds only US federal civilian agencies. It sets remediation urgency from four questions: is the asset publicly exposed, is the vulnerability in CISA's Known Exploited Vulnerabilities (KEV) catalog, can an adversary automate every step of exploitation, and does exploitation give partial or total control. CISA says it publishes answers on KEV status, automation and technical impact for every CVE.

The directive also says timelines move as facts change. Its own example: removing a system from the internet changes the exposure answer and relaxes the timeline. And for the most severe combinations the directive requires a forensic triage, to check whether the system was already compromised, alongside the fix.

A constructed example

A critical flaw is reported in a file-transfer product, and an advisory says it is being exploited. No patch exists. A team with an asset inventory finds two internet-facing instances in under an hour. They take the web interface off the internet and restrict it to a VPN, which is the same move the directive describes. They search logs back to the first public report for unusual logins and large downloads. When the vendor ships a patch two days later, they test it on one instance and roll it out to the other. A team without an inventory would still be asking who owns the product.

How to check or apply this

1. Keep a live inventory of software and versions, tagged by internet exposure and owner. This is the step that most decides how fast you respond.
2. Subscribe to the KEV catalog and your vendors' security advisories, and map new entries to your inventory the same day.
3. Pre-plan mitigations for exposed systems: remove from the internet, restrict by network, disable the affected feature, or add a virtual patch at a gateway.
4. Limit blast radius with segmentation, least privilege, and secrets that are short-lived and scoped.
5. Log enough to look backward. After a zero-day is disclosed, you will need to ask whether it was used against you before the news.
6. Rehearse the patch path: who approves, how you test, how you roll back. Aim to patch exposed, exploited flaws in hours or days, not on the monthly cycle.

Safeguard works on the software side of this. Its zero-day discovery work and reachability analysis aim to tell you early which of your dependencies are affected and whether your code reaches the vulnerable function, and its fix pull requests, which are off by default, can speed the patch step once a fix exists.

Quick check

Sources

• NIST CSRC Glossary, zero-day attack
• Google Project Zero, Vulnerability Disclosure Policy
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA, Known Exploited Vulnerabilities Catalog

Last reviewed: 18 October 2026.