The gap is not intelligence; it's decision logic. Organisations receive KEV data. Most don't have a workflow that treats it differently from everything else. This briefing provides one: a tiered decision framework, role-specific implementation guidance, and sector-adjusted operationalisation criteria.

Executive Summary

The CISA KEV catalog identifies 1,484 vulnerabilities confirmed exploited in the wild, out of 308,920+ published CVEs. That is 0.48% of all known vulnerabilities, and available evidence suggests it accounts for a disproportionate share of confirmed breaches. The operational problem is not access to this signal: most programs receive KEV data. The problem is that workflows built around CVSS scores have no structural mechanism to act on KEV status differently from any other finding. With mean time-to-exploit now estimated at -7 days, the window between catalog addition and active exploitation is, on average, already closed before a patch cycle begins. The central argument of this briefing is that KEV status must function as a workflow trigger, routing findings to a pre-defined emergency track, rather than as one severity input among many. What follows is the operational methodology to implement that distinction: a four-tier decision framework, role-specific guidance for five functions, and sector-adjusted criteria for six industries.

The Problem

This is a structural artefact, not a knowledge gap. Vulnerability management workflows were built in the 2000s and 2010s around CVSS as the only standardised severity metric available. When CISA launched KEV in November 2021, most programs had no capacity to treat it differently from existing scanner output. KEV was absorbed into workflows designed for a different signal and has stayed there.

The consequence is a category error at the point of triage. KEV status encodes confirmed, in-the-wild exploitation. CVSS encodes theoretical severity. Processing both through the same scoring formula, as most programs do, treats empirical evidence of active attack as functionally equivalent to a theoretical risk rating. The Operational Analysis section examines what that produces at the workflow level.

The Evidence

KEV represents concentrated exploitation risk. Government data from CISA and NIST's National Vulnerability Database confirms that as of end-2025, the KEV catalog contains 1,484 confirmed, actively exploited vulnerabilities out of 308,920+ CVEs published since 1999, approximately 0.48% of all known vulnerabilities. Vendor-funded research from the Cyentia Institute and Kenna Security (a VM platform vendor) found that vulnerabilities with evidence of active exploitation are 7 times more likely to affect a given organisation than those without; that figure has not been independently replicated in peer-reviewed literature but is directionally consistent with CISA's own catalog concentration data.

Time-to-exploit has gone negative. Three commercial security vendors published converging findings on exploitation speed in early 2026, each drawing on proprietary incident data. All three have a commercial interest in demonstrating the severity of the exploitation gap; the convergence across separate datasets nonetheless represents the strongest available signal on exploitation speed.

Mandiant (a Google subsidiary) released M-Trends 2026, built on 450,000+ hours of paid incident response engagements, estimating mean time-to-exploit at -7 days for 2025. Exploitation begins, on average, before a vendor patch is publicly available. Rapid7 found the median window between vulnerability publication and CISA KEV addition compressed from 8.5 days to 5 days. CrowdStrike found 42% of exploited vulnerabilities were attacked before public disclosure.

Organisations running monthly patch cycles alone are unlikely to be operating ahead of this timeline.

CVSS alone is a poor predictor of exploitation. Independent nonprofit research from FIRST.org's EPSS project, the most methodologically transparent public dataset on exploitation probability, found that only approximately 2.3% of CVEs scored 7.0 or higher are observed in actual exploitation attempts within any given measurement period.

The misalignment runs in both directions. Some KEV-listed vulnerabilities carry CVSS scores below 7.0 but appear in active ransomware and nation-state operations. Conversely, a CVSS 9.8 rating with no public exploit code and no known threat actor interest carries less urgency than a CVSS 6.5 entry confirmed in the wild.

Fewer than 5% of all published CVEs are ever observed exploited. KEV membership is a sharper filter than any severity score.

Federal mandates have set a response baseline that private sector timelines often don't meet. CISA's Binding Operational Directive 22-01 (2021) originally required Federal Civilian Executive Branch agencies to remediate KEV vulnerabilities within 14 days of catalog addition. On June 10, 2026, CISA issued BOD 26-04, which revokes BOD 22-01 and replaces the flat 14-day window with a four-variable risk model — asset exposure, KEV status, exploit automation, and technical impact — that assigns remediation windows ranging from 3 days (highest-risk combinations, with mandatory forensic triage) to deferral until the next scheduled system upgrade. Private sector organisations face no equivalent mandate, but face the same threat actors. The gap between federal response timelines and typical enterprise patch cycles creates an asymmetry that available evidence suggests adversaries exploit systematically.

