Vulnerabilities Are Now the Top Way In. Here Is How We Decide What to Fix First

What vulnerability prioritization actually means

A vulnerability scanner produces a list. On a typical network that list runs to hundreds or thousands of items, many rated “critical” or “high” by their CVSS score. If your team works that list from the top down, two things happen. The work never ends, and the issues attackers are actually using can sit in the queue behind ones nobody will ever exploit.

Vulnerability prioritization, sometimes called risk based vulnerability management or exposure management, replaces the raw severity sort with three questions:

1. Is it being exploited right now? A flaw with working attacks in the wild is a different problem than one that is only theoretical.
2. Can an attacker reach it? A weakness on an internet-facing VPN, firewall or web server is more urgent than the same weakness on an isolated lab machine.
3. What would it cost the business if it were used? A flaw on the system that runs payroll, dispatch or patient scheduling outranks the same flaw on a spare laptop.

Severity still matters. It is just one input instead of the whole answer.

Why CISA KEV belongs at the top of the list

The CISA KEV catalog is a public list of vulnerabilities with reliable evidence of exploitation in the wild and a clear fix available (CISA KEV catalog). CISA recommends that every organization, not only federal agencies, use KEV as an input to its prioritization framework (CISA guidance on reducing KEV risk).

KEV is useful because it answers the first question for you. If a vulnerability is on the list, someone is already using it. CISA’s own decision model, Stakeholder-Specific Vulnerability Categorization (SSVC), combines exploitation status with exposure, technical impact and how automatable an attack is to decide whether to track, attend to or act on a flaw (CISA SSVC).

KEV is not the whole job, though. It lists what has been exploited somewhere, not what is exposed in your environment. A KEV item on a product you do not run is noise. A non-KEV flaw on your only internet-facing server may still deserve a fast fix. That is why the second and third questions matter.

CVSS, EPSS, KEV and SSVC: what each signal tells you

Most prioritization frameworks combine a handful of public signals. Each one answers a different question, and none of them answers all of them.

The Common Vulnerability Scoring System describes the technical characteristics of a vulnerability (FIRST CVSS v4.0). The Exploit Prediction Scoring System is a data-driven model that estimates the probability a published CVE will be exploited in the wild in the next 30 days, updated daily for every CVE (FIRST EPSS). Used together with KEV, they separate “bad in theory” from “being used right now,” and SSVC turns those facts into an action.

The missing input is always the same: your own environment. A public score cannot know that one server runs payroll and another is a test box. That is the part a managed team has to bring.

How to prioritize vulnerabilities: a five-step process

Whether you run the program yourself or hand it to a provider, the steps are the same. NIST describes enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches across the organization (NIST SP 800-40 Rev. 4). In practice that becomes five steps:

1. Build and maintain the asset inventory. List every server, laptop, network device, cloud service and internet-facing system, with an owner and a business role for each. Unknown assets are where unpatched flaws hide.
2. Scan on a schedule and after changes. CIS Control 7 calls for continuously assessing and tracking vulnerabilities on all enterprise assets to minimize the window of opportunity for attackers (CIS Control 7).
3. Enrich each finding. Add KEV status, EPSS probability, internet exposure and the business role of the affected system to the raw scanner output.
4. Sort into tiers and assign deadlines. Exploited and exposed issues on important systems go first, with a fixed deadline. Everything else follows a normal cycle.
5. Fix, verify and report. Rescan to prove the fix, document exceptions and report trends to leadership.

A simple vulnerability prioritization matrix

A matrix makes the order visible and keeps the debate short. Here is the structure we start from. The deadlines below are examples to show the shape of a policy; the real intervals are set with each client.

For reference, CISA’s Binding Operational Directive 26-04, issued June 10, 2026, replaced BOD 22-01 and now sets federal civilian agencies’ remediation timelines from four variables: whether the asset is publicly exposed, whether the flaw is on the KEV catalog, whether exploitation can be automated, and whether an attacker gains partial or total control (CISA BOD 26-04). Private businesses are not bound by it, but it is a useful model when leadership asks what should go first, and its logic closely mirrors the matrix above.

How BTI decides what to fix first

BTI treats managed patching, vulnerability management and vCISO oversight as one operating model. For managed and co-managed clients, the cycle works like this:

• Inventory first. You cannot prioritize what you have not found. We start with an asset inventory, scanning coverage, open critical and high findings, and the current patching cadence.
• Exploited and exposed go to the front. We map CISA KEV entries, vendor advisories and internet exposure to the systems you actually run. Edge devices such as firewalls, VPN portals and email gateways get special attention, because they face the internet by design.
• Business impact sets the order inside each tier. Two KEV items on two different servers are not equal if one of those servers runs your business.
• Fix, then prove it. A patch is not done when the update is pushed. It is done when a rescan confirms the finding is gone. We call this verified closure.
• Document exceptions. Some systems cannot be patched on schedule. Those get a written exception, a compensating control and a review date instead of quietly aging in the queue.
• Watch the gap. BTI’s 24/7 NOC/SOC monitors for activity that arrives before a fix can, so the time between disclosure and patch is not a blind spot.

Patching intervals themselves are something leadership should decide in advance, not something IT improvises under pressure. BTI writes them into a Protection Level Agreement (PLA), which sets the protection outcome you are paying for. Our free white paper on Protection Level Agreements for managed patching explains the model.

A real example: the October 2026 PHP flaws

