A zero day vulnerability is a software, firmware or hardware flaw that is unknown to those who would fix it, or has no fix yet, and that an attacker may already be able to exploit. The name refers to the zero days of warning defenders have had.
What does the official definition say?
NIST's glossary, citing CNSS and NISTIR sources, defines a zero day attack as one that exploits a previously unknown hardware, firmware or software vulnerability. In everyday use people stretch the term. They say "zero day" for a flaw disclosed with no patch, or for one found being exploited before a fix. These uses overlap, but they are not identical, so check which meaning a report uses.
What is the difference between a vulnerability, an exploit and an attack?
A vulnerability is the weakness. An exploit is the technique or code that takes advantage of it. An attack is the use of that exploit against a target. A zero day can be at any of these stages: a flaw that nobody has found, a flaw with a working exploit held privately, or an exploit being used in the wild.
How does a zero day get found?
Researchers find them and report them, which usually starts a coordinated fix. Attackers also find them and keep them private. Sometimes a flaw is discovered because someone notices odd behavior on a compromised system. Automated tools and AI assisted analysis now find flaws in code at scale, which speeds discovery on all sides.
Why are they hard to defend against?
There is no patch and often no signature. Scanners that match known vulnerabilities cannot report what is not yet in a database. Defense depends on reducing what an attacker can do with a flaw: limiting exposure, restricting privileges, and detecting odd behavior.
What should defenders do before one lands?
Know what you run. The first question in any event is "are we affected?" A queryable inventory of software and dependencies answers it in minutes. Without one, you search by hand while the clock runs.
Reduce exposed surface. Software that is not reachable from outside, or not loaded, cannot be attacked through a flaw in it. Remove what you do not use.
Limit privilege. If a service runs with only the rights it needs, a flaw in it yields less.
Segment and monitor. Separation limits how far an intruder moves. Monitoring that watches behavior rather than known signatures can catch use of a flaw nobody has named.
Prepare containment options. Workarounds, feature flags, blocking rules and the ability to isolate a component should be on a list before the event.
What should defenders do when one is announced?
Confirm whether you are affected, using inventory. Check whether the vulnerable component is reachable in your environment. Apply the vendor's mitigation or workaround if there is no patch. Watch for the fix and apply it on an agreed timeline. Check whether CISA's Known Exploited Vulnerabilities catalog has added it, since that confirms exploitation in the wild. NIST SP 800-40 Rev. 4 treats patching as preventive maintenance and recommends planning for it as an enterprise process, including for urgent cases.
Communicate. Tell leadership what you know, what you do not know and when you will update them next.
Does every zero day matter to me?
No. Many affect software you do not run, or code you do not reach. Panic spending is a risk too. Use a short test: do we run it, is it reachable, is it exploited, what does it touch? Most events end at the first or second question.
Do zero days drive most breaches?
We have not confirmed a figure from a source, so we do not give one. Public exploitation catalogs show that many exploited vulnerabilities were known and patchable, which is the subject of the n-day comparison in our companion post. Good basics reduce more risk than a hunt for exotic threats.
Where Safeguard fits
Safeguard offers zero day discovery in agentic and scanner modes and reachability analysis, which shows whether affected code is called in your application. Policies, gates and guardrails can block a vulnerable release at build, CI and release. Fix pull requests exist as autonomous remediation, which is off by default.
What to do
- Build a queryable inventory of software and dependencies.
- Remove unused software and unneeded exposure.
- Run services with least privilege.
- List containment options per component type before an event.
- On announcement, ask four questions: run it, reachable, exploited, what it touches.
- Watch CISA's catalog for exploitation confirmation.
- Tell leadership what is known and when the next update comes.
Quick check
Is a zero day the same as an unpatched vulnerability?
Not exactly. A zero day was unknown to the fixers. A vulnerability can be known and unpatched, and people often call that a zero day informally.
Can a scanner find a zero day?
A scanner that matches known vulnerabilities cannot. Discovery tools that analyze code or behavior can find unknown flaws, but they find them in your code and dependencies, not everything.
Sources
Last reviewed: 18 October 2026.