Exploitation volume is accelerating faster than remediation capacity. Rapid7's 2026 Global Threat Landscape Report, vendor research based on Rapid7's own MDR incident data, found confirmed exploitation of newly disclosed high-severity vulnerabilities (CVSS 7-10) increased 105% year-over-year, from 71 cases in 2024 to 146 in 2025. As a vendor with commercial interest in demonstrating threat severity, this figure should be read alongside government and academic sources; it is directionally consistent with CISA's catalog growth data and Mandiant's findings.

Operational Analysis

Enterprise vulnerability queues are not manageable at CVSS-first scale. Practitioner experience indicates a typical enterprise generates 50,000-200,000 findings per month, a range that varies by organisation size and scanning coverage, but one where 15-20% are flagged critical or high by CVSS. That volume consistently exceeds available remediation capacity. Programs that treat all high-severity findings as equivalent lose KEV signal in the noise.

In most programs, the queue does not clear. Patching one round of vulnerabilities surfaces the next. Teams tend to optimise for volume reduction, closing the most tickets rather than addressing the highest-probability threats. That dynamic is what makes the decision logic problem structural rather than behavioural.

When a new KEV entry arrives, multiple industry reports and practitioner accounts indicate many programs have no automatic interrupt. The entry joins the standard ticket queue and waits for the next weekly triage meeting.

The timeline from KEV addition to patch deployment, without a pre-defined emergency track, frequently exceeds two weeks. Against a mean time-to-exploit of -7 days, that gap cannot be closed through faster process execution alone. The process itself needs to change.

Vulnerability management platforms advertise "risk-based prioritisation" and "threat intelligence integration." In practice, practitioner experience indicates many implementations add KEV as one more input in a scoring formula without changing how findings move through the workflow. The output looks different. The process is identical. Ticket volume, not exploitation probability, remains the optimisation target.

The fix is not a platform upgrade. Practitioner accounts describe organisations that replaced their VM tooling without redesigning triage policy and reported the same KEV handling failures on new infrastructure. The constraint is policy: the absence of a clear, documented definition of what a KEV designation triggers and who is authorised to act on it without a standard approval cycle. The Decision Framework section provides that definition.

Visibility Gaps and Control Failures

Many vulnerability scanners cross-reference NVD but not KEV status natively. Where KEV tagging requires manual correlation or TI platform integration, a lag develops between CISA catalog addition and organizational recognition of immediate priority.

Practitioner estimates place the resulting exposure lag at 7-14 days: the time teams spend waiting for tools to surface KEV status or manually cross-referencing data sources. Controlled measurement of this lag across programs is limited; the figure represents the range most commonly reported.

Asset inventory gaps compound the lag. Organisations identify a CVE as KEV-listed but cannot determine which assets are affected without accurate CMDB data. Unresolved asset attribution defaults the finding to standard scheduling rather than emergency track.

Change governance creates a third delay vector. CAB approval cycles designed for scheduled maintenance windows are incompatible with 72-hour Tier 1 SLAs. Without a pre-negotiated emergency change track, KEV findings queue for the next monthly window by default.

EPSS integration gap: Most VM consoles do not surface EPSS scores natively. Manual export-enrich-reimport cycles running weekly at best introduce data latency that undermines Tier 4 escalation logic. Daily EPSS refresh is the minimum operational requirement.

Decision Framework

KEV status is the primary triage criterion. CVSS, EPSS, asset exposure, and asset criticality operate as secondary inputs within each tier. A vulnerability is assigned to the highest applicable tier - lower-tier criteria do not accumulate to override a higher-tier classification.

Priority Tier Table

Input Signal Definitions

KEV Status: Binary - CVE present in CISA KEV catalog, yes or no. Checked at scanner ingestion, not at triage review.

EPSS Score: Probability of exploitation in next 30 days, expressed as 0.00–1.00. Threshold for Tier 4 escalation: ≥ 0.50.

Asset Exposure: Internet-facing (publicly routable), Internal (behind perimeter), or Isolated (air-gapped or segmented). Sourced from asset inventory; assets without a classification default to Internet-facing.

