EPSS Score vs CVSS vs CISA KEV: 4 Ways to Triage [2026]

Security teams sit on the same problem every Monday: thousands of open findings, a handful of people, and four different numbers that all claim to say which bug matters first. On October 13, 2026, CISA added Ivanti Connect Secure CVE-2026-104935 to its Known Exploited Vulnerabilities catalog after reporting active exploitation of a zero-day authentication bypass that gives attackers unauthenticated remote command execution. Three days later it added a critical authentication bypass in BeyondTrust Remote Support (CVE-2026-102764, versions 26.2.3 and earlier). Neither addition waited for a score to cross a threshold. Confirmed attacks put them on the list.

That is the whole argument of this comparison in one paragraph. The EPSS score, the CVSS score, CISA KEV membership and an SSVC decision are not four versions of the same answer. They answer four separate questions: how bad could it be, how likely is exploitation soon, is anyone exploiting it right now, and what should we do about it. Teams that treat them as rivals end up with a queue sorted by the wrong thing. Teams that stack them in the right order cut the pile down to a list people can actually work through. If you already run a CISA KEV patch workflow, this article shows where EPSS, CVSS and SSVC slot in around it.

The short verdict, backed by the sections below: treat KEV membership as the override, use the EPSS score to rank everything that is not on KEV, keep the CVSS score as the severity label and as an input to impact, and adopt SSVC when you need a written, defensible decision rather than a number. All four are free to use. The cost is analyst time, which is exactly why the order matters. Every figure in this piece comes from the maintainers’ own pages or from dated reporting we checked on October 25, 2026, and where the evidence is thin we say so instead of filling the gap.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What Each Score Actually Measures

The confusion starts with vocabulary. People say “risk score” for all four, but none of them measures risk on its own. Risk needs a threat, a weakness and an asset worth something to you. Each system covers one slice of that triangle, and none covers all three. Reading the slices correctly is the difference between a defensible queue and a pile of red badges.

CVSS: how severe is the flaw in isolation

The Common Vulnerability Scoring System, maintained by FIRST, rates the technical severity of a vulnerability. It looks at how an attacker reaches the bug, how hard the attack is, what privileges and user interaction it needs, and how much confidentiality, integrity and availability damage follows. The output is a vector string plus a number on a 0 to 10 scale. CVSS v4.0, published in November 2023, is the newest major version, and v3.1 is still everywhere in vulnerability databases and vendor advisories. The CVSS score says nothing about whether anyone is attacking the flaw today. A 9.8 can sit unexploited for years, and an 8.8 can be burning down networks this week.

EPSS: how likely is exploitation in the next 30 days

The Exploit Prediction Scoring System, run by an EPSS special interest group at FIRST, returns a probability between 0 and 1 that a published CVE will see exploitation activity in the following 30 days. The EPSS score refreshes daily, covers every public CVE, and ships as a free CSV and JSON feed. It is a forecast, not a verdict. It does not know your asset inventory, your compensating controls or whether the vulnerable service faces the internet. It also reports a percentile next to the probability, and the two numbers mean different things. A bug in the 90th percentile is not 90 percent likely to be attacked. It is simply scored higher than 90 percent of other CVEs.

CISA KEV and SSVC: what is already happening, and what to do

The Known Exploited Vulnerabilities catalog is a list, not a scoring model. A CVE appears on it when CISA has evidence of exploitation in the wild, and that evidence is the entire point. SSVC, short for Stakeholder-Specific Vulnerability Categorization, is a decision framework. It walks a team through a small set of questions such as exploitation status, whether the attack can be automated, and technical impact, then lands on an outcome. CISA’s version uses four: Track, Track*, Attend and Act. Where CVSS and EPSS give you a number to sort by, KEV and SSVC give you a category and a recommended action.

Put the four side by side and the layering becomes obvious. CVSS describes the bug, EPSS forecasts the attacker, KEV records what attackers already did, and SSVC turns those inputs plus your context into a decision. The rest of the article tests that mental model against current data and against October 2026 cases. For readers who follow our wider cybersecurity coverage, the same layering explains why so many zero-day stories end up on KEV within days.

