EPSS vs CISA KEV for ranking test findings

EPSS vs CISA KEV: which one sets your remediation floor

If you are facing a backlog of scan and penetration test findings and must decide what gets fixed first, use CISA KEV as the floor and EPSS as the ranking. The two sources answer different questions. The *Known Exploited Vulnerabilities* (KEV) catalog lists CVEs for which CISA has reliable evidence of active exploitation, and an entry must also have clear remediation guidance such as a vendor update. The *Exploit Prediction Scoring System* (EPSS) is a forecast: FIRST's EPSS publishes, for every published CVE and every day, a score from 0 to 1 estimating the probability of exploitation in the wild over the next 30 days, plus a percentile for ranking.

KEV is a short, curated list, so it cannot tell you everything that is risky. A CVE that is not in KEV may still be exploited, and KEV entries are added only after evidence emerges, so a brand-new vulnerability can be serious and absent. EPSS covers far more CVEs, but its score is a prediction, not proof that anyone has attacked a system. Treat any KEV entry in your environment as a must-fix item regardless of its score, and treat EPSS as the way to order everything else. Confirm with your vulnerability management tool whether it ingests KEV and EPSS directly, and how often it refreshes them. Also confirm which of your scanner findings map to a CVE ID, because both sources only work on CVEs.

If you are a federal civilian agency, KEV is not optional. CISA's BOD 26-04, issued on 10 June 2026, carries forward the KEV criteria from BOD 22-01 and requires remediation within prescribed timeframes, so confirm those timeframes in the directive itself. Other organizations are strongly encouraged to prioritize KEV entries too, and regulated entities should check whether their supervisor expects it. A practical rule for a remediation SLA: any finding on KEV goes to the front of the queue, and within the remaining findings, sort by EPSS percentile and then by your own asset criticality, so a high-probability flaw on an exposed system beats a higher CVSS score on an isolated one. Record the rule in your vulnerability management policy so that auditors and penetration testers see the same order.

How EPSS vs CISA KEV differ on purpose, coverage and output

This table compares what each source answers, what it outputs, how often it changes, and what it means for a test finding. Read it as a guide to which signal to use for which decision, since the two are designed to be combined rather than swapped.

Factor	EPSS	CISA KEV
Question it answers	How likely is this published CVE to be exploited in the wild in the next 30 days?	Has this vulnerability been confirmed as exploited in the wild?
Output format	A score from 0 to 1 with a percentile for every CVE	A catalog entry for each listed vulnerability
Time horizon	Forward-looking, next 30 days	Backward-looking, confirmed past or active exploitation
Update frequency	Published every day	Entries added as evidence is confirmed
Scope of CVEs covered	Every published CVE	Only curated CVEs with confirmed exploitation
Inclusion rule	Model-based estimate, no confirmation needed	Requires a CVE ID, reliable evidence of active exploitation, and clear remediation guidance
Who maintains it	FIRST	CISA
Access	Free CSV files, an API and a GitHub repository	Published on the CISA website as the authoritative catalog
What it means for a test finding	Use to rank findings that are not yet on KEV	Treat a listed finding as a minimum priority to fix

What KEV inclusion requires and why the list stays short

A vulnerability enters the CISA Known Exploited Vulnerabilities catalog only when three conditions hold at once: it has a CVE ID, there is reliable evidence of active exploitation, and there is clear remediation guidance such as a vendor update. Each condition filters out candidates that might otherwise look urgent. A flaw without a CVE ID cannot be listed, and a flaw with no fix gives the catalog nothing actionable to tell an operator. The exploitation test is the strictest of the three, and it is the one that determines whether a finding is on the list at all.

Scanning activity, security research and public proof-of-concept code do not count as evidence of exploitation under this test. For your team, this means a finding that is severe, network-reachable and has a working exploit published on a research site can still be absent from KEV. Its absence says only that CISA has not confirmed exploitation in the wild, not that the flaw is safe. Keep the finding in your queue with its own ranking, record the date you checked the catalog, and recheck it on a fixed schedule, because a later confirmation can add the CVE without any change to the flaw itself.