Asset Criticality: High (revenue systems, personal data repositories, OT/ICS, authentication infrastructure), Medium (business support systems), Low (development, test, isolated workstations).

Escalation Criteria

The framework dynamically adjusts urgency, elevating a vulnerability to a higher-priority track the moment real-world threat intelligence or environmental data invalidates the baseline assumptions of its current tier.

No-Patch Escalation Path

Patch unavailable at time of KEV addition: Deploy compensating controls within Tier SLA window → Document control coverage gap → Initiate vendor contact for patch timeline → Review asset isolation feasibility → Escalate to accepted risk register if no viable mitigation exists → Monitor for exploitation indicators every 24 hours until patch available.

Framework Constraints

Asset inventory dependency: Tier 1 and Tier 2 classifications require accurate Internet-facing and criticality tagging in CMDB. Unclassified assets default to Tier 1 treatment. CMDB accuracy below 80% degrades framework precision proportionally.

Change management dependency: Tier 1 remediation windows (72 hours) require a pre-negotiated emergency change track with standing CAB approval. Organisations without this track in place must negotiate it before framework adoption. Runtime negotiation during active exploitation is a documented failure mode.

EPSS data latency: EPSS scores update daily. Scanner integrations pulling EPSS weekly introduce a data lag that reduces escalation trigger accuracy. Daily EPSS refresh is the minimum operational requirement for Tier 4 escalation logic to function correctly.

Operational Outcomes

Cost of misaligned prioritization. Peer-reviewed research supports the underlying problem, if not the specific figures sometimes quoted for it. Jacobs et al., "Improving Vulnerability Remediation Through Better Exploit Prediction" (Journal of Cybersecurity, 2020), found that a CVSS-only strategy of remediating all vulnerabilities scored 7.0 or higher achieves only about 9% efficiency — meaning the vast majority of remediation effort under that strategy goes toward vulnerabilities with no observed exploitation. Controlled research isolating KEV-first triage specifically, rather than exploit-prediction models generally, as the sole variable remains limited.

Remediation queue reduction. Practitioner experience, not controlled research, indicates that deprioritising non-KEV findings with low EPSS scores can reduce active queue volume by 40-60%, with outcomes varying by program maturity and initial CVSS dependency. Independent nonprofit data from FIRST.org's EPSS project shows that an EPSS threshold of 10% reduces the remediation population to a small fraction of CVSS-flagged findings while retaining meaningful exploitation risk coverage.

Reduction in time-to-patch for high-risk vulnerabilities. Practitioner accounts, not peer-reviewed study results, describe reductions in median time-to-patch for actively exploited vulnerabilities from 30-45 days to 7-14 days following KEV-first triage adoption. No controlled study isolates this effect exclusively; these figures represent self-reported operational outcomes. The mechanism is structurally sound: KEV status triggers a pre-defined workflow instead of requiring risk assessment and prioritisation debate, removing decision friction from the critical path.

Governance visibility and audit defensibility. KEV-first operationalisation produces a measurable improvement in reporting precision that CVSS-based programs cannot replicate. When KEV entries are tracked on a separate SLA track, executive dashboards can surface mean time-to-patch specifically for confirmed-exploitation findings, rather than averaging them into the broader remediation population. Practitioner accounts indicate this separation makes SLA compliance visible at the tier level: Tier 1 (72 hours), Tier 2 (7 days), and Tier 3 (14 days) each carry a discrete compliance rate rather than a single aggregate metric.

For audit and regulatory purposes, a documented record of KEV triage decisions, covering timestamp of catalog addition, tier assigned, patch or compensating control deployed, and SLA met or escalated, constitutes the evidence trail that regulators, cyber insurers, and IR teams increasingly request.

Organizations subject to NY DFS 23 NYCRR 500, HIPAA breach response requirements, or SEC incident disclosure rules benefit from the same record: a defensible, timestamped account of how each confirmed-exploitation finding was handled. Board reporting improves correspondingly. Rather than presenting aggregate patch rates, security leaders can report against the population that carries actual breach risk: KEV entries on Internet-facing and high-criticality assets. That framing aligns security metrics with business risk in terms a board can evaluate.

Workflow Integration Guidance

Vulnerability Management Engineer

Primary responsibility: KEV status check at scanner ingestion, not at triage review.