EPSS Score vs CVSS vs CISA KEV vs SSVC: Specs Table

The table below lines up the four systems on fourteen attributes. Version names, dates and prices come from FIRST, CISA and CERT/CC material checked on October 25, 2026. Where an attribute depends on how a team uses the system rather than on a published fact, the cell describes the design, not a measurement.

Attribute	CVSS	EPSS	CISA KEV	SSVC
Maintainer	FIRST	EPSS SIG at FIRST	CISA	CERT/CC, with a CISA methodology
Question it answers	How severe is the flaw?	How likely is exploitation soon?	Is it exploited in the wild?	What should we do?
Output	Vector plus 0 to 10 score	Probability (0 to 1) plus percentile	Catalog entry (in or out)	Track, Track*, Attend or Act
Newest version	CVSS v4.0 (Nov. 2023)	EPSS v5, build v2026.06.15	Single living catalog	SSVCv2
Predecessor still in use	CVSS v3.1	EPSS v4 (published from March 17, 2025)	None	Not applicable
Update rhythm	Set per CVE, rescored when corrected	Daily	When exploitation evidence arrives	Per decision
Looks at active exploitation	No	Indirectly, through data inputs	Yes, that is its definition	Yes, as a decision point
Forecasts the future	No	Yes, 30-day window	No	No, reflects current state
Uses your environment	Only if you fill in environmental metrics	No	No	Yes, stakeholder-specific
Covers every public CVE	Most published CVEs	Every public CVE	Only exploited ones	Only CVEs you assess
Price	No fee identified	$0	$0	No separately priced product
Machine-readable	Vector strings in CVE and advisory records	CSV and JSON feeds	Public catalog feed	Fields in CISA CVE records and ICS advisories
Typical owner	Scanner and ticketing teams	Vulnerability management	Patch and IR teams	Risk and policy owners
Main blind spot	Ignores attacker behavior	Ignores your assets	Lags first exploitation	Needs effort to operate

Two details in that table deserve a second look. First, EPSS moved to a new generation this summer, so any guide that still describes EPSS v4 as current is out of date. Second, SSVC is no longer just a research proposal. CISA publishes SSVC fields operationally, and a description of the framework as experimental would be wrong in October 2026.

CVSS in 2026: v4.0 Is Current, v3.1 Is Everywhere

CVSS v4.0 has been the newest version for nearly three years, yet reporting through October 2026 keeps showing both generations side by side. A Veracode briefing dated September 30, 2026 gave one vulnerability a v3.1 score of 9.8 and a v4.0 score of 9.3. Same flaw, same week, two numbers. CISA’s ICS advisories show the same split. The Hitachi Energy MicroSCADA X SYS600 advisory lists a v3.1 vector next to a v4.0 vector for each CVE, and the v4.0 vectors add fields such as attack requirements (AT) and subsequent-system impact (SC, SI, SA) that v3.1 never had. If your scanner exports only one version, you are not comparing like with like when a vendor quotes the other.

The score itself also moves after publication. A tracker reported that the National Vulnerability Database rescored CVE-2026-109619, one of the two PHP flaws behind the PHP2Shell wave, from 9.8 to 8.1 on its CVSS 3.1 scale on October 22, 2026. Treat that as a reported change, not an official statement, but the pattern is real. Initial scores come from a hurried first read and get corrected later, which means a rule like “patch everything at 9.0 or above within seven days” can flip a ticket between buckets overnight without any change in actual danger.

Severity still earns its place. When two bugs carry the same exploit signal, the one that allows unauthenticated remote code execution deserves attention before the one that leaks a low-value field. That is what CVSS is good at. It also makes a decent common language between vendors, auditors and customers, which is why contracts and compliance frameworks still cite it. The problem arrives when CVSS becomes the only sort key. The Cisco and SonicWall zero-days that reached KEV confirm what the score is good at, but a score alone cannot separate flaws like those from the hundreds of critical-rated bugs nobody has touched.

