Pre-KEV exploitation is closing the vulnerability response window

At a glance

What this is: This analysis argues that CISA KEV is a confirmation signal, not an early warning system, because real exploitation often begins days or weeks before formal listing.

Why it matters: For IAM and security practitioners, the implication is that prioritisation workflows must shift upstream from confirmed exploitation to layered exploitability evidence, especially where identity-adjacent services, exposed secrets, and privileged access paths are involved.

By the numbers:

• Nucleus reviewed 122 new vulnerabilities added to CISA KEV between October 2025 and March 2026.
• The review found 8 of those 122 vulnerabilities were already exploited in the wild before KEV listing.
• Mandiant’s M-Trends 2024 report found average time-to-exploit dropped by approximately 92% from 2018-19 to 2023.

👉 Read Nucleus's analysis of the exploitability intelligence gap before CISA KEV

Context

KEV prioritisation is useful, but it is not designed to catch the earliest phase of exploitation. In practice, many programmes still wait for formal confirmation, even though attackers often move during the disclosure-to-exploit gap, when exposure is already real but consensus has not formed.

This matters to IAM-adjacent operations because vulnerable developer tools, endpoint software, and exposed services often sit close to credential pathways, secrets, and privileged workflows. When exploitability becomes the trigger rather than the proof, teams can reduce the window in which attacker activity can turn into access, persistence, or lateral movement.

Key questions

Q: How should security teams prioritise vulnerabilities that appear in KEV lists?

A: Security teams should prioritise vulnerabilities by evidence of active exploitation, reachability in the running environment, and privilege impact. KEV signals deserve higher urgency because they represent weaknesses adversaries are already using, not just theoretical exposure. The best programmes combine exploit intelligence with runtime context so remediation effort follows real attack paths, not broad category rankings.

Q: Why do CISA KEV and EPSS still leave exposure gaps?

A: Because both are signals, not guarantees of when attackers will act. KEV is intentionally conservative and often arrives after real exploitation has begun, while EPSS is probabilistic and does not tell you whether a specific asset is already being targeted. Teams need workflow integration that converts weak signals into a decision before the window closes.

Q: What breaks when teams wait for confirmed exploitation before patching?

A: The response window collapses. By the time exploitation is confirmed publicly, attackers may already have had days or weeks to establish access, weaponise proof-of-concepts, or pivot into adjacent systems. Waiting for certainty turns vulnerability management into after-the-fact cleanup instead of exposure reduction.

Q: Who is accountable when pre-KEV exploitation is missed?

A: Accountability usually sits across vulnerability management, security operations, and the asset owner, because the failure is often a process gap rather than a single missed alert. Organisations should assign a clear owner for pre-KEV escalation decisions and define when exploitability evidence is enough to trigger compensating controls.

Technical breakdown

Why KEV is a confirmation signal, not a warning system

CISA’s Known Exploited Vulnerabilities catalog is intentionally conservative. A CVE usually appears only after exploitation is observed and validated, which makes the list authoritative but reactive. That design suits governance reporting, but it does not help teams that need to act before attackers fully operationalise a flaw. The practical problem is not whether KEV is trustworthy. It is that trust arrives after the attacker has already had time to move.

Practical implication: build an upstream prioritisation path that can act on exploitability evidence before KEV confirmation arrives.

How pre-KEV exploitation collapses the response window

Pre-KEV exploitation means the vulnerable asset is already under active attack while many defenders still treat it as merely theoretical. As disclosure-to-exploit cycles shrink, public proof-of-concepts, ransomware activity, and commercial threat intelligence become more important than waiting for a catalog entry. This is a prioritisation problem as much as a vulnerability problem: teams often have the evidence, but not the workflow to connect it quickly enough.

Practical implication: correlate PoC activity, exploit chatter, and threat intelligence into a single decision path within hours, not days.

What layered exploitability intelligence changes in practice

Layered exploitability intelligence combines multiple weak signals into one defensible action. No single feed is enough, but together they can show whether a vulnerability is trending toward real-world abuse. That matters for tools, too. A vulnerability management programme that only listens for one high-confidence indicator will always arrive late. The better pattern is to treat exploitability as a probability that rises across sources, not a binary status that appears only after confirmation.

Practical implication: assign prioritisation weight to signal convergence across sources rather than waiting for a single definitive alert.

Threat narrative

Attacker objective: The attacker aims to exploit a known weakness before defenders treat it as urgent, creating access or execution opportunities while response workflows are still waiting for confirmation.

1. Entry occurs when attackers find a vulnerable internet-facing or internally reachable service before it is added to KEV.
2. Escalation follows when proof-of-concept code, weaponisation, or active exploitation turns the flaw into repeatable access.
3. Impact appears when the attacker uses the window before formal confirmation to establish access, pivot, or execute payloads across the environment.

NHI Mgmt Group analysis

Pre-KEV exploitability is a governance gap, not just a timing problem. The market often treats CISA KEV as the point at which risk becomes real, but this article shows that exploitation can be active long before formal listing. That means the issue is less about missing a signal and more about over-trusting the signal that is easiest to defend internally. Practitioners need decision paths that can escalate on layered evidence, not only on confirmed catalog status.

