It fails when the flaw is unknown before exploitation begins, because there is nothing to scan, catalogue, or patch in time. In that situation, defenders need controls that observe behaviour at runtime and stop malicious execution paths as they form. Known-vulnerability workflows are necessary, but they are no longer sufficient against fast exploit generation.
Why vulnerability-only thinking fails at the zero-day boundary
Zero-day defence breaks the moment your model assumes the adversary must first be catalogued before they can be stopped. The core failure is temporal: exploitation can begin before a vulnerability is named, scored, published, or patched, so a knowledge-first workflow leaves a blind window at the exact point defenders need runtime interruption most.
What defenders must watch instead of waiting for a CVE
The practical shift is from “known flaw, known fix” to observable malicious behaviour. That means looking for exploit chains, abnormal process creation, memory tampering, privilege escalation, suspicious outbound traffic, and other execution-path signals that reveal a live attack even when the underlying defect is still undocumented.
That is why defensive knowledge graphs and detection mappings matter: MITRE D3FEND helps teams reason about countermeasures by behaviour, not just by vulnerability record, while the NIST Cybersecurity Framework 2.0 reinforces the need to detect and respond even when preventive knowledge is incomplete.
In practice, runtime controls, hardening, segmentation, and application allowlisting become the fallback when patch intelligence is missing. The point is not to abandon vulnerability management, but to stop treating it as the only line of defence when fast-moving exploitation can outrun disclosure and remediation.
Why vulnerability catalogues still matter, but cannot be the whole strategy
Known-vulnerability workflows remain essential for triage, exposure reduction, and long-tail risk management. They are just structurally unable to solve first-seen exploitation, because a scanner cannot flag what the defender does not yet know exists, and a patch cannot be deployed before there is something concrete to patch.
That distinction is captured well by upstream visibility sources such as NIST National Vulnerability Database and the CVE Program, which are critical for known issues but depend on disclosure, assignment, and indexing. When an exploit lands before those steps complete, defenders need compensating controls already in place.
The most mature programmes treat vulnerability knowledge as one input to defence, not the defence itself. That typically means pairing catalogue-driven patching with behaviour-based detection, exploit mitigation, least privilege, and containment so that a missed or undisclosed flaw does not automatically become a successful intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Exploit paths drive zero-day defense when flaws are unknown. |
| Recommendation — Map exploit behavior to T1190 and block abuse paths with runtime detection. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | Zero-day defense needs runtime monitoring beyond vulnerability knowledge. |
| RS.MA-01 — Response actions are performed to contain incidents | When patching lags, containment is the fallback control against active exploitation. | |
| Recommendation — Monitor live activity for exploitation indicators before a CVE exists. Contain suspicious execution quickly when exposure cannot yet be patched. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Runtime controls help stop malicious execution paths during zero-day abuse. |
| SI-4 — System Monitoring | Observed behavior is the key signal when vulnerability knowledge is absent. | |
| Recommendation — Deploy runtime protections that can stop malicious code in execution. Instrument systems to detect exploit behavior, not just known vulnerabilities. | ||
Practitioner Guidance
What to prioritise: If your current zero-day posture starts and ends with vulnerability intelligence, prioritise runtime detection and containment first. Those controls are what reduce blast radius when the issue is still invisible to scanners, ticketing, and patch queues.
What to verify: Verify that you have telemetry capable of spotting exploitation as it happens, not only after a CVE is published. Good evidence includes alerting on anomalous process trees, blocked suspicious execution, and containment actions that can be explained after the event.
Decision rule: If a control only helps after a vulnerability is identified, treat it as necessary but insufficient for zero-day defence. If a control can also interrupt an attack path in flight, it belongs in the front line of your response design.
Practitioner takeaway: Zero-day resilience is built on the ability to see and stop abuse before you know the flaw’s name; vulnerability intelligence should accelerate response, not define the boundary of defence.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org