To be clear, a zero day vulnerability is not a synonym for “unpatched” or “critical vulnerability.” It is also not interchangeable with a “new” vulnerability or one that simply lacks a fix. A zero day is a very specific condition for multiple states of a vulnerability and associated exploitation and deserves precision when mentioned by a vendor or the media.

Straight Forwardly: A zero-day vulnerability is a previously unknown flaw in software or hardware that is potentially being actively exploited regardless of its severity, where the vendor (or responsible open-source community) has had “zero days” to develop and release a patch at the time of public disclosure. The emphasis on three elements: the threat is unknown to the vendor, it is potentially being exploited, and it is disclosed to the public. If you remove any one of these elements, it is no longer a zero day. For example, if the vulnerability has been patched—even if active exploitation is occurring—it is no longer a zero day but a known vulnerability following responsible public disclosure. Misusing the term—or creating hybrid phrases like “undisclosed” or “unknown” zero day—only muddies the waters for risk prioritization.

This distinction matters because the industry routinely collapses three very different concepts into one overloaded term:

1. Known, but unpatched, vulnerabilities: The industry sees CVEs reserved all the time for these situations. These flaws are publicly or privately disclosed, often cataloged, sometimes scored, and frequently prioritized for remediation by the vendor, based on severity and complexity to resolve. They are dangerous, but they are not zero days.
2. Newly disclosed vulnerabilities: These may lack a patch, but are not yet known to be exploited in the wild. These are serious, but without a working exploit, they aren’t categorized as zero days.
3. True zero days: These are the vulnerabilities defenders didn’t know existed until threat actors demonstrated that knowledge through active exploitation (zero day exploit) before a patch was available.

Why does this confusion persist and why do cybersecurity professionals and the media still get this wrong? Simply put, “zero day” sounds catastrophic. It implies an inevitability that fuels sensationalism. For the media, it suggests that no defense could have worked, creating a sense of extreme urgency to drive engagement. For organizations explaining a breach, it can sound like absolution—an excuse that nothing could have thwarted the attack and subsequent breaches. For vendors selling tools, it creates an artificial, absolute need for their specific solutions to be secured regardless of the moment of time.

For cybersecurity professionals, the cost of this misuse is not academic. When the term is used excessively, real zero days lose their urgency and budget. Security teams become desensitized and lose focus. Boards will begin to assume that breaches are unavoidable acts of nature rather than failures of control, hygiene, or prioritization. Regulators then struggle to distinguish genuine negligence from unforeseeable risk. Over time, the term loses its meaning.

Today, true zero days are rare and expensive. They are usually not wasted on low-value targets. Instead, they are typically chained with other weaknesses, like identity-based attack vectors, delivered through trusted pathways and executed with stealth precision.

Nation states and top-tier cybercrime syndicates do not “burn” zero days casually. They use them only when the return justifies the cost of development and risk of public exposure. Once the vulnerability is disclosed and patched, their advantage as a weapon is lost. That reality alone tells us how careful we must be when invoking the term.

A proper understanding of zero days also changes the conversation around cyber defense. You cannot patch what you do not know exists; this is why disclosure is a part of the definition. However, you can reduce the impact of what you cannot patch or threats that have not been disclosed through cybersecurity best practices:

• Least Privilege: Limits what exploit code or malware can interact with at the operating system and application level.
• Segmentation: Prevents lateral movement after an initial exploitation.
• Identity Controls: Limits the ability of an attacker to impersonate legitimate users.

These aren’t just theoretical mitigations, they are the difference between a contained incident and a systemic failure when a zero day is truly exploited in an environment. Getting the definition right also forces honesty in post-incident analysis. These questions are uncomfortable, but necessary if organizations want to mature, rather than just repeat misunderstood terms:

• Was the vulnerability truly unknown at the time of exploitation, or was it known but deprioritized?
• Was exploitation confirmed, or merely assumed?
• Was the absence of a patch the root cause, or was it the absence of compensating controls?