One practical point for teams mid-migration: pick a version per workflow and say so in the ticket. Use v4.0 where your tooling supports it, keep v3.1 where regulators or customers still ask for it, and never average the two. The vector string is the real data. The number is a rendering of it.

EPSS Score: What v5 Changed on June 15, 2026

FIRST deployed EPSS v5, model build v2026.06.15, on June 15, 2026. It replaced EPSS v4, which had been publishing since March 17, 2025. According to FIRST’s announcement, the refresh brought a general model update, better detection of exploit code on GitHub, an improved calibration step, VulnCheck KEV data and GitHub popularity metrics as inputs, plus a few smaller changes. FIRST describes the system as producing updated exploitation-probability scores for every public CVE, with daily retraining behind it. Jay Jacobs, lead data scientist on EPSS and co-chair of the EPSS SIG, is the named figure behind the project. As of October 25, 2026 we found no model release newer than v2026.06.15.

One point helps with scale. EPSS publishes updated exploitation-probability scores for every public CVE, with daily scores available through a CSV feed. What matters for planning is the shape of the data: most CVEs sit at very low probabilities, and a small tail climbs high. That skew is exactly why the EPSS score works as a filter. You do not need to chase everything above a medium severity if the probability of attack sits near zero.

A subtle point from the v5 inputs: KEV data feeds the model. That makes KEV and EPSS related rather than independent, and it explains why a bug added to a KEV list usually shows an elevated EPSS score soon after. It also means you should not count a high EPSS score and a KEV listing as two separate confirmations. Treat KEV as the stronger fact. The EPSS score is the forecast for everything that has not yet earned a place on the list.

Where does the score fail? It cannot see your environment, so a vulnerability in software you never deployed can score high, and an internal-only bug can score low even though a compromised laptop makes it reachable. It also reacts to public signals, which means a freshly disclosed flaw with no public proof of concept starts low and can jump within days. A case like the Nextcloud Collabora flaw that saw web shells planted shows how quickly attackers can move after disclosure. Re-pull the file every day, and alert on score changes, not just on absolute values.

CISA KEV: The Catalog That Settles the Argument

KEV holds a simple promise: every entry has evidence of exploitation in the wild. In practice that makes it the cleanest signal in vulnerability management, because it removes the guesswork. The October 13 and October 16 additions are typical. Ivanti Connect Secure CVE-2026-104935 arrived with confirmed zero-day abuse, and BeyondTrust Remote Support CVE-2026-102764 followed. A report on catalog version 2026.10.23 counted 1,756 vulnerabilities, 361 of them marked as used in ransomware campaigns. Both numbers come from a single report, so treat them as a snapshot, since counts from October 20 and 21 were already a couple of entries lower.

For federal agencies, KEV carries remediation due dates. Pyramid Systems’ October 24 write-up covers those deadlines under CISA’s BOD 26-04. Private companies face no such mandate, but the deadline culture spreads. Insurers, auditors and customers increasingly ask whether you patched KEV entries on time. Our coverage shows the pattern repeatedly. The FortiMail zero-day is a clean example of a mail-security bug reaching the catalog, and when ransomware gangs hit a VMware bug, the compressed deadline CISA set showed how short the response window can get.

KEV has three limits you should plan around. It lags first exploitation, because CISA needs evidence before listing. It is biased toward products and sectors that defenders and researchers watch closely, so obscure software can be exploited long before it appears. And it says nothing about the thousands of vulnerabilities that attackers never touch, which is the part of the queue EPSS and CVSS have to sort. A related point from the October reporting: CISA also publishes ICS advisories that explicitly state no known public exploitation. Those are not KEV additions and should not trigger a KEV-style response.

SSVC: The Decision Tree CISA Runs in Public

