Threats and Vulnerabilities
How to Prioritize CISA Known Exploited Vulnerabilities Without Treating Every CVE as an Emergency
The CISA Known Exploited Vulnerabilities catalog answers a critical question: has a vulnerability been exploited in the wild? It does not answer every question a business needs to decide what happens next.
An effective response combines exploitation evidence with the organization’s actual assets, exposure paths, business services, security controls, recovery constraints, and ability to verify remediation. The goal is neither to patch blindly nor to debate scores while an exposed system remains at risk. The goal is a fast, evidence-based decision.
What the KEV catalog tells you
CISA describes its Known Exploited Vulnerabilities catalog as an authoritative source of vulnerabilities known to have been exploited in the wild. Each entry identifies a CVE, affected product, date added, required action, due date for covered federal agencies, ransomware-use status, and supporting links.
That signal is materially different from severity alone. A CVSS score describes technical characteristics and potential impact under defined conditions. CISA KEV status indicates observed exploitation. EPSS estimates the probability that a published CVE will be exploited in the wild during the next 30 days. These inputs are useful together, but they answer different questions.
What KEV status does not tell you
KEV inclusion does not prove that:
- your organization owns an affected product;
- the affected version is installed;
- the system is reachable from an attacker;
- exploitation succeeded in your environment;
- a particular threat actor targeted you;
- ransomware is involved;
- a patch can be installed without operational risk; or
- installing the patch removes existing attacker access.
The distinction protects teams from two common failures: treating every catalog entry as the same operational emergency, and treating patch completion as proof that no incident occurred.
A six-factor prioritization model
1. Known exploitation
KEV status should sharply raise priority because exploitation has moved from possibility to observed activity. Record the CISA date added, required action, due date, notes, and ransomware-use field. If CISA or the vendor revises the entry, update the ticket rather than relying on the original alert.
2. Asset confirmation
Determine whether the affected product and version exist. Use more than one source when practical:
- authenticated vulnerability scan;
- software and hardware inventory;
- endpoint or server management;
- cloud and application administration;
- network discovery;
- procurement and support records; and
- owner confirmation.
An unauthenticated scan that cannot see the installed build may be a lead, not final proof.
3. Effective exposure
Exposure is broader than “internet-facing.” Evaluate:
- public reachability;
- authenticated remote access;
- vendor and support connections;
- trusted partner paths;
- identity and single-sign-on relationships;
- lateral access from user networks;
- management interfaces;
- cloud control-plane access; and
- data or workflow integrations.
A server behind a firewall may still be reachable through a compromised identity, VPN, service account, or trusted application.
4. Business criticality
Identify which service depends on the asset and what a failed change or compromise could interrupt. A vulnerability in an order-processing, clinical, financial, identity, manufacturing, backup, or remote-access system may require a different change plan from the same vulnerability in a disposable test instance.
Criticality should affect both urgency and care. High-value systems often need faster action, stronger evidence preservation, coordinated change control, and a tested rollback path.
5. Compensating controls and detection
Controls can change short-term risk but should not become indefinite substitutes for a supported fix. Relevant controls may include:
- removing public exposure;
- restricting management sources;
- disabling the vulnerable feature;
- isolating the asset;
- enforcing stronger authentication;
- application-aware filtering;
- least-privilege access;
- high-fidelity logging; and
- focused detections based on authoritative vendor or government guidance.
Document what the control blocks, what it does not block, who approved it, and when it expires.
6. Remediation and validation feasibility
NIST SP 800-40 Rev. 4 defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. NIST frames patching as preventive maintenance and recommends an enterprise strategy that makes it operational rather than episodic. See NIST SP 800-40 Rev. 4.
The team should know:
- whether a vendor fix or mitigation exists;
- prerequisites and known side effects;
- test coverage;
- maintenance-window availability;
- rollback capability;
- whether evidence should be collected first; and
- how successful remediation will be verified.
A practical response clock
The following model is an operational target, not a universal legal deadline. Adjust it for the asset, industry, contractual commitments, and authoritative vendor instructions.
Within 24 hours: determine exposure and ownership
- Assign an accountable owner.
- Confirm or rule out affected products and versions.
- Identify public, remote, privileged, and trusted access paths.
- Capture vendor and CISA guidance.
- Preserve relevant evidence when exploitation is plausible.
- Apply safe immediate containment where needed.
- Notify the business owner if a critical service is involved.
Within 72 hours: remediate the highest-risk paths
- Patch or mitigate exposed and high-criticality systems.
- Review focused identity, endpoint, application, and network evidence.
- Rotate credentials or secrets only when the evidence and architecture support that action.
- Validate service function and security controls.
- Open controlled exceptions for systems that cannot be remediated.
Within seven days: close evidence gaps
- Re-scan or re-query the asset with an authenticated method.
- Confirm configuration and build state from the system of record.
- Review exceptions with business and risk owners.
- Schedule replacement for unsupported products.
- Record lessons that improve inventory, patching, logging, and change control.
A simple decision matrix
| Known exploitation | Effective exposure | Business criticality | Recommended response |
|---|---|---|---|
| Yes | External or readily reachable | High | Immediate containment, evidence preservation, emergency remediation, executive awareness |
| Yes | Internal but reachable through normal identities or trusted paths | High | Rapid remediation, focused hunting, controlled change and rollback |
| Yes | Strongly isolated | High | Validate isolation, plan accelerated remediation, monitor and document exception |
| Yes | External | Low | Rapid remediation; confirm the asset is genuinely noncritical before accepting delay |
| No | External | High | Use severity, EPSS, vendor intelligence, exposure, and business impact to set priority |
| No | Isolated | Low | Normal risk-based remediation unless other evidence raises priority |
The table is a triage aid. It does not replace technical investigation or an organization’s risk-acceptance process.
Use EPSS correctly
The Exploit Prediction Scoring System publishes a probability from 0 to 1 estimating the likelihood that a CVE will be exploited in the wild during the next 30 days, along with a percentile. It is updated daily.
EPSS is valuable for sorting large queues, especially vulnerabilities not yet in KEV. It should not overrule confirmed exploitation, asset context, or authoritative vendor action. Scores also change over time, so record the score date when using it as evidence.
Separate vulnerability remediation from incident investigation
If an affected system was reachable before remediation, ask two questions:
- Is the vulnerability now mitigated?
- Is there evidence it was exploited before mitigation?
The first may be answered by build verification, configuration inspection, and rescanning. The second may require identity, endpoint, network, web, application, cloud, and administrative evidence. If logs do not exist or were not retained, record the visibility limitation rather than declaring that no compromise occurred.
Require evidence before closure
A defensible ticket should include:
- affected asset and business owner;
- product, version, and evidence source;
- KEV and vendor references;
- exposure assessment;
- business-service impact;
- action taken and timestamp;
- change and rollback record;
- validation method and result;
- evidence reviewed for exploitation;
- residual risk and exception approval; and
- re-scan or replacement date.
For detailed implementation, review CVSS, EPSS, and KEV Vulnerability Prioritization and Vulnerability Remediation SLAs and Rescanning. The weekly cyberattack roundup for July 13–19, 2026 shows how this decision model applies when several newly cataloged exploited vulnerabilities arrive together.
What leaders should measure
Useful measures focus on risk reduction and proof:
- time to identify affected assets after a KEV addition;
- percentage of internet-reachable KEV assets remediated within the target;
- percentage of closures with authenticated verification;
- unresolved exceptions by age and business owner;
- unsupported products with active exploitation risk;
- percentage of high-risk assets with sufficient investigation telemetry; and
- recurrence caused by inventory, ownership, or change-control failure.
A single “patch compliance” percentage can conceal the riskiest exceptions.
Build a prioritization process you can defend
OC Security Audit can independently evaluate whether vulnerability intake, asset confirmation, exposure analysis, remediation, rescanning, and risk acceptance work as designed. Contact OC Security Audit to discuss a focused review.
Prepared and reviewed by Ali Hassani, CISO.
Sources
- CISA Known Exploited Vulnerabilities Catalog
- CISA KEV JSON feed
- CISA BOD 26-04: Prioritizing Security Updates Based on Risk
- CISA BOD 26-04 implementation and forensics guidance
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
- FIRST Exploit Prediction Scoring System
Last fact-checked July 2026. Always use the current CISA entry and vendor advisory when making a remediation decision.