KEV is an input to prioritization, not a full risk register. It answers one question, whether a known CVE has been confirmed as exploited, and it says nothing about your exposure, asset value or compensating controls. Confirm with your scanner and asset inventory which KEV entries touch systems you actually run, and treat the catalog as a floor that guarantees minimum urgency. Anything above the floor still needs a separate ranking, which is where a probability model and your own business context come in.

What each one finds and misses in your estate

KEV and EPSS answer different questions about the same CVE: whether exploitation has been confirmed, and how likely exploitation is next. The four cards show where each source helps with scanner and penetration test findings, and where it needs your own asset data to be useful.

What KEV finds

KEV lists CVEs that CISA has confirmed are exploited in the wild and that have clear remediation guidance, such as a vendor update. When a scan or penetration test reports a finding whose CVE ID is in the catalog, that finding has evidence of active attack behind it and a known fix. Match CVE IDs against the catalog on every scan cycle, and place matches at the top of your remediation queue. Confirm the affected version range against the vendor advisory before scheduling the patch.

What KEV misses

KEV is deliberately narrow. A CVE disclosed recently, a flaw with public proof-of-concept code, or a critical scanner finding that no one has observed being exploited will not appear in the catalog. CISA requires reliable evidence of active exploitation, and scanning activity and research do not meet that bar. A penetration test that chains several medium findings can produce a serious attack path with no KEV entry, so review unlisted high-severity findings through a separate process.

What EPSS finds

EPSS estimates the probability that a published CVE will be exploited in the wild within the next 30 days, and it publishes a score from 0 to 1 with a percentile for every CVE each day. That covers the long tail of findings that KEV leaves out, so a large scan backlog can be ranked by forecast instead of left in severity order. Join daily scores to your scanner output by CVE ID, and use the percentile to order findings that share a similar score.

What EPSS misses

EPSS is a forecast, so it can be wrong in both directions: a CVE with a modest score can be exploited quickly, and a high score can pass without any attack. The model also knows nothing about your estate. A high score on a service behind a firewall with no internet route is still a finding on a host you may not expose. Confirm reachability, authentication requirements and compensating controls from your own scan and test data before you raise or lower a priority.

How BOD 26-04 changes duties for federal and other organizations

BOD 26-04, issued on 10 June 2026, is a binding directive for federal civilian agencies. It carries forward the KEV inclusion criteria from BOD 22-01 and requires agencies to remediate KEV vulnerabilities within prescribed timeframes. For these organizations, KEV is not one input among many. It sets a minimum remediation obligation that operates regardless of the EPSS score or the CVSS rating of a given finding.

Binding scope: The directive applies to federal civilian agencies, and the duty to remediate is an obligation, not a recommendation.
Continuity of criteria: The inclusion criteria carry forward from BOD 22-01, so agencies familiar with that directive can reuse their understanding of what qualifies for the catalog.
Prescribed timeframes: Remediation deadlines are set in the directive text rather than chosen by each team, so a KEV entry starts a clock.
Ranking still applies: EPSS can order work that falls outside KEV, but it does not waive a KEV remediation duty.
Records: Agencies should be able to show when each KEV entry was identified and when it was remediated.

Confirm the exact timeframes and reporting expectations in the directive text itself and with your agency's governance office before setting internal deadlines.

What you receive from a KEV and EPSS prioritization exercise

This table compares the outputs of a self-run KEV and EPSS process with those of an outside engagement, and marks which items you keep after handover and which need a written scope to produce. Read it as a checklist for asking what a provider will hand over and what your own team must be able to reproduce.