SSVC works differently from the other three. It does not hand you a number. It asks a short series of questions and ends in an action. The version CISA uses relies on decision points such as exploitation status, automatable or not, and technical impact, and it ends in one of four outcomes: Track, Track*, Attend or Act. CISA records these decisions in CVE records, and its public vulnrichment repository has published SSVC assessments for CVEs since early 2024, according to an October 5, 2026 analysis from 543HQ. In other words, you can read how a government agency triages and copy the logic.

Recent records show the framework at work. The October 13 Ivanti record lists active exploitation, automatable exploitation and total technical impact. That combination describes the worst case on the tree, and it should map to the top outcome. On October 21, enrichment for two other vulnerabilities recorded active exploitation, non-automatable exploitation and total technical impact, a meaningfully different profile that suggests attacks need hands-on effort. Same exploit signal, different urgency. A single score would flatten that difference, which is exactly what SSVC is designed to avoid.

The CERT/CC documentation describes SSVC as living, modular guidance with separate decision methods for CISA, for coordinators, for deployers and for suppliers. That flexibility is the strength and the cost. A deployer tree asks about your systems, so two companies can reach different outcomes on the same CVE, and both can be right. The price is effort. Someone has to answer the questions per asset class and keep the answers current. For a team that wants an audit trail, that effort is worth it. For a team with one analyst and thousands of findings, start with KEV and EPSS and adopt SSVC for the narrow set that remains. The LiteLLM flaw, the first MCP-related entry CISA flagged, is the kind of new-category case where a written decision beats a lookup table.

What the Maintainers Say: Five Verbatim Quotes

The best way to avoid misusing these systems is to read what their authors say about them. The three quotes below come from the FIRST EPSS project documentation. They define the score, mark its limits and settle the KEV question.

The EPSS score is a calibrated probability: the estimated likelihood that exploitation activity for a given vulnerability will be observed across EPSS data partners in the next 30 days.

FIRST EPSS project, EPSS project documentation

Not a “severity” score and not a complete risk score.

FIRST EPSS project, EPSS project documentation

As a general rule of thumb: when a vulnerability appears on CISA KEV, treat it as actively exploited and prioritize accordingly, regardless of EPSS score.

FIRST EPSS project, EPSS project documentation

The first quote makes the EPSS score a probability tied to a 30-day window and to the data partners that feed it. The second blocks the most common misuse, which is reading a high EPSS score as a high CVSS score. The third is the rule of thumb most teams should print and pin: KEV beats EPSS every time. FIRST wrote that sentence about its own product, which makes it unusually credible.

The CERT/CC team behind the SSVC documentation draws a similar line between predicting and observing.

The intent is not to predict future exploitation but only to acknowledge the current state of affairs.

CERT/CC SSVC project, SSVC documentation

Predictive systems, such as EPSS, could be used to augment this decision or to notify stakeholders of likely changes.

CERT/CC SSVC project, SSVC documentation

Read together, the five statements describe one stack. SSVC records the current state of exploitation, EPSS adds a forward-looking signal, and KEV overrides both when exploitation is confirmed. None of the maintainers claims their system works alone.

Evidence and Benchmarks: What the Public Record Shows

Readers often ask for a head-to-head benchmark, such as “EPSS catches X percent of exploited bugs with Y percent of the effort.” We looked for current, dated, independently verifiable figures of that kind and did not find any we could confirm against primary pages on October 25, 2026. Rather than quote percentages from vendor blogs we could not check, we list the evidence we can stand behind and explain how to read each piece. Treat it as a map of sources, not a leaderboard.

Source	Date	What it shows	How to read it
FIRST EPSS documentation	Current	EPSS is a 30-day exploitation probability, not severity	Defines the score’s scope and its limits
FIRST EPSS v5 announcement	June 15, 2026	Model refresh, new inputs including VulnCheck KEV data	Confirms EPSS v5 is the current generation
CISA Ivanti alert	Oct. 13, 2026	Zero-day exploited, added to KEV	KEV reacts to confirmed attacks, not to scores
CISA BeyondTrust alert	Oct. 16, 2026	Critical auth bypass added to KEV	A second KEV addition within three days
CERT/CC SSVC documentation	Current	Decision points and outcomes	Shows what a decision model asks beyond a score
Veracode weekly briefing	Sept. 30, 2026	One flaw rated 9.8 (v3.1) and 9.3 (v4.0)	Version choice changes the number
Brinqa Patch Tuesday analysis	Oct. 15, 2026	Ranks monthly CVEs by exploit risk, not only severity	Practitioner use of exploit signals
FIRST 2026 vulnerability report	Feb. 11, 2026	Projects a record year for published CVEs	Explains why volume now outruns severity-only triage

