September 2026's Patch Tuesday shipped fixes for 973 CVEs. Releases of that size break the naive approach of reviewing each item, and they expose whichever part of your process is weakest.

This is a repeatable model for handling them.

The core principle: triage by exploitation and exposure

CVSS is a severity score, not a risk score. It tells you how bad a vulnerability would be if exploited; it says nothing about whether anyone is exploiting it or whether you are reachable.

Two inputs matter more:

  • Is it being exploited? Confirmed in-the-wild exploitation, or a public proof of concept, changes the calculus entirely.
  • Is the affected system exposed? A critical RCE on an internet-facing server is a different problem from the same CVE on an air-gapped workstation.

The four tiers

Tier 1 — Exploited, everywhere. Target: 24–48 hours.

Any CVE with confirmed active exploitation, regardless of CVSS. In September 2026 that was two elevation-of-privilege flaws — CVE-2026-81963 in the Windows Update Stack and CVE-2026-85880 in ALPC.

These bypass your normal ring model. Pilot ring compressed to hours, broad deployment same day where possible.

Tier 2 — Critical on exposed systems. Target: 7 days.

Critical-rated vulnerabilities on anything that terminates inbound traffic: web servers, RDP gateways, mail servers, VPN concentrators, exposed database listeners, edge appliances.

Tier 3 — Tier-zero identity infrastructure. Target: 7–14 days.

Domain controllers, ADFS, certificate authorities, privileged access workstations, identity provider connectors. These get their own tier because a privilege escalation here is not contained to one host — it is a path to the whole estate.

Tier 4 — Everything else. Target: standard 30-day cycle.

The remaining hundreds. Real, but not worth breaking change management over.

Making Tier 1 possible

A 24-hour target is unachievable if every patch requires a CAB meeting. The enabling control is a pre-authorised emergency change process, agreed in advance:

  • Define the trigger precisely: "confirmed active exploitation per CISA KEV or vendor advisory."
  • Grant standing approval for deployment under that trigger, without per-instance sign-off.
  • Name who can invoke it, and their deputies.
  • Require retrospective documentation within 48 hours — the audit trail is preserved, the delay is not.

Negotiate this with change management during a quiet period. Trying to establish it during an active exploitation event is how organisations lose days.

Testing without losing the window

The tension between patching fast and not breaking production is real. A workable compromise:

  • Ring 0 — IT and security staff. A few dozen machines, deployed immediately. Your own team absorbs the risk first.
  • Ring 1 — Volunteer early adopters. A few hundred across departments, 4–8 hours later.
  • Ring 2 — General population. 24 hours after Ring 1 is clean.
  • Ring 3 — Critical servers. Scheduled maintenance windows with rollback plans.

For Tier 1 patches, compress the intervals rather than skipping rings. Rings still catch catastrophic regressions; they just do it faster.

Verify coverage — separately from deploying

This is the step that consistently gets skipped, and it is where the gap between "we patched" and "we are patched" lives.

Your deployment tool reports what it attempted. Independent verification tells you what actually happened. Sources of discrepancy are predictable:

  • Machines that were powered off during the window.
  • Machines that require a reboot nobody performed.
  • Machines missing the management agent entirely.
  • Machines in exclusion groups added years ago for a reason nobody remembers.
  • Machines nobody knew existed.

Verify with a vulnerability scanner or a query against endpoint telemetry — a different data source from the one that did the deploying. Track the delta explicitly and drive it down.

The pending-reboot problem

A large share of "patched" Windows systems are running the old code because the reboot has not happened. Users defer indefinitely; servers wait for a window that keeps slipping.

Practical handling:

  • Report on pending-reboot status as a first-class metric, separate from patch installation.
  • Enforce a maximum deferral for workstations — three days is reasonable and survivable.
  • For Tier 1 patches, force the reboot with clear advance notice.
  • Schedule server reboots as a recurring calendar commitment, not as an ad-hoc negotiation each month.

Compensating controls while you patch

Deployment takes days. In the interim:

  • Confirm EDR coverage on affected systems, with special attention to servers where coverage gaps are most common.
  • Enable any vendor-recommended workaround for Tier 1 items.
  • Increase monitoring for the behaviours that follow successful exploitation, rather than for the exploit itself.
  • Consider temporary network restrictions on exposed systems that cannot be patched immediately.

Metrics that mean something

  • Mean time to patch exploited vulnerabilities. The single most meaningful patch metric.
  • Percentage of assets under management. Unmanaged assets are unpatchable by definition, and this number is usually worse than people expect.
  • Pending-reboot backlog, trended over time.
  • Exception register size and age. Exceptions accumulate. Each should have an owner, a justification and an expiry date.

Note what is not on that list: total CVEs patched. It measures activity, not risk reduction, and it makes a 973-CVE month look like an achievement when the only two that mattered were the exploited pair.