→ Auto-tag findings with KEV status and EPSS score at ingestion via daily API sync. Any finding where KEV = true AND asset_exposure = internet-facing routes directly to Tier 1, bypassing standard triage.

→ Enforce three required attributes on every finding: KEV status, exposure classification, criticality tier. Missing attributes default to highest-risk classification.

→ Run a daily KEV delta report: new catalog additions cross-referenced against active asset inventory, distributed to the VM team and TI analyst each morning.

Metric: Mean time from KEV addition to Tier 1 ticket creation. Target: < 4 hours.

Threat Intelligence Analyst

Primary responsibility: Enrich KEV entries with threat actor context and generate escalation signals.

→ For each new KEV entry: document threat actor associations (APT designations, ransomware affiliations), exploit maturity (PoC / weaponized / commodity), and days from disclosure to catalog addition.

→ Push escalation signals to VM Engineer on: confirmed APT attribution with sector targeting, EPSS delta ≥ 0.20 within 72 hours, or ISAC-reported exploitation ahead of formal catalog addition.

→ Maintain a sector-specific KEV watch list reviewed weekly. ISAC-reported exploitation without formal catalog addition triggers Tier 4 → Tier 3 escalation.

Metric: Threat actor attribution coverage for active KEV entries. Target: ≥ 70% of entries relevant to the organisation's asset profile.

Detection Engineer

Primary responsibility: Deploy detection coverage in parallel with patch, not after.

→ Open a detection ticket at the same time the patch ticket is created for every Tier 1 and Tier 2 entry. Query SIEM and EDR rule sets within 24 hours. Gaps on Tier 1 require immediate rule development or vendor signature pull.

→ Maintain a KEV detection coverage matrix: CVE identifier, ATT&CK mapping, detection source, coverage status, date achieved.

→ Run retrospective hunts against 30-day log data for each new Tier 1 entry. Exploitation may predate the catalog addition. Escalate anomalies to IR.

Metric: Detection coverage rate for Tier 1 and Tier 2 entries. Target: 100% coverage within 48 hours of Tier 1 ticket creation.

Security Manager

Primary responsibility: Pre-negotiate the organizational conditions that make the framework executable.

→ Secure a standing pre-approved emergency change track with CAB before rollout. Activation conditions: KEV = true AND asset_exposure = internet-facing. Standing policy, not runtime authorization.

→ Get KEV SLA policy signed by CISO and CIO: Tier 1 = 72 hours, Tier 2 = 7 days, Tier 3 = 14 days. Define the accepted-risk path for no-patch scenarios before it is needed.

→ Report to leadership monthly: Tier 1 mean time-to-patch, detection coverage rate, escalation frequency by tier, accepted risk register size. Quarterly review against 90-day performance data.

Metric: SLA compliance rate. Target: ≥ 95% of Tier 1 findings remediated or compensating controls deployed within 72 hours.

IT Operations / Patch Engineer

Primary responsibility: Execute KEV patches on a separate track from the standard monthly cycle.

→ Maintain a KEV patch runbook separate from the standard cycle: emergency change template, reduced testing threshold for Tier 1 (functional validation plus rollback readiness), and rescan trigger on completion.

→ Pre-configure deployment groups for internet-facing, critical infrastructure, and authentication assets so Tier 1 patches deploy without manual asset selection.

→ Verify every Tier 1 patch via authenticated rescan within 4 hours. A failed patch with no compensating control triggers IR notification; it does not re-enter the standard queue.

Metric: Patch verification rate for Tier 1 findings. Target: 100% confirmed via authenticated rescan within 4 hours of deployment.

Industry Context

Sector Variables Matrix

Cross-Sector Constants

KEV addition rate: Catalog additions have increased year-over-year since November 2021. Sector adjustments change response capacity, not the underlying signal volume.

Threat actor convergence: Nation-state TTPs appear in ransomware toolkits. Multiple vendor threat reports show commodity exploit code reaching KEV-listed CVEs within hours to days of PoC publication, a finding consistent across Mandiant, Rapid7, and CrowdStrike reporting, though each draws on proprietary telemetry. Sector threat actor profiles inform sequencing, not tier logic.

CMDB accuracy: Asset inventory quality determines framework precision in every sector. Assess CMDB coverage before calibrating sector-specific SLA targets.