Edge devices need a tighter patch SLA than your servers
Vulnerability exploitation is now the top way attackers get in, and the edge is where it starts. A single blended remediation SLA prices that risk wrong. Here is the tiered math.
Vulnerability exploitation became the single most common way attackers get in this year. The 2026 Verizon DBIR put it at 31% of initial access, up from 20% the year before, the first time in the report’s 19-year run that exploiting a bug beat stealing a credential. The place that exploitation concentrates is the internet-facing edge: firewalls, VPN concentrators, load balancers, mail and web gateways. The 2025 DBIR already had edge and VPN vulnerabilities climbing from 3% to 22% of exploitation-driven breaches in a single year, more than a sevenfold jump.
The obvious read is that the answer is speed. Patch the edge faster. Everyone in the room already agrees with that, which is usually the sign that the real problem is somewhere else.
The more interesting detail is where the speed target comes from. Most shops run one remediation SLA for the whole fleet: some median number of days to close a known-exploited vulnerability, measured across every asset the scanner sees. Set it at 30 days and you have a defensible-sounding policy that reports cleanly to leadership. The number is also a quiet lie about your edge, and the math is not close.
A single blended SLA prices every asset at the same risk. It treats the domain controller in a locked rack and the VPN gateway answering unauthenticated requests from the entire internet as the same remediation problem, because to a scanner and a ticket queue they are the same row. They are not the same problem. One requires an attacker to already be inside. The other is how the attacker gets inside.
The edge is not being ignored. It is being priced wrong.
Here is the part the “patch faster” framing misses. In the 2025 DBIR the edge was already remediated better than the rest of the catalog: 54% of edge KEVs fully closed against 38% for all KEVs, at a 32-day median versus 38 days for the general pool (GreyNoise’s read of the report, corroborated by Tenable’s). Edge devices were the fast lane, not the slow one.
That is the uncomfortable finding. Even the fast lane runs on a monthly cadence. A 32-day median to close a known-exploited edge bug is “good” relative to the fleet and catastrophic relative to the threat. And it got worse: the 2026 DBIR moved the overall median to 43 days, up from 32, with only 26% of KEVs fully remediated, down from 38%. At day seven after a KEV lands, 60% to 70% of them are still open (watchTowr). Against an internet-facing appliance, day seven is late. GreyNoise’s State of the Edge dataset logged 2.97 billion malicious sessions against internet-facing infrastructure over 162 days in the back half of 2025, roughly 212 attempted sessions every second (Help Net Security). The scanning is continuous. The remediation is monthly. A blended SLA is the policy that turns that mismatch into a plan.
The math a blended SLA hides
Two calculations make the gap concrete. Both use my numbers; redo them with yours.
First, the exposure window: the days an attacker is ahead of you, measured as the day your fix actually lands minus the day mass exploitation of that asset class begins. For an internet-facing appliance, treat exploitation onset as day two after disclosure. That is generous. Automated scanning of the edge is constant, and mass exploitation of appliance CVEs routinely starts within days of the advisory, sometimes before the vendor has shipped fixed firmware.
| Approach | Median day the fix lands | Days the attacker is ahead |
|---|---|---|
| Blended SLA, running at the 2026 all-KEV median | 43 | 41 |
| Edge worked at the 2025 edge-KEV median | 32 | 30 |
| Edge in its own 72-hour tier (this model) | 3 | 1 |
Carving the edge into a 72-hour tier collapses the exposure window from about a month to about a day. Nothing else in the calculation moved; only the target the edge is measured against did.
Second, why the blended median hides this at all. A median is a headcount statistic. Take a shop with 1,000 tracked assets, 100 of them internet-facing edge. Say the 900 internal boxes close at a 20-day median and the 100 edge boxes sit at 45 days. The blended median across all 1,000 is still about 20 days, because the 500th and 501st assets in the sorted list both fall deep inside the internal majority. The edge tail does not touch the number until roughly the 90th percentile. Your dashboard reads “20-day median, on track.” The hundred boxes that face the entire internet are 45 days deep and statistically invisible.
A median is a headcount statistic, and the edge never has the headcount to move it.
This is why “improve our mean time to remediate” can trend the right way while your real attack surface gets worse. The metric is dominated by the assets that are hardest to reach and cheapest to fix. The one tier that is easy to reach and expensive to lose is a rounding error inside it.
What the tiers look like when you price the risk
If the edge needs its own window, so does everything else. The point of tiering is not a faster number for one row. It is matching the clock to how exploitation actually reaches each class of asset. Below is the model I would defend: actively-exploited or KEV-listed in the tight column, unexploited-but-critical in the middle, routine in the last.
| Tier | Asset class | KEV / actively exploited | Critical, no exploitation yet | Everything else |
|---|---|---|---|---|
| Tier 0, internet-facing edge | firewall, VPN gateway, load balancer, mail/web gateway, reverse proxy | 72 hours | 7 days | 30 days |
| Tier 1, internal critical | domain controllers, identity providers, hypervisors, backup infrastructure | 7 days | 14 days | 45 days |
| Tier 2, internal standard | workstations, general app and file servers | 14 days | 30 days | 90 days |
The windows are tunable and the asset lists are yours to argue with. The structure is the part that carries: three exposure classes, three clocks. A KEV on a VPN gateway and a KEV on a print server are not the same ticket, and a policy that hands them the same due date has decided in advance to be wrong about one of them.
This is the SLA half of asset-first prioritization
We argued at the end of June that the patch queue is being rebuilt around the asset, not the score: CISA and Microsoft both demoted CVSS in the same month and put asset exposure at the top of the sort. The tier table above is that same idea expressed as a deadline instead of a ranking. Exposure decides the order you work in, and the clock you work against. CISA’s own BOD 26-04 moved the federal regime the same way, making whether an asset is publicly exposed one of the variables that sets its remediation urgency. Tier 0 is that variable turned into a due date.
The honest caveat is the one that dogs asset-first prioritization everywhere: this only works if you know which boxes are Tier 0. That is a smaller inventory problem than a full CMDB, though. You do not need to classify all 1,000 assets to start. You need the list of everything with a public IP and a reachable management interface, which is a query most edge vendors and most external scanners can answer today. Tier 0 is the one tier you can populate without trusting your CMDB, which is convenient, because it is the one that cannot wait for you to fix the CMDB first.
What to watch
The number that tells you whether any of this is working is the tiered median, not the blended one. Cut the remediation clock by exposure class and watch the Tier 0 line by itself. If the fleet-wide median improves while the Tier 0 median holds at three or four weeks, the program is getting better at the work that was never going to hurt you and no better at the work that will.
The 2026 DBIR already ran that experiment across 13,000 organizations. The blended median got worse, the edge stayed hot, and the two facts sat in the same report without touching. Whether next year’s report shows the edge finally pulling away from the blended number is the tell for whether anyone actually split the SLA, or just wrote a smaller one over the whole fleet and hoped.
Sources
- 2026 Data Breach Investigations Report (DBIR) | Verizon
- Verizon DBIR 2026: Vulnerability Exploitation Is #1 Initial Access Vector | watchTowr
- Verizon DBIR: Vulnerability exploitation is the dominant initial access vector | Help Net Security (2026-05-20)
- Verizon DBIR 2025: Edge KEVs Are Increasingly Left Unpatched, and More Often Exploited | GreyNoise
- Cybersecurity Snapshot: Verizon DBIR (VPN & edge device) | Tenable (2025-04-25)
- Edge systems take the brunt of internet-wide exploitation attempts | Help Net Security (2026-02-25)
Sources
- 2026 Data Breach Investigations Report (DBIR) | Verizon
- Verizon DBIR 2026: Vulnerability Exploitation Is #1 Initial Access Vector | watchTowr
- Verizon DBIR: Vulnerability exploitation is the dominant initial access vector | Help Net Security
- Verizon DBIR 2025: Edge KEVs Are Increasingly Left Unpatched, and More Often Exploited in Breaches | GreyNoise
- Cybersecurity Snapshot: Verizon DBIR Finds Attackers Feast on Vulnerability Exploits (VPN & edge) | Tenable
- Edge systems take the brunt of internet-wide exploitation attempts | Help Net Security
Share
Related field notes
-
When the firmware patch drops, the exploit race has already started
For internet-facing appliances, the vendor's release is the disclosure. The clock starts when the patch ships, not when CISA lists it. Here is why that changes how you rank the queue.
-
The Security Update Broke Production: A Rollback Runbook
A step-by-step runbook for when a security patch takes down production: pause the rollout, scope the damage, decide roll-back vs fix-forward, and keep the rolled-back host from becoming a silent unpatched asset.
-
The patch queue is being rebuilt around the asset, not the score
In the same month, CISA and Microsoft both demoted CVSS as the thing that decides what to patch first. The order of operations is inverting: asset context is becoming the queue.
-
The FortiGate firmware was current. The admin password hashes were not.
FortiOS 7.2.11, 7.4.8, and 7.6.1 introduced PBKDF2 hashing for administrator accounts. The migration is per-login: SHA-256 hashes stay in place until each admin authenticates post-upgrade. The FortiBleed campaign in June 2026 compromised roughly 75,000 internet-facing firewalls by cracking credentials on devices that cleared the patching check.
Get the free CVE triage cheat sheet
Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekly digest.
Subscribe