TL;DR: Use CVSS to understand a vulnerability's technical severity, and treat EPSS (Exploit Prediction Scoring System) as one signal for exploit probability. Then add exposure, asset value, patch availability, and operational impact to decide what to fix first. Neither score measures business risk on its own, and neither tells you when to patch.
Your scanner returns a long list of findings, and every one comes with a number. Sort by CVSS alone and you'll spend time on severe flaws attackers may never touch. Sort by EPSS alone and you'll overlook severe flaws on your most important systems. "Patch the highest score" isn't a complete policy. This guide covers what each score represents and how to combine them.
What does CVSS measure, and what does EPSS estimate?
CVSS describes vulnerability severity. FIRST (Forum of Incident Response and Security Teams) maintains it, and the Base score (0–10) captures intrinsic traits, like attack vector and impact, that don't change from one environment to the next. Teams can add Threat and Environmental metrics to adjust it, but many public sources show only the Base score. FIRST's CVSS FAQ says Base scores aren't risk and shouldn't drive patch prioritization alone. That makes CVSS a severity input, not a time-to-fix recommendation.
EPSS, maintained by the EPSS special interest group at FIRST, estimates the probability that a published CVE will be exploited in the wild within the next 30 days. Scores update daily and range from zero to one. An EPSS score of 0.20 represents a 20% estimated probability for that horizon.
That isn’t a 20% chance your endpoint will be compromised. EPSS doesn’t know your installed software, network exposure, or business impact. Its percentile is also different from its probability: The percentile describes relative ranking among scored vulnerabilities. A 95th-percentile result doesn’t mean a 95% exploitation probability. FIRST’s EPSS FAQ explains these limits.
How should teams interpret score disagreements?
CVSS and EPSS can disagree because they measure different things: technical severity and exploitation probability. EPSS uses CVSS metrics as inputs but learns its weights from exploitation data, and FIRST warns against multiplying the two scores into one number. Treat them as separate evidence.
Two hypothetical examples:
High severity, low EPSS. A critical flaw in a desktop utility that needs local access, with little exploitation activity. It can usually wait for a normal cycle, unless it's reachable on a sensitive asset.
Moderate severity, stronger exploitation signals. A medium-rated flaw in an internet-facing client with public exploit code. It can outrank the critical one.
Also consider two additional inputs:
Known exploitation: CISA's Known Exploited Vulnerabilities (KEV) catalog lists CVEs with reliable evidence of active exploitation. KEV records exploitation that already happened, while EPSS forecasts the next 30 days. A low EPSS score shouldn’t override that evidence when prioritizing affected devices.
Asset exposure and impact: Check whether the vulnerable software is present, whether an attacker could reach or trigger it, and what a compromise would disrupt. Prioritize exposed, business-critical systems, and verify access restrictions before using them to justify a lower priority.
PDQ’s post on likely exploited vulnerabilities explains how exploitation evidence fits into prioritization.
How do you turn the signals into a patch order?
Start with the strongest evidence and work down. This matrix is a starting point, not a standard. PDQ's guide to prioritizing vulnerabilities covers more factors.
Tier | Signals | Action |
|---|---|---|
Fix first | KEV listing or confirmed exploitation, on an exposed or critical asset | Patch or mitigate now, using a small pilot group |
Fix next | High EPSS (by your threshold) or public exploit, reachable asset, many devices, fix available | Schedule in the next patch cycle after pilot testing |
Plan | High CVSS, low EPSS, limited exposure | Normal cycle, with the reasoning recorded |
Monitor | Low CVSS, low EPSS, low exposure | Batch with routine updates, or accept the risk |
Set your own EPSS threshold and revisit it. EPSS doesn't endorse the commonly cited 0.10 cutoff. If no patch exists, mitigate and log an exception with an owner, a reason, and a review date. How to prioritize CVEs goes deeper on weighing these factors.
How does PDQ help prioritize vulnerabilities?
PDQ surfaces vulnerability findings on managed Windows and macOS endpoints and adds risk context, so you can see which devices are affected and filter by risk, severity, and affected software. Its risk score is its own measure, not CVSS or EPSS. It combines the CVE's CVSS score with business impact, access levels, exploitability, and weaponization. Treat it as one input, not the decision.
When a PDQ package exists, deploy the fix to impacted devices from the same console, then review rescan results to confirm.
Final thoughts
CVSS tells you how bad a flaw could be. EPSS tells you how likely exploitation is. Neither knows your environment, so add KEV status, exposure, and asset value before you set the order.
Try PDQ free for 14 days to see vulnerability findings, risk context, and remediation in one place.