Exploitability intelligence is the new prioritisation layer. The article’s strongest contribution is the argument that public PoCs, ransomware activity, EPSS movement, and vendor intelligence are individually imperfect but collectively actionable. That is the operating model security teams need in vulnerability response, because attackers do not wait for a single source to agree. Exploitability intelligence gap: the delay created when teams cannot consolidate weak but timely signals into one prioritisation decision.

Identity-adjacent systems inherit vulnerability risk faster than most programmes admit. Developer tooling, endpoint software, and exposed services may not look like IAM assets, but they often sit on the path to credentials, tokens, certificates, and privileged workflows. That makes pre-KEV exploitation directly relevant to NHI governance and privilege containment, not just patch management. Teams should treat early exploit signals as potential identity-risk indicators when the affected service can expose or redirect access.

Waiting for consensus shifts the burden from risk management to incident response. By the time a vulnerability is in KEV, some defenders are already behind the attack curve, especially where no patch exists. The article is right to frame this as an integration problem: organisations need one workflow that fuses detection, prioritisation, and accountability before the wider market catches up. Security leaders should measure whether their process shortens decision time, not just remediation time.

What this signals

Exploitability now behaves like an identity-risk signal as much as a patching signal. When a vulnerable service can expose tokens, certificates, or privileged sessions, the question is no longer only whether the flaw is exploitable. It is whether the service sits on a path to non-human identity compromise, which can amplify a routine vulnerability into a broader access event. Teams should therefore blend vulnerability intelligence with identity context and privileged asset mapping.

Decision speed is becoming a control in its own right. Programmes that can connect weak early signals to containment actions will reduce exposure faster than teams waiting for confirmation from KEV or a single threat feed. That is where operational maturity shows up: in how quickly evidence becomes a decision, and how quickly that decision becomes isolation, patching, or compensating control. The practical benchmark is hours, not business days.

NHI exposure often begins where vulnerability management and access governance do not meet. Services that host secrets or authenticate workloads can turn a pre-KEV vulnerability into an identity incident before anyone opens an incident ticket. That makes the governance gap structural, not incidental: exposure management, IAM, and PAM teams need shared visibility into which vulnerable assets can materially alter access. See 52 NHI Breaches Analysis for the recurring failure patterns.

For practitioners

• Add pre-KEV escalation criteria to vulnerability triage Define a trigger set that includes public proof-of-concept release, commercial threat intelligence, ransomware mention, and exploit chatter, then route those cases for same-day review even when CISA KEV is still empty. This is especially important for services that can expose credentials, tokens, or remote execution paths.
• Correlate exploit signals in one prioritisation workflow Unify EPSS, PoC monitoring, vendor advisories, and internal asset criticality so analysts are not stitching evidence together manually across disconnected feeds. The goal is to decide faster on the cases most likely to become access or execution events.
• Map vulnerable services to identity blast radius For every externally reachable application or developer tool, document whether a compromise could expose service accounts, API keys, certificates, or admin sessions. That mapping tells you which vulnerabilities are identity risks as well as availability risks.
• Measure decision latency, not only patch latency Track the time between first credible exploit signal and the decision to isolate, patch, or compensate. If the gap is measured in days rather than hours, the programme is still reacting on attacker timelines.

Key takeaways

• KEV is a confirmation mechanism, so programmes that wait for it are often already behind attacker activity.
• The article shows that exploitation can arrive 1 to 31 days before formal listing, which is enough time for meaningful access, persistence, or pivoting.
• Security teams should prioritise layered exploitability evidence and map vulnerable services to identity blast radius before the window closes.

Key terms

• CISA KEV: CISA’s Known Exploited Vulnerabilities catalog lists vulnerabilities that have been observed being actively exploited in the wild. It is a trusted confirmation source, but it is intentionally reactive, so organisations should not use it as the only trigger for prioritisation or response.
• Exploit Intelligence: Actionable information about which vulnerabilities are being actively targeted, how attackers are delivering them, and where exploitation is emerging. It turns vulnerability management from static inventory tracking into a dynamic response process that reflects live adversary behaviour.
• Pre-KEV exploitation: Pre-KEV exploitation occurs when attackers are already using a vulnerability before CISA adds it to the KEV catalog. This phase matters because defenders may still see the issue as theoretical even while real-world abuse is underway, creating a gap between visibility and action.
• Exposure management: Exposure management is the practice of identifying which assets are reachable by attackers and reducing that reach before exploitation occurs. For collaboration systems like SharePoint, it is not enough to know that a patch exists, because public accessibility changes the speed and likelihood of attack.

What's in the full report

Nucleus's full analysis covers the operational detail this post intentionally leaves for the source:

• A complete breakdown of all 122 KEV additions reviewed during the six-month window.
• Per-CVE pre-KEV signal analysis showing how public PoCs, EPSS, and threat intelligence lined up before confirmation.
• The Nucleus Threat Rating approach and how it is used inside exposure management workflows.
• The full case-by-case evidence for Gogs, Notepad++, FileZen, and Chromium.

👉 The full Nucleus report shows the 122-vulnerability dataset, pre-KEV signal patterns, and case-by-case timing.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners building governance across human identity, non-human identity, and privileged access workflows.