Most vulnerability management policies look roughly like this: critical in 7 days, high in 30, medium in 90, low at your convenience.
CrowdStrike's 2026 Threat Hunting Report reports that 88% of observed exploitation of vulnerabilities with a public proof-of-concept occurred within 48 hours of that PoC's release, with some China-nexus actors moving inside 24 hours of disclosure.
Against that population, a 7-day critical SLA is not fast. It is roughly three times too slow for the thing it exists to prevent.
Why "shorten the SLA" is the wrong answer
The instinct is to compress every tier. It does not survive contact with reality, for reasons that have nothing to do with security team competence:
- Change control, maintenance windows, and customer-facing SLAs exist and are not going away.
- Many patches require coordinated dependency upgrades or vendor releases you do not control.
- Regression risk is real; a bad emergency patch causes the outage the attacker was hoping for.
- The volume is enormous. Microsoft alone patched a record 622 flaws in a single month in July 2026.
A 48-hour SLA applied to everything produces one of two outcomes: it is ignored, or it burns out the team and breaks production. Usually both.
The realistic design is different: keep the normal cadence for the bulk, and build a genuinely fast lane for a set small enough to move at 48 hours. The engineering problem is selecting that set correctly and automatically.
Selecting the fast lane
Severity alone is the wrong selector, because criticals are far too numerous and many are never exploited. Four signals do the work better, combined:
Public exploit availability. This is the strongest single predictor and it maps directly to the 48-hour finding. A vulnerability with a working PoC on GitHub is in a different risk class from one with a vendor advisory and nothing else. CVE-2026-9198 in Langflow had multiple public PoCs and 650 recorded exploitation attempts from 244 IP addresses across 41 countries — the exploit is two curl commands.
CISA KEV membership. Empirical evidence of exploitation in the wild. It is conservative and lags reality, but a KEV listing should be an automatic override of every other consideration.
Reachability in your code. A vulnerable function that nothing in your application ever calls is not urgent regardless of its score. This is the signal that shrinks the fast lane most, and it is the one most organisations lack — which is why their critical bucket is unmanageably large.
Asset exposure and criticality. Internet-facing, holding credentials, or sitting on the management plane. A CVSS 5.3 on Cisco's Firewall Management Center outranks a 9.1 on an isolated internal service, and any policy sorting by base score gets that backwards.
Combine those and the fast lane typically resolves to a handful of items per month rather than hundreds. A handful per month is a volume an on-call rotation can genuinely absorb in 48 hours.
A tiering model that survives audit
| Lane | Trigger | Target | Volume |
|---|---|---|---|
| Emergency | KEV listing, or public PoC plus internet-facing and reachable | 48 hours | Very low |
| Expedited | Public PoC, or high EPSS, and reachable | 7 days | Low |
| Standard | Reachable, no known exploitation | 30 days | Moderate |
| Backlog | Not reachable, or compensating control in place | Next cycle | High |
Two properties make this workable. Lane assignment is computed, not argued — no triage meeting decides whether something is urgent, so the assignment happens at ingest rather than at the next stand-up. And items move between lanes automatically when the world changes: a vulnerability sitting quietly in Backlog jumps to Emergency the moment a PoC is published, without anyone re-reviewing it.
That second property is what most programmes lack. Prioritisation is treated as a one-time decision made at discovery, when it is a function of facts that change daily.
What to build before the next 48-hour event
A dependency inventory that is current, not quarterly. You cannot meet a 48-hour window if determining whether you are affected takes a week. This is the single most common cause of missed windows, and it is an inventory problem rather than a patching problem.
Automated PoC and KEV monitoring wired to your backlog. The signal has to reach your issue tracker without a human noticing a news article.
A pre-authorised emergency change path. The 48-hour clock includes change approval. If your emergency path requires a CAB that meets on Tuesdays, your real SLA is nine days no matter what the policy says. Negotiate this in advance, with defined criteria, so nobody is debating process during an incident.
Rehearsal. Run the drill on a real recent CVE. Most teams discover their bottleneck is neither detection nor patching but approval, or the absence of a tested rollback.
An honest reachability signal. Without it, the fast lane fills with findings that cannot be exploited in your environment, the team stops believing the alerts, and the whole model degrades to the 30-day SLA you started with.
The uncomfortable trade-off
A fast lane this narrow means consciously accepting that some vulnerabilities will not be patched quickly. That is a real risk decision and it should be made explicitly, documented, and reviewed — not arrived at accidentally by having a policy nobody can meet.
The alternative is worse. A programme that nominally treats everything as urgent treats nothing as urgent, and the item that gets exploited is the one that was sitting in a queue of four hundred equally-labelled criticals.
How Safeguard helps
Lane assignment computed from live signals. Safeguard combines CVSS, CISA KEV membership, EPSS, public exploit availability, network exposure, and code-level reachability into a ranking that updates as those inputs change — so a dormant finding escalates on the day a PoC appears rather than at the next review cycle.
Reachability that shrinks the queue honestly. Safeguard analyses whether vulnerable code paths are actually invoked from your application, which is what makes a 48-hour lane small enough to staff. Cutting the urgent set is only defensible if the cut is based on evidence.
Continuous inventory as the precondition. Supply Chain Core maintains CycloneDX and SPDX SBOMs generated at build time across packages, containers, models, and appliances, so "are we affected" is a query answered in minutes.
Griffin for the remediation itself. The 48-hour clock is mostly consumed by mechanical work — bumping versions across dozens of repositories, resolving conflicts, running test suites, opening reviewable PRs. Griffin does that in parallel, which is what converts a policy target into an achievable one.
Eagle for the cases where you were too late. When exploitation preceded remediation, Eagle scopes what was genuinely reachable and which credentials were exposed, so the response is proportionate rather than a full-estate rotation.
Take your last three emergency patches and measure where the hours actually went. If more than half were spent determining whether you were affected, your problem is inventory, not patching.
Sources: CrowdStrike 2026 Threat Hunting Report · The Hacker News — Microsoft Patches Record 622 Flaws · CISA Known Exploited Vulnerabilities Catalog · The Hacker News — CISA Flags Langflow, Tomcat, and N-central Flaws