The Brinqa analysis of the October 2026 Patch Tuesday is a good illustration of how practitioners already work. Its headline counts 1,411 CVEs and a single zero-day in the release, which is the kind of volume that makes a pure severity sort useless. A single zero-day is the signal, and the rest of the list is a ranking problem. That is the practical case for layering: the volume is too high for CVSS alone and the confirmed-exploitation list is too short to cover everything.

Three conclusions follow from the evidence. First, no source we checked treats a single score as sufficient. FIRST warns against reading EPSS as severity, CERT/CC frames SSVC as a decision aid, and CISA records exploitation separately from scoring. Second, the data points we can verify all lean the same way, with confirmed exploitation outranking forecasts and forecasts outranking raw severity. Third, the gap in public head-to-head efficiency studies is itself a finding. If you need numbers for your own environment, run a backtest against your last twelve months of tickets, as the migration guide below describes.

Real-World Examples From October 2026

Theory is easy. Here are seven recent cases and how each system would have treated them.

1. Ivanti Connect Secure CVE-2026-104935 (October 13). A zero-day authentication bypass with unauthenticated command execution. KEV listed it on the day CISA’s alert went out. The SSVC record shows active exploitation, automatable and total impact. Any queue that waited for an EPSS update or a CVSS rescore would have lost days.
2. BeyondTrust Remote Support CVE-2026-102764 (October 16). A critical authentication bypass in versions 26.2.3 and earlier, added to KEV three days after Ivanti. Remote support tools sit on privileged paths, so the KEV listing alone justifies emergency change control.
3. A Microsoft Windows flaw, CVE-2026-96951 (October 13). CVETodo lists it at CVSS 8.8, which is high but below the usual critical line, and reports tie it to the same October 13 KEV additions. A policy that only escalates at 9.0 would have missed it. This is the clearest argument for a KEV override.
4. The Veracode example (September 30). One flaw, two scores: 9.8 on v3.1 and 9.3 on v4.0. Both are critical, so the bucket survives, but the lesson is that a 0.5 gap can decide whether a rule fires when thresholds sit at 9.5.
5. Hitachi Energy MicroSCADA X SYS600 and RTU500 (September to October). CISA’s ICS advisories pair v3.1 and v4.0 vectors with an SSVCv2 string. One MicroSCADA entry carries the string SSVCv2/E:N/A:N dated September 28, 2026, which reads as no known exploitation and not automatable. For RTU500 CMU firmware, the fix path runs from affected builds such as 13.8.1 to 13.8.2. That mix of severity vector, decision string and concrete upgrade path is what asset owners in operational technology actually need.
6. EseeCloud app and firmware (initial release October 15). A CISA ICS advisory covering EseeCloud App 4.9.6 and earlier and firmware 4.9.86.0 and earlier, tied to CVE-2026-107617, CVE-2026-97858 and CVE-2026-105664. IoT products rarely appear on KEV early, so severity vectors and device exposure carry the weight until exploitation evidence appears.
7. PHP2Shell CVE-2026-109619 (October 22 rescore). The reported drop from 9.8 to 8.1 on the v3.1 scale is a reminder that scores shift after publication. Teams that tied SLAs to the original number needed to re-triage. Teams that keyed on exploitation signals were less exposed to the swing.

Across all seven cases, the signal that changed behavior was never the severity number alone. It was exploitation evidence (Ivanti, BeyondTrust, the Windows flaw), a decision record (Hitachi Energy) or a correction to a published score (PHP2Shell). The same logic applies to edge appliances. When the Citrix NetScaler zero-days drew a three-day CISA deadline, the listing mattered more than any score attached to it.

