The Scan Came Back Full of Criticals: Stop Ranking by CVSS and Build a Four Tier Short List
The views expressed are my own and do not represent those of my employer.
Imagine a security lead at a mid size manufacturer. It is Monday morning and the weekly scan report lands in her inbox. Thousands of findings carry a critical or high label. The IT director wants a plan by noon. The plant operations lead wants to know which fixes could stop a production line. She has two maintenance windows this month.
She does what the industry trained her to do. She sorts by CVSS and starts at the top. By Wednesday her team has patched a stack of 9.8s on internal servers that nobody outside the building can reach. Meanwhile an 8.8 sits on an internet facing server. It is on CISA's list of vulnerabilities attackers are using right now. Nobody touched it, because 8.8 ranks below 9.8.
That is the failure mode, and I have watched versions of it play out across the industry for years. Sorting by severity feels rigorous. It produces a tidy queue. It also points scarce hours at the wrong targets while the dangerous items wait.
This is part 1 of 5 in my vulnerability management update series. I covered the foundations of exposure management back in April 2026 in Stop Scanning. Start Managing Exposure. If you are new to this, start there. This post picks up where that one left off.
A lot has changed since April. Federal policy moved. A long standing government bulletin disappeared. New research sharpened what we know about predicting exploitation. This post covers all of it and ends with a four tier model you can put in front of your leadership.
Patching Everything Was Never Realistic, and the Math Got Worse
Patch everything was always a slogan, not a plan. No organization of any size has ever done it. Treating every critical as equally urgent does not make you thorough. It burns out your team and teaches IT and operations to ignore your tickets.
The numbers explain why the slogan is breaking. CISA wrote in June 2026 that AI is helping researchers and adversaries find software flaws faster, which vastly increases the pace of new vulnerabilities. Artificial intelligence is assisting both researchers and adversaries in identifying flaws in software, vastly increasing the pace at which new vulnerabilities are discovered. Defenders were already behind. CISA cited Verizon's 2026 Data Breach Investigations Report: only 26% of vulnerabilities on the KEV Catalog were fully remediated in 2025, down from 38% the year before, and the median time to full resolution rose to 43 days.
Read that again. Those are the vulnerabilities with proof of exploitation, and most organizations did not finish them.
Attackers do not wait for your cycle either. Rapid7's Q3 2026 threat update found exploitation occurred an average of three days after public disclosure, with 80% of tracked exploitation inside 14 days. A monthly patch cadence ranked by severity cannot win that race. A short list ranked by evidence can.
CVSS Answers the Wrong Question
CVSS measures how bad a flaw could be if someone exploits it. That is useful information. It is not the question your board or your plant manager is asking. They want to know whether anyone is going to use it against you.
Academic work on EPSS makes the same point. A key limitation of CVSS is its focus on potential impact rather than the likelihood of exploitation. The IANS Vulnerability and Breach Update for Q3 2026, written by IANS faculty member Mike Saurbaugh and published October 20, 2026, lands in the same place. IANS describes CVSS as losing usefulness. IANS framed the message as ranking fixes by real exploitation and exposure, not CVSS.
CVSS tells you how bad a vulnerability could be. It does not tell you whether anyone is using it.
I am not telling you to delete the score. I am telling you to demote it. Severity becomes a tiebreaker and an impact input. It stops being the sort key.
CISA Changed the Default, and That Helps You in the Boardroom
Two federal moves in 2026 matter here. First, CISA released Binding Operational Directive 26-04 on June 10, 2026, which reprioritizes remediation based on public exposure, KEV status, automatability and technical impact. Second, CISA stopped publishing the weekly Vulnerability Bulletin. It discontinued that bulletin on September 28 as part of a shift from severity based vulnerability management to a risk based approach. That bulletin sorted new vulnerabilities into high, medium and low categories using CVSS scores.
The directive gives timelines teeth. Only the highest risk vulnerabilities must be patched within three days, while lower risk items can run on longer timelines or even wait until the next system upgrade. That is a federal agency permitting deferral on purpose.
BOD 26-04 binds federal civilian agencies. It does not bind you. But CISA encourages other organizations to adopt a similar approach. That sentence is worth keeping in your back pocket. When an auditor or a director asks why your queue no longer follows CVSS, you can answer that the agency that runs the national KEV catalog made the same change.
One detail in the directive deserves attention from every CISO. CISA supplies KEV status, automatability and technical impact. Exposure is the one variable the organization has to determine itself. That puts a burden on your asset inventory, and I will return to it.
KEV Is Your Floor, EPSS Fills the Gaps
KEV is the cleanest signal in vulnerability management. A listing means CISA has evidence of real exploitation. That makes it a hard trigger, not a suggestion.
KEV has a limit, though. It is a floor, not a ceiling. Empirical Security tracks more than 17,000 exploited CVEs from observed activity, and KEV had 1,477 entries at the time of its 2026 analysis. Even with perfect overlap, KEV would cover at most about 8.7% of exploited CVEs. Plenty of exploited flaws never reach the catalog, or reach it late.
EPSS covers part of that gap. EPSS is the probability, between 0 and 1, that exploitation activity against a CVE will be observed in the wild in the next 30 days. Use it to rank the vulnerabilities that have not hit KEV yet.
Do not let EPSS overrule KEV, though. IANS gave two Q3 2026 examples that make the point. A SharePoint flaw rated CVSS 8.8 carried an EPSS score of 2.70%. A Cisco VPN denial of service flaw rated CVSS 8.6 carried an EPSS score of 1.01%. Both sat on KEV. Both had low EPSS. Both still mattered because exploitation was confirmed and the products face the internet.
Think about what a purely probability driven queue would have done. It would have pushed both items down the list. Exploitation was already happening.
EPSS ranks the unknown. KEV settles the known. A low EPSS score never overrules a KEV listing on an exposed asset.
The Recency Signal Most Programs Ignore
Here is the newest idea in this space, and it changes how I think about sorting a long KEV list. IANS summarized a study by Empirical Security covering nearly 17,000 CVEs. The finding: time since first exploitation is a weak predictor of future exploitation. How recently exploitation was last seen improves accuracy.
Most teams track the first signal without realizing it. They say a flaw has been exploited for two years, so it is old news. Or they say it was only added last week, so it must be urgent. Neither statement tells you much. What matters is whether attackers are still using it this month.
Empirical's own research supports this. If a vulnerability has had any exploitation activity, the chance of seeing activity again in the next month is about 65%. Recent exploitation is a powerful predictor, and the absence of recent exploitation lowers the probability of re-exploitation as time passes.
The data is also available to you. Empirical Security generates the EPSS scores that FIRST serves. Its data dictionary breaks exploitation activity into time buckets: the last 7 days, 8 to 30 days, 31 to 90 days and so on out to a year.
Use recency to order work inside a tier. Do not use it to drop an exposed KEV item off the list because attackers went quiet for a month. Quiet is not safe. It only changes the sequence.
The Four Tier Model
You need a model your analysts can run without a committee meeting. This is the one I recommend. The thresholds are my starting points. Tune them against your own data.
Tier 1: Fix now. The vulnerability is on KEV, or you have credible evidence of exploitation in the last 30 days, and the affected asset is exposed to the internet or an untrusted network. Target 72 hours. This lines up with the three day clock CISA set for its highest risk category. Run it as an emergency change. If no patch exists, apply a mitigation: remove the exposure, restrict access or disable the feature.
Tier 2: Fix in the next window. Either the vulnerability is on KEV but the asset is internal, or it is not on KEV, the asset is exposed and the EPSS score sits at 10% or higher. Target the next scheduled maintenance window, within 14 days. This tier is what your maintenance windows are for.
Tier 3: Schedule. Not on KEV, EPSS below 10%, internal asset, but a high CVSS or a business critical system. These go into the normal monthly or quarterly cycle. CVSS earns its keep here as an impact input.
Tier 4: Defer on purpose. Low EPSS, not on KEV, no exposure, no automated exploitation path. Batch these with the next upgrade. Record the deferral, name an owner and set a review date. Deferral is a decision, not neglect.
Two rules keep the model honest. Re-score every day, because a KEV addition can move an item from Tier 4 to Tier 1 overnight. And sort by last exploitation seen inside each tier, so the item attackers touched yesterday goes before the one they touched last spring.
Two Maintenance Windows and a List You Can Defend
Manufacturers have a constraint most IT shops do not. Plants run on schedules. Change freezes are real. Some systems cannot reboot without stopping production, and some controllers cannot be patched at all until the next planned outage.
That makes a short list essential. If you hand operations a list of thousands, you get a polite no. If you hand them a list of a few dozen items, each tied to proof of exploitation, you get a conversation. The four tier model gives you a list you can finish inside the windows you actually have.
For plant floor assets, Tier 1 often means a compensating control, not a patch. Cut the internet path. Tighten remote access. Segment the device. Then document an owner and an end date for the exception. Most operational technology should never be reachable from the internet. If your Tier 1 list is full of plant systems, the finding is the exposure itself. My post on limiting the exposure of your connectivity covers that side.
All of this depends on knowing what is exposed. CISA leaves that variable to you, and no feed can supply it. If your inventory is weak, start with asset management and tag every internet facing system first. A rough exposure tag today beats a perfect one next year.
Getting Organizational Support
This change touches budget, plant schedules and audit language, so you need support at every level. Frame each conversation around business risk, not scoring systems.
The board. Directors do not want to hear about EPSS. They want to know whether you are spending effort where attackers are active. Here is a script for you to adapt: "The scanners flag [number] issues. Attackers are using a small share of them. The program fixes those first, within days, and schedules the rest on a documented plan. The measure to watch is how long known exploited, internet facing flaws stay open." Point out that the federal government made the same change in 2026. That shows you are following an established direction, not inventing one.
The CEO and CFO. Tell them the same people hours now go to the flaws attackers use. You are not asking for more budget to chase a longer list. You are asking for backing to stop chasing the wrong one. Money talks here: fewer emergency overtime weekends and a smaller chance that an exploited flaw sits open.
Audit and legal. Auditors want a documented, repeatable method. Give them the four tiers, the data sources, the deferral records with owners and dates, and a note on your policy change. A deferral with a named owner and a review date is defensible. A silent backlog is not.
IT and application owners. Promise fewer tickets and better tickets. Every Tier 1 or Tier 2 request carries proof: a KEV listing, exposure and a deadline. That kills the argument about whether the request is real.
Plant and operations leaders. Agree on the rules before the first emergency. Tell them that interruptions outside the maintenance windows will be rare, limited to Tier 1 and explained with evidence. For more on earning this kind of trust, see Winning the Room.
Your own team. Analysts burn out chasing queues that never shrink. A short list with a clear finish line gives them a win each week.
Key Points
- Patching everything was never realistic. Equal treatment of every critical burns out teams.
- CVSS measures potential impact. Demote it to a tiebreaker and an impact input.
- KEV is your hard trigger, but it covers only a fraction of exploited flaws.
- EPSS ranks what has not reached KEV yet. A low score never overrules a KEV listing on an exposed asset.
- How recently exploitation was last seen predicts better than how long ago it began.
- Use four tiers: fix now, fix in the next window, schedule, defer on purpose.
- Exposure is your variable. Build the asset tag before you need it.
Pro Tips
Back test your last quarter. Pull every KEV addition from the last 90 days and check how long each one sat on your assets. That one table does more to win leadership over than any framework slide. It shows the real gap in your own environment.
Replace the bulletin feed on purpose. CISA told bulletin subscribers to select the KEV Catalog and Cybersecurity Advisories topics to keep receiving updates. Do that, then wire KEV additions into an automatic query against your inventory. A human should never have to read a feed and remember to check.
Pre approve the emergency change. Agree with operations on what a Tier 1 change looks like before you need one: who approves it, who is on call and what rollback exists. The time you save on day one is worth more than the patch speed.
Separate the signal from the vendor pitch. Many tools now sell a proprietary risk score. Ask what is inside it. If the answer does not include exploitation evidence, exposure and recency, you have bought a new CVSS.
Pitfalls to Avoid
Do not treat a low EPSS score as permission to wait on a KEV item. The IANS Q3 examples show that low probability scores and real exploitation can coexist.
Do not treat KEV as the complete list of exploited flaws. It is the floor. Pair it with EPSS and recency data.
Do not retire CVSS from your reports overnight without telling your auditors and your board. Explain what replaced it and why.
Do not defer without an owner and a review date. An undocumented deferral is just a backlog with a better name.
Do not wait for a perfect asset inventory before starting. Tag the internet facing systems this month and refine from there.
Final Thought
The scan will always return more findings than you can fix, and that will not change. What you control is whether your team spends this month's maintenance windows on the flaws attackers are using today, and whether you can explain that choice to a director in two sentences.
Tell me where your queue breaks first: the inventory, the maintenance windows or the conversation with leadership. Leave a comment, subscribe so you do not miss the rest of this series, and share this post with a peer who still sorts by CVSS. I read every one.
Comments ()