Patch Tuesday Is a Starting Gun, Not a Finish Line

The second Tuesday of every month, Microsoft publishes its latest round of security updates. If you work in IT operations or security, you know the drill – your inbox lights up, your scanning tools start flagging, and someone in the room asks the question nobody wants to answer: which ones do we actually need to worry about?

That question is where most patch management programs fall apart.

The scale of the problem

Before we talk about process, it helps to understand the volume involved. In January 2025 alone, Microsoft addressed 157 CVEs in a single Patch Tuesday release – the largest single release of the decade so far. That’s not unusual – monthly releases regularly land in the 100–180 range, and that’s before you factor in out-of-band emergency patches, third-party application updates, and driver vulnerabilities that don’t show up in the Microsoft bulletin at all.

For a team managing hundreds or thousands of endpoints across Windows Server, Exchange, SQL Server, and Active Directory, the math doesn’t work. You cannot remediate 150+ vulnerabilities a month on top of everything else. Nobody can. So something has to give – and what usually gives is prioritization discipline.

Teams fall back on what’s available: CVSS scores. The scanner says something is a 9.8, so it goes to the top of the list. Except a 9.8 on an isolated development machine with no internet exposure is not the same threat as a 7.2 on a public-facing Exchange server that processes customer data. CVSS scores the vulnerability in isolation. It has no idea what your environment looks like.

The result is alert fatigue, a backlog that grows faster than it shrinks, and remediation effort pointed at the wrong things.

The myth of “patch everything”

The textbook answer is still straightforward: apply all patches as quickly as possible. In practice, nobody does this – and for good reason. Enterprise environments are complex. Patches interact with each other, with third-party software, with configurations that have been in place for years and that nobody fully understands anymore.

Pushing every update blindly is how you end up with a production Exchange server down at 2am on a Wednesday. I’ve seen it happen more than once; one of those times was at financial year end for a global client which multiplied the pain. So teams do what’s rational – they triage, they prioritize, they make judgment calls based on experience and whatever context they can gather. The problem is that this process is almost entirely manual, inconsistent across teams, and impossible to scale as the environment grows.

Context is what the tools don’t give you

Here’s what frustrates me about the current state of vulnerability management: the tools are excellent at finding things. Scanners will dutifully report every missing KB, every outdated library, every misconfigured service. What they won’t tell you is whether a given patch has been causing blue screens across similar environments for the past 48 hours.

Effective prioritization needs to account for at least four things that most tools ignore:

Asset criticality. A vulnerability on a domain controller is not the same as the same vulnerability on a test workstation. Your patching priority should reflect your asset tier list, and that tier list should be deliberate – not something that evolved organically over five years of IT turnover.

Exposure level. An internet-facing server has a fundamentally different risk profile from an air-gapped internal system. Both might carry the same CVE. Only one of them is likely to get exploited before you can schedule the maintenance window.

Client environment profiling. During onboarding, we build a structured profile of the client’s environment through a combination of Microsoft telemetry, system inventory data from Intune, and direct interviews with the team. That process identifies which devices, users, and processes carry the highest operational priority – the systems where downtime has disproportionate business impact. That profile feeds directly into patch prioritization, so the risk scoring reflects the actual shape of the organization, not a generic model.

Real-world deployment outcomes. This is the one nobody talks about enough. Security teams have more vulnerability data than ever and less context than they need. They know what to patch but not whether it’s safe to patch it right now. A patch that’s causing rollbacks across thousands of environments this week is a different calculation than one that’s deploying cleanly. That intelligence should be baked into prioritization, not discovered after something breaks.

Systems over sprints

The teams that handle Patch Tuesday well aren’t the ones with the fastest response times. They’re the ones with a system – a repeatable process that turns a monthly event into business as usual.

That means a few things in practice.

Scanning has to run continuously, not just on the second Wednesday after Microsoft publishes. By the time you’re running your first scan post- release, you’re already behind on context gathering. Your asset inventory needs to be current before the patches drop, not updated reactively afterward.

Prioritization has to be automated and contextual. Human review is appropriate for edge cases and anything that needs a judgment call. It is not appropriate as the primary sorting mechanism for 150+ CVEs a month. Risk scoring that accounts for asset criticality, exposure, and exploitability – applied consistently and automatically – is the only thing that scales.

Deployment pipelines need rollback capability built in from the start. When a patch causes issues – and it will, eventually – the blast radius needs to be contained and recovery needs to be fast. That means staged rollout, not mass deployment. Pilot devices first, then rings of progressively larger groups, with automated health checks between each stage.

SLAs need to be tied to actual risk level, not patch age. A critical CVE on an exposed asset should have a tight SLA. A medium CVE on an isolated internal system can wait for the next scheduled window. Treating everything with the same urgency means nothing actually gets treated urgently.

What a structured program looks like

The difference between a reactive patching cycle and a mature program is most visible in how teams respond to Patch Tuesday over time. In a reactive cycle, the release creates a spike – scanning, manual triage, frantic prioritization, a wave of emergency changes that keep the team busy for two weeks. Then it quiets down. Then next month’s release creates another spike.

In a structured program, the release is just new data flowing into an existing system. Scanning is already running. The asset tier list is already current. The risk scoring runs automatically as new CVE data comes in. The deployment pipelines already have the appropriate rings and health checks configured. What’s left for the team is reviewing the flagged exceptions – the patches that need a human decision because something in the context is unusual.

That shift doesn’t happen overnight, but it doesn’t require a complete overhaul either. The biggest lever is usually prioritization – getting from “we triage by CVSS score” to “we triage by actual risk to this environment.” Everything else builds on that foundation.

Where Patch Veracity fits in

Most of the above is achievable with good process and existing tooling. Where we’ve focused with Patchly is the piece that’s hardest to solve manually: real-world patch intelligence.

Patch Veracity draws on a combination of sources: community telemetry and sentiment analysis from administrator forums and communities, deployment monitoring signals, threat intelligence feeds, and – crucially – early canary and pilot deployments within the client’s own environment. That combination gives a picture of how a patch is actually performing in the real world before it rolls out to the broader estate.

Patches that score above our high-confidence threshold can be auto-approved and routed to the next maintenance window. Patches with known issues get flagged for review with specific context about why they need attention – not just a severity rating, but actual deployment outcome data. The high-confidence decisions get automated. The edge cases get human attention. That’s the division of labor that makes the system scale.

Patch Tuesday is a starting gun. The scanning, the prioritization framework, the deployment pipelines – all of that should be running before the updates drop. The monthly release is just new data. That’s what it looks like when it’s working.

---

Related reading: Finding Vulnerabilities Is Easy. Proving You Fixed Them Is the Hard Part. | Agentless Patch Management: Why We Chose Native Microsoft Integration

Want to see how Patch Veracity prioritization works in a Microsoft environment like yours? Book a 30-minute walkthrough and we’ll show you exactly what the triage output looks like for your environment.