Pricing and Cost: Every Score Is Free, Triage Time Is Not

We found no license fee for EPSS, CISA KEV or SSVC. EPSS daily data is available as free CSV and JSON feeds, and CISA KEV is public at $0. We found no separately priced SSVC product or plan. For CVSS, we could not confirm a price from the sources we checked. What you do pay for sits around the edges, in tooling that ingests the feeds and in analyst hours.

System	License or plan cost	Access	Where the real cost sits
CVSS	No fee identified	Vectors in advisories, CVE records and scanners	Keeping v3.1 and v4.0 straight across tools
EPSS	$0	Daily CSV and JSON feeds	Daily ingestion and score-change alerting
CISA KEV	$0	Public catalog and feed	Matching entries to your asset inventory
SSVC	No separately priced product	CERT/CC documentation, CISA methodology and calculator, vulnrichment data	Answering decision questions per asset class

The sensible budget question is therefore not “which score do we buy” but “who runs the pipeline.” A small team can wire KEV and EPSS into a spreadsheet or a short script in a day. Commercial scanners and exposure platforms often bundle these signals already, so check your existing vulnerability management contract before building anything. If your scanner shows an EPSS column and a KEV flag, you are most of the way to a layered queue without spending a dollar.

Pros and Cons of Each Score

CVSS

• Pros: universal, published with nearly every CVE, understood by auditors and vendors, v4.0 adds finer impact fields, vector strings carry real detail.
• Cons: ignores attacker activity, two versions in circulation, scores get revised after publication, easy to misuse as a priority list.

EPSS

• Pros: free, daily, covers every public CVE, forward-looking, easy to automate, v5 refreshed the model in June 2026.
• Cons: blind to your environment, a probability that people misread as severity, percentile versus probability confusion, reacts to public signals so new flaws start low.

CISA KEV

• Pros: evidence-based, short, free, carries due dates for federal agencies, the strongest single signal for emergency patching.
• Cons: lags first exploitation, covers a small slice of all CVEs, tells you nothing about unlisted flaws. Our look at four critical CVEs added in August shows what a single month of additions can look like.

SSVC

• Pros: produces an action and a written reason, adapts to your role, used operationally by CISA, no license cost.
• Cons: needs setup and upkeep, results differ between teams, fewer turnkey integrations than a simple score column.

Use-Case Recommendations: Which Signal Leads

The right ordering depends on who you are. Seven common situations follow, each with a lead signal and the reasoning.

Situation	Lead signal	Supporting signals	Why
Edge and perimeter teams (VPN, firewalls, mail gateways)	CISA KEV	EPSS, CVSS	October’s Ivanti and BeyondTrust cases hit exactly this layer
One-person security team	KEV, then EPSS	CVSS as a tiebreaker	Two free feeds cut the queue with minimal tooling
Federal agencies and contractors	KEV with due dates	SSVC for documentation	Deadlines are binding and decisions must be defensible
AppSec teams reading scanner output	CVSS v4.0 plus EPSS	KEV as a hard gate in CI	Code findings arrive with severity and need a likelihood filter
OT and ICS asset owners	SSVCv2 and vendor advisories	CVSS vectors	Patching is slow and risky, so decisions need context
Managed service providers	SSVC-style decisions per client	KEV, EPSS	Each client has a different exposure profile
Board and audit reporting	CVSS severity bands	KEV overrides listed separately	Executives understand severity, auditors want exceptions explained

A few notes on those rows. Small teams should resist the urge to build a weighted formula. Weights hide assumptions, and nobody can explain why 0.7 times the EPSS score plus 0.3 times the CVSS score equals “high.” A decision order is easier to defend: KEV first, then EPSS above a threshold you choose, then CVSS and asset value. For OT, the cost of patching, which may require a maintenance window or vendor sign-off, is a first-class input. A pure score cannot express that, so a decision framework does better there.