Deliverable	Self-run process	Outside engagement (written scope)
Ranked remediation queue	Built by your team from scanner output joined to KEV and EPSS data; you own the logic and must rerun it daily or weekly.	Delivered as a ranked list for your asset set, with the ranking method stated; confirm refresh cadence and handover format in the scope.
KEV match report by CVE ID	Produced by matching your findings against the CISA KEV catalog; you own the query and the audit trail of the match date.	Delivered as a CVE-level match table with the catalog date used; confirm whether it covers only KEV entries or also near-matches.
EPSS score and percentile per finding	Pulled from FIRST's daily CSV or API; you must record the snapshot date, because scores change each day.	Delivered as a snapshot per finding with the source date; confirm whether the scope includes ongoing refresh after handover.
Documented thresholds and exception records	Thresholds and exceptions are yours to write, approve and review; they stay valid only while someone maintains them.	Drafted as a policy annex and exception log for your approval; the scope should name who signs off and how often it is reviewed.
Evidence for auditors or regulators	Consists of your own tickets, dated exports and approvals; the evidence quality depends on your record keeping.	Packaged as a dated evidence set mapped to your internal control wording; it prepares evidence and does not replace an independent auditor's opinion.
Analyst walkthrough and runbook	Your team learns the method through trial and error unless documentation exists.	Delivered as a written runbook and walkthrough session; confirm which team members attend and the session count in the scope.
Federal remediation timeframes under BOD 26-04	Applies to federal civilian agencies; other organizations use KEV as a prioritization input.	Scope should state whether your organization is a federal agency, since this changes which remediation duties apply.

How to use KEV as a floor and EPSS as a ranking

This sequence turns a list of raw test findings into a ranked remediation queue in which every known-exploited vulnerability is scheduled first and the rest are ordered by likelihood of exploitation, adjusted for what the business actually runs. Each step ends with a record that an auditor or a board member can trace back to the source data.

Map every finding to a CVE identifier
The assessment team or the vulnerability management lead reviews each penetration test or scanner finding and records the CVE ID where one exists. Findings without a CVE, such as misconfigurations, weak design choices or application logic flaws, go into a separate track because neither KEV nor EPSS scores them. Confirm that each finding also names the affected asset, version and patch status, since the same CVE can be exploitable on one host and irrelevant on another. The step is done when every finding is either mapped to a CVE or explicitly routed to the non-CVE track.
Check each CVE against the KEV catalog
Compare every mapped CVE against the CISA Known Exploited Vulnerabilities catalog. CISA lists a vulnerability only when it has a CVE ID, reliable evidence of active exploitation and clear remediation guidance, so a match is a strong signal that attackers are using the flaw. Treat any match as a floor: the item is scheduled for remediation within the tier your policy sets for KEV entries, regardless of its EPSS score or CVSS base score. The output is a KEV-matched list with the catalog date each entry was checked, so the decision can be reproduced later.
Pull EPSS scores and percentiles for the remaining CVEs
For the CVEs that are not in KEV, retrieve the current EPSS probability and percentile from FIRST's daily data through the CSV files, the API or the GitHub repository. EPSS estimates the probability of exploitation in the wild over the next 30 days, so record the score date alongside each value. Store the score and percentile in the finding record. The check is complete when every non-KEV CVE has a dated EPSS value, and any CVE with no published score is flagged for manual review rather than assumed to be low risk.
Order the queue by EPSS with asset context
Rank the non-KEV findings by EPSS score, then adjust the order for asset criticality and exposure. A high-EPSS flaw on an internet-facing system that holds regulated data usually moves ahead of a high-EPSS flaw on an isolated test host, while a low-EPSS flaw on a crown-jewel system may still need attention. Document the adjustment rules in the queue itself so each change of position has a stated reason. The output is an ordered remediation backlog in which every item shows its KEV status, EPSS score, percentile and asset context side by side.
Set written SLA tiers and thresholds
Agree the remediation tiers with the risk owners and write them into the vulnerability management policy. Tiers typically separate KEV matches, high-EPSS items on exposed assets and everything else, but the cut-off values, timeframes and approval routes are a client decision, not a DeployOpen or FIRST default. Ask the policy owner to confirm how the tiers align with any contractual, regulatory or internal commitments that apply to your environment. The step closes when the signed policy names each tier, its threshold and its owner.
Schedule reviews and rescore on a fixed cadence
Set a review cadence for the queue and rescore it as new data arrives, because EPSS values change daily and KEV entries are added over time. At each review, the owner re-pulls EPSS for open items, checks the KEV catalog for newly listed CVEs and moves any item that has changed tier. Record the date of each review and the changes made. The cadence is in place when the review schedule appears in the policy and a dated log shows that the queue was refreshed against current data.
Record exceptions with an owner and expiry
Some items cannot be fixed within their tier, for example when a vendor patch is unavailable or a change freeze applies. Record each exception with the CVE, the affected asset, the compensating control, the named risk owner and an expiry date that the owner has approved. Exceptions to KEV floors deserve the closest review because those flaws have confirmed exploitation. The output is an exception register that a reviewer can audit, and the register is reviewed at the same cadence as the queue.