In October 2026, two critical flaws in PHP, widely called PHP2Shell (CVE-2026-109618 and CVE-2026-109619), allowed unauthenticated remote code execution on web servers. CISA urged organizations to inventory every system running PHP, patch immediately and prioritize internet-facing systems, then added both flaws to KEV on October 26 (CISA alert, October 21, 2026).

That alert is a good model for prioritization in practice. It was exploited, it was reachable from the internet, and PHP often sits inside other software where nobody remembers it is running. That combination jumps the queue. We track issues like this on our managed patching and vulnerability management page, with the CISA or vendor source for each one.

Five signs your vulnerability program needs a reset

• Your scanner report is longer every month, and nobody can say which ten items matter most.
• Patches are marked complete, but nobody rescans to confirm the fix.
• Firewalls, VPN appliances and other edge devices are patched “when there is a maintenance window.”
• Leadership hears a count of open findings, not a picture of risk.
• The same vulnerability shows up in two consecutive reports.

If two or more of these sound familiar, the fix is usually process, not another tool.

Where prioritization fits in exposure management

Prioritization is one stage of a larger loop that many teams now call exposure management. The loop starts with discovering what you own, including cloud services and remote devices that never touch the office network. It continues with validating what an attacker could actually reach, which is where penetration testing comes in, and it ends with mobilizing the fix: getting the right people to patch, reconfigure or retire the system on time.

Each stage feeds the next. Discovery without prioritization produces a long list. Prioritization without validation can rank a flaw highly that a firewall rule already blocks. Validation without mobilization produces a report nobody acts on. When one team owns the whole loop, or several teams share one ranked list, the time between “we found it” and “it is closed” gets shorter. NIST’s Cybersecurity Framework 2.0 frames the same idea as identifying, protecting, detecting, responding and recovering under a governance function that sets priorities (NIST Cybersecurity Framework).

What leadership should ask for

Owners and executives do not need to read CVE numbers. They should be able to get clear answers to a few questions every quarter:

• How many actively exploited vulnerabilities are open on our systems today, and how old is the oldest one?
• Which internet-facing systems are behind on updates?
• What is our agreed patching interval for critical issues, and are we meeting it?
• What exceptions exist, who approved them and when do they expire?
• What changed since last quarter?

A vCISO can own that conversation. BTI’s vCISO services turn scan data into a roadmap and a report leadership can fund and track.

Risk based vulnerability management metrics that matter

Risk based vulnerability management lives or dies on a few numbers. Counting open findings is not one of them, because the count goes up every time a scanner adds checks. These are more useful:

• Open KEV items on your systems, and the age of the oldest one.
• Median time to remediate for each tier, compared with the interval leadership agreed to.
• Percentage of fixes verified by rescan, not just marked complete.
• Scan coverage, meaning the share of known assets that were actually scanned this cycle.
• Exceptions past their review date.

Verizon’s finding that the median time to fully resolve critical KEV flaws reached 43 days is a reminder that time, not volume, is the metric attackers care about (Verizon 2026 DBIR).

Tools help, but process decides the order

Vulnerability prioritization tools can pull KEV, EPSS and asset data into one score, and they are worth having in larger environments. They do not replace three human decisions: which systems matter most to the business, what patch intervals leadership will fund, and which exceptions are acceptable. When those decisions are missing, a tool simply produces a more sophisticated list.

That is why BTI ties prioritization to its broader managed cybersecurity services and to managed IT services that already own patching and change control. The team that schedules the maintenance window should be working from the same ranked list as the team watching for attacks.

Common prioritization mistakes

• Sorting only by CVSS. A 9.8 on an isolated lab box can wait; a 7.5 on your VPN often cannot.
• Treating KEV as the whole list. KEV tells you what is exploited somewhere, not everything that is exposed in your network.
• Skipping edge devices. Firewalls, VPN portals and email gateways face the internet by design and deserve their own fast track.
• Closing tickets without a rescan. An update that failed silently looks identical to one that worked until you test again.
• Forgetting credentials. Some flaws expose passwords and keys, so the fix is not complete until those are rotated. Our guide on rotating credentials after a critical vulnerability covers when that applies.

Prioritization also depends on good test data. Read how often to retest after fixes and why we start with a credential-free test instead of handing over admin passwords.

Local help in Los Angeles, Chicago and Phoenix

BTI’s engineers work with mid-market and multi-site organizations across Southern California, Chicagoland and Arizona, from our Los Angeles office in Santa Fe Springs to teams serving Chicago and the Phoenix and Tucson areas. Local engineers can handle the on-site part of a fix, such as an edge appliance in a branch closet, while the 24/7 NOC/SOC watches for activity in the meantime.

• Los Angeles and Southern California: Los Angeles cybersecurity services, IT line 323-510-8003.
• Chicago and Chicagoland: Chicago cybersecurity services, IT line 312-492-2613.
• Phoenix and Tucson: Phoenix and Tucson cybersecurity services, IT line 480-272-8728.

Start with what is actually exposed

The fastest way to see where you stand is a test. BTI’s free cybersecurity assessment runs a credential-free test on 3 to 5 machines you choose, with an optional external scan, a written report, a prioritized roadmap and a readout with a senior BTI engineer. The report and roadmap are yours to keep, whether your own team, your current provider or BTI does the work.

Get a free cybersecurity assessment or book a free consultation. Prefer to talk? Call the BTI IT team: Los Angeles 323-510-8003, Chicago 312-492-2613, Phoenix 480-272-8728.

Calling from outside those metros? Reach BTI toll-free at 800-435-7284 (800-HELP-BTI).