Endpoint and browser teams deserve their own note. Software that updates itself changes the math, because the fix arrives without a ticket. A browser-engine bug like the Chrome V8 zero-day on the KEV list may demand less manual work than its listing suggests, and SSVC’s deployer questions let you record that reasoning instead of leaving an open ticket that nobody can close.

Migration Guide: From a CVSS-Only Queue to a Layered Pipeline

Most teams do not start from zero. They have a scanner, a CVSS-based SLA and a ticket system. The steps below move that setup to a layered pipeline without a rewrite, and the whole thing fits in two to three weeks of part-time work.

1. Inventory your current rules. Write down every SLA tied to a CVSS threshold and note which version your scanner reports.
2. Backtest on your own history. Pull the last twelve months of closed findings. Mark which were later added to KEV and what their EPSS scores were at the time. This gives you your own benchmark instead of a vendor’s.
3. Add the KEV flag. Load the catalog daily, match by CVE ID against your findings and add a field. Any match becomes the highest priority regardless of score.
4. Add the EPSS column. Pull the daily file, store the probability and the percentile, and record the date so you can alert on jumps.
5. Choose a threshold and test it. Start from your backtest. Pick an EPSS cutoff that would have caught your KEV-listed bugs before they were listed, and accept that you will tune it.
6. Keep CVSS as severity. Use the score for impact context and for compliance reports, and store the vector so v3.1 and v4.0 never get confused.
7. Pilot SSVC on one asset class. Pick the class with the most arguments, such as internet-facing servers, and write down the answer to each decision point. Review after a month.
8. Publish the decision order. One page: KEV, then EPSS above the threshold, then severity and asset value. Share it with engineering so tickets stop bouncing.

A starter script for steps three and four looks like this. It loads the public KEV feed, pulls EPSS scores in batches and assigns a priority tier. The 0.10 cutoff is an example to tune against your backtest, not a recommendation from FIRST or CISA.

import requests

KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
EPSS_URL = "https://api.first.org/data/v1/epss"
EPSS_CUTOFF = 0.10  # example threshold, tune against your own backtest


def load_kev():
    data = requests.get(KEV_URL, timeout=30).json()
    return {v["cveID"] for v in data["vulnerabilities"]}


def load_epss(cves):
    scores = {}
    for i in range(0, len(cves), 100):
        batch = ",".join(cves[i:i + 100])
        rows = requests.get(EPSS_URL, params={"cve": batch}, timeout=30).json()["data"]
        for row in rows:
            scores[row["cve"]] = (float(row["epss"]), float(row["percentile"]))
    return scores


def triage(findings):
    kev = load_kev()
    epss = load_epss([f["cve"] for f in findings])
    for f in findings:
        prob, pct = epss.get(f["cve"], (0.0, 0.0))
        if f["cve"] in kev:
            f["tier"] = "P0-KEV"
        elif prob >= EPSS_CUTOFF:
            f["tier"] = "P1-EPSS"
        elif f["cvss"] >= 9.0:
            f["tier"] = "P2-SEVERITY"
        else:
            f["tier"] = "P3-TRACK"
        f["epss"], f["epss_percentile"] = prob, pct
    return findings

Run it against a copy of your backlog first and compare the tiers with what your team would have chosen by hand. Where the two disagree, you will learn something about your own assumptions. Expect pushback from teams who liked the simplicity of “critical means seven days.” The answer is to keep the severity band for reporting and add the override logic on top, not to abolish the familiar view.

Five mistakes that wreck a layered queue

Teams that adopt the stack tend to trip over the same problems. Avoid these five and you save yourself a quarter of rework.

1. Reading the percentile as a probability. The 95th percentile means the CVE ranks above most others. It does not mean a 95 percent chance of attack.
2. Counting KEV and EPSS as two votes. KEV data feeds the EPSS model, so a listed bug will often show both. Treat the listing as the fact and the score as the echo.
3. Freezing the score at ticket creation. EPSS refreshes daily and NVD can rescore a CVE. Re-evaluate open tickets on a schedule.
4. Ignoring the asset side. None of the public scores know that a server holds payroll data or sits in a lab. Add an asset-criticality field before you trust any ranking.
5. Building a weighted formula nobody can explain. If an auditor asks why a ticket ranked third, “the formula said so” is a bad answer. A decision order is a good one.