What drives cost and effort in a prioritization program

A prioritization program using EPSS and KEV costs less in licenses than in people's time: mapping assets, normalizing findings, moving decisions into tickets and recording exceptions. The cards below separate one-time setup from recurring work, and name the party paid for each item so you can ask for the right lines in a quote.

Asset inventory and CVE mapping

A KEV or EPSS score means little until it is tied to a system that matters to your business. Someone must map CVEs to installed products, versions and owners, which is the largest one-time effort in most programs. Ask whether the quote includes building the inventory or only consuming one you already maintain, and who keeps it current as hosts change. The effort recurs whenever new assets are onboarded.

Scanner and pentest normalization

Scanners, penetration test reports and code analysis tools name the same weakness differently and report different affected versions. Normalizing them into one list keyed by CVE, asset and status is needed before EPSS and KEV can rank anything. Confirm whether the scope covers mapping duplicate findings, handling non-CVE findings such as misconfigurations, and who reviews the output before it reaches the queue.

EPSS and KEV data pipeline

FIRST makes EPSS data freely and openly accessible through CSV files, an API and a GitHub repository, so the feed itself carries no license fee. The recurring cost is the job that downloads, stores and joins the daily scores to your inventory, and the team that keeps it running. For KEV, confirm the terms of access and the update mechanism with CISA before you design the pipeline around it.

Ticketing and patch workflow integration

A ranking only changes outcomes if it creates or reprioritizes tickets in the system engineers already use. Integration work covers mapping scores to priority fields, setting SLA clocks per tier, and closing tickets when a patch is verified. Ask who builds and maintains the connector, what happens when the ticketing schema changes, and whether vendor patch dependencies are visible in the workflow.

Governance and exception handling

Every program needs a written decision on what happens when a KEV entry cannot be patched, such as a vendor fix that is not yet available or a system that cannot be taken offline. Exceptions need an owner, a compensating control, an expiry date and a review path. This work is mostly internal policy effort, though a consultant can draft the policy and the exception register template. Confirm who approves exceptions and how evidence is kept for assessors.

Ongoing retainer support

Scores change every day and the asset estate changes continuously, so a program that worked at launch can drift within months. Retainers cover tuning thresholds, reviewing new KEV additions against your inventory, upgrading connectors and reporting. Ask whether the retainer is fixed in scope, what response expectations apply to new KEV entries, and which tasks stay with your staff. Quotes are built from written scope, so list each recurring task explicitly.

What buyers ask before hiring help with prioritization

Can we run KEV and EPSS in-house without outside help?

Yes, many teams do. Both sources are public and free to use: EPSS publishes CSV files, an API and a GitHub repository, and CISA publishes the KEV catalog. The harder part is the internal work that turns those lists into decisions: matching CVE IDs to assets you actually run, deciding who owns each fix, and keeping the process running every week. Ask yourself whether your team has someone who can own that loop, not whether the data is accessible. If the answer is no, a fixed-scope engagement can build the process and hand it over.

How long does setting up KEV and EPSS prioritization take?

