Microsoft’s August 2026 Patch Tuesday addressed more than 400 vulnerabilities, and small IT teams cannot install all of them. Let’s talk about patch prioritization using the CISA KEV catalog and EPSS scores, and how to document the ones you decide to defer.

Every small IT department runs on the same unspoken arrangement. Patches go out on a schedule, the schedule covers what the schedule covers, and the rest of the queue sits there growing. That arrangement emerged from three people working forty hours a week while vendors ship far more work than that.

Then August 11 arrived and Microsoft shipped somewhere in the neighborhood of 400 vulnerability patches in one day.

What Microsoft Actually Shipped in August 2026

We say “somewhere in the neighborhood” for a reason. BleepingComputer counted 400. SecurityWeek, Qualys, and Rapid7 all landed on 421. CrowdStrike said 415. The gap comes from what each outlet includes, since Microsoft pushes fixes for Azure, Entra, Teams, and Office at various points in the month, and counting only what shipped on the Tuesday itself produces a different number than counting the month. The severity counts diverge too, with some sources reporting 42 critical vulnerabilities and others 62.

Let’s pause on that detail for a second. Professional security publications, all working from the same vendor bulletins on the same day, can’t agree on how much work landed in your company’s To Do List.  Now imagine the controller at a forty-person firm asking your IT lead whether “the patches” got installed. Um, kinda?

There’s a reason the volume keeps climbing. Microsoft has told customers to expect bigger releases because it’s now using AI to hunt for vulnerabilities in its own products. That’s an AI security story that doesn’t generate big headlines but does generate headaches for your IT department.  The technology is currently generating significantly more remediation work for your team than attacks against your team.

Why Most CVEs Are Never Exploited

Of the 35,364 CVEs published in the first half of 2026, 85 had shown up in CISA’s known-exploited catalog as of July. That’s 0.24%. Broader research from the EPSS project puts lifetime exploitation somewhere under 5% of all published vulnerabilities.

Both figures come with a caveat: KEV lags disclosure, and it records only exploitation somebody confirmed and documented. In other words, 0.24% is a baseline that will rise as this year’s crop ages. The median gap between a CVE being published and landing in KEV runs around 57 days.

The overwhelming majority of what your scanner flags will never be used against anyone, and a small, identifiable minority is being used right now. Treating those two groups as one queue sorted by severity score is how a team burns August on critical-rated bugs with no exploitation activity while something rated medium sits in a container image.

How to Prioritize Patches Using CISA KEV and EPSS

One patch genuinely couldn’t wait. CVE-2026-68820 is a use-after-free flaw in afd.sys, the Windows driver behind socket operations, and Microsoft confirmed attackers were already using it to escalate to SYSTEM on machines where they’d gained a foothold. It went into CISA’s catalog of known exploited vulnerabilities immediately.

Anything in the CISA Known Exploited Vulnerabilities (KEV) Catalog goes first, on a clock measured in days. Federal agencies operate under binding timelines for exactly this list, and there’s no reason a private company should be looser about vulnerabilities that are confirmed to be in active use.

Likewise, anything internet-facing jumps the queue regardless of what it scores. Roughly a quarter of KEV entries get added within a week of publication, which is to say that the review cadence matters as much as the ranking. A monthly look at the catalog will miss those entirely.

After that, the EPSS (Exploit Prediction Scoring System) gives you a probability of exploitation in the next thirty days, and concentrating on the top tier of those scores catches a large majority of what actually gets exploited while leaving most of the backlog alone.

That’s the core of effective patch prioritization: confirmed exploitation first, exposure second, probability of exploitation next, and everything else on a managed schedule.  But be wary. Lower priority should still mean scheduled; the moment it means forgotten you’re back to square one.

How to Document Deferred Patches

When your team defers a patch, write down four things.

  • What it was.
  • Why it waited, in one sentence.
  • What compensating control covers the gap in the meantime, if anything.
  • When you’ll revisit it.

Two lines in a shared document is enough. Nobody needs a form.

That record does three jobs. It gives your insurer something to look at when they ask about your vulnerability management program. Understand that from an insurer’s point of view, saying “we prioritized by confirmed exploitation and documented our deferrals” is a defensible answer, while “we patch when we can” is not. Second, it gives your own team a way to notice when a deferred item’s circumstances change, which happens the instant that CVE lands in KEV. And last but not least, it converts a decision that could’ve been left to drift into a decision somebody actively made and explained.

That last one matters most. The gap between a deferral you chose and a deferral that just happened is invisible in the moment, but it can be of enormous significance later. Same unpatched system, same exposure, but a very different conversation with counsel.

Resilience’s midyear claims data found known vulnerabilities behind 7% of insured cyber losses in the first half of this year, down from a quarter of losses in late 2024. So the patching discipline of the last few years is working. The trouble is that the volume is climbing faster than any small team’s capacity. Something has to give, that just can’t be avoided. The question is whether the thing that gives is deliberately chosen and documented.

Frequently Asked Questions about Patch Management

How should small IT teams prioritize patches?

Prioritize vulnerabilities in CISA’s KEV catalog, then internet-facing vulnerabilities and those with high EPSS scores. Document patches that are deliberately deferred.

What is the CISA KEV catalog?

The CISA Known Exploited Vulnerabilities Catalog identifies vulnerabilities that have been confirmed as exploited in the wild.

What is an EPSS score?

EPSS estimates the probability that a vulnerability will be exploited in the next 30 days.

Should every Microsoft vulnerability be patched immediately?

No. Small IT teams generally need a risk-based patch prioritization process rather than treating every vulnerability as equally urgent.

Leave a Reply

Your email address will not be published. Required fields are marked *