Verdict: Stack Them, and Put KEV First

If you must pick one signal for emergency response, pick CISA KEV. It has the shortest list, the strongest evidence and the clearest instruction. If you must pick one for everything else, pick the EPSS score, because it is free, daily and aimed at the question your queue actually asks: which of these thousands will attackers use next. Keep the CVSS score for severity and for the compliance paperwork it still anchors. Add SSVC when you need decisions you can defend, repeat and explain to someone outside the team.

Here is the scorecard behind that call. The ratings are our judgment based on the design of each system and the October 2026 evidence above, not measured results.

Criterion	CVSS	EPSS	CISA KEV	SSVC
Speed to act on a new zero-day	Low	Medium	High	High (with KEV input)
Coverage of all CVEs	High	High	Low	Medium
Forward-looking value	None	High	None	Low
Fit to your environment	Low	None	None	High
Ease of automation	High	High	High	Medium
Audit and compliance value	High	Medium	High	High
Role in our stack	Severity label	Ranking engine	Override	Decision record

We could not confirm any change to CVSS, EPSS, KEV or SSVC governance, pricing or versions in the week of October 18 to 25, 2026. That stability helps. The workflow you build now should not need a redesign next quarter, though you should watch FIRST’s release notes for the next EPSS model and keep tracking how quickly teams move from CVSS v3.1 to v4.0. For the next six months, the winning pattern stays the same: confirmed exploitation first, probability second, severity third, and a written decision for anything that crosses your risk line.

Frequently Asked Questions

What is an EPSS score?

An EPSS score is a probability between 0 and 1 that a published CVE will see exploitation activity within the next 30 days. FIRST publishes it daily for every public CVE, and the current model generation is EPSS v5, deployed on June 15, 2026. It forecasts exploitation likelihood and does not measure severity.

Is EPSS better than CVSS?

Neither is better in general because they answer different questions. CVSS rates how severe a flaw is if exploited, and EPSS estimates how likely exploitation is soon. Use EPSS to rank the queue and CVSS to describe impact. Using only CVSS ignores attacker behavior, and using only EPSS ignores how damaging a bug could be.

Should I always patch CISA KEV entries first?

Yes, for systems you actually run. FIRST’s own documentation tells readers to treat a KEV vulnerability as actively exploited regardless of its EPSS score. If an entry covers software you do not deploy, record that and move on. For everything you do run, KEV membership should override your normal SLA.

Is CVSS v3.1 obsolete now that v4.0 exists?

No. CVSS v4.0, published in November 2023, is the newest version, but v3.1 remains in wide use across vulnerability databases, vendor advisories and CISA’s own ICS advisories. Many records carry both. Record which version each number comes from and do not compare them directly.

What does SSVC output look like?

CISA’s SSVC implementation ends in one of four outcomes: Track, Track*, Attend or Act. It reaches them by answering decision points such as exploitation status, whether the attack is automatable and the technical impact. CISA publishes these decisions in CVE records and shows SSVCv2 fields in ICS advisories.

Do EPSS, KEV or SSVC cost money?

We found no license fee. EPSS data is a free daily feed, CISA KEV is public at $0, and SSVC has no separately priced official product. You may pay for tools that ingest the feeds, but the underlying data is free.

Can a vulnerability have a low EPSS score and still be dangerous?

Yes. EPSS reacts to public signals, so a newly disclosed flaw without public exploit code can start low, and it cannot see your internal exposure. That is why KEV membership, asset context and a decision framework such as SSVC sit alongside it.

What is the right order to use all four?

Check KEV membership first, rank the remainder by EPSS score, use CVSS for severity and impact context, and record the final call with an SSVC decision for assets that need an audit trail. Tune the EPSS cutoff against your own ticket history before you rely on it.