The duration depends on your environment, and no fixed figure applies to every team. The main drivers are how many scanners and asset sources you have, how clean your asset inventory is, whether scanner output already carries CVE IDs in a usable format, how many ticketing queues need changing, and how many named owners must agree on SLAs. A team with one scanner and a current inventory will move faster than one with several scanners, duplicate hostnames and no agreed owners. Ask any provider for a written timeline that lists these dependencies and the assumptions behind each one.

What does the work need from our team?

Expect to supply four things: an asset inventory with owners, exports from your vulnerability scanners and penetration test reports, read and write access to the ticketing system where remediation work is tracked, and named owners who can accept risk or approve a remediation window. Without asset data, a KEV match cannot tell you whether the affected system is internet-facing or business critical. Without ticket access, the ranking never reaches the people who fix things. Confirm these inputs in writing before work starts, and confirm who signs off on exceptions.

Is EPSS alone enough to prioritize vulnerabilities?

No. EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days, so it ranks by likelihood, not by confirmed activity. KEV lists vulnerabilities with reliable evidence of active exploitation, a CVE ID and clear remediation guidance, so it works as a floor you should not drop below. Use KEV entries as mandatory priority, then sort the remaining backlog by EPSS and your own asset context. FIRST's own guidance covers combining EPSS with CVSS and KEV, which is the approach most mature programs adopt.

What changes under BOD 26-04 for federal agencies?

BOD 26-04, issued on 10 June 2026, carries forward the KEV criteria from BOD 22-01 and requires federal civilian agencies to remediate KEV vulnerabilities within prescribed timeframes. Agencies should check the directive text for the exact deadlines that apply to them. Organizations outside the federal civilian scope are not bound by the directive, but CISA strongly recommends that they prioritize KEV entries too. If you are a contractor or a regulated entity with federal dependencies, confirm with your contracting officer or compliance lead which obligations flow down to you.

How often do EPSS scores and the KEV catalog change?

EPSS publishes a score and percentile for every CVE every day, so scores can move between runs as exploitation evidence and CVE data change. The KEV catalog changes when CISA adds or updates entries, which happens as evidence of active exploitation emerges, so the list is not static. For operations, build a daily or regular import, store the date of each pull, and record which version of the data drove each ticket. That history lets auditors and managers see why a finding was ranked where it was on a given day.

What should a fixed-scope prioritization engagement specify in writing?

Most engagements are fixed-scope, so the written agreement should define the scope, deliverables and timelines before work starts. Ask it to list the in-scope asset sources and scanners, the data feeds to be used (EPSS and KEV), the ranking rules and how KEV entries override EPSS, the ticketing integrations and their owners, the handover format and training, the acceptance criteria, and what is excluded, such as remediation work itself. It should also state who is responsible for each input, what happens when a required input is late, and how changes to scope are priced. DeployOpen does not publish a price list, so ask for a quote that follows from this written scope.

How DeployOpen scopes and supports vulnerability prioritization

DeployOpen helps teams put EPSS and CISA KEV into their own vulnerability management workflow, inside their own infrastructure. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm which scanners and penetration test report formats feed the prioritization workflow
Agree in writing whether KEV acts as a mandatory floor and EPSS as the ranking within each band
Define which asset groups, data sources and EPSS and KEV feed refresh routines are in scope

How we build

Map KEV membership and EPSS percentiles onto existing finding fields in your ticketing or reporting tools
Set up scheduled retrieval of the daily EPSS data and the KEV catalog in your environment
Test the ranking logic against a sample of past findings so reviewers can check the outputs

How we hand over

Document the decision rules, data sources, refresh schedule and exceptions process in writing
Record how federal BOD 26-04 duties differ from voluntary KEV use, so your owners know which applies
Train the people who triage findings to read EPSS scores, percentiles and KEV status correctly

How we support

Offer ongoing support, upgrades and reviews of the prioritization rules as retainers
Revisit the thresholds with your risk owners when the scope of assets or regulations changes
Confirm with your auditors or regulator which evidence of prioritization they expect to see

EPSS vs CISA KEV