September 2026 delivered a number that would have sounded extraordinary only a few years ago: 995 Microsoft patches, including 119 Critical vulnerabilities and two actively exploited zero-days, according to Action1’s September Patch Tuesday analysis.
But the bigger story is not the number itself.
The real question is whether vulnerability discovery is beginning to move faster than organizations can realistically assess, test, prioritize, and remediate what is being found.
For many IT teams, the answer is increasingly yes.
The challenge is no longer simply getting patches deployed. It is deciding what needs attention first when everything seems urgent, doing it fast enough to stay ahead of exploitation, and avoiding unnecessary disruption to critical systems.
More vulnerabilities do not simply mean more patches
At first glance, a very large Patch Tuesday release might not seem dramatically different operationally. Microsoft uses cumulative updates, so administrators are not necessarily deploying hundreds of individual patches.
That does not mean hundreds of new vulnerabilities create no additional work.
Every vulnerability still has to be understood in the context of the organization’s environment. Security and IT teams need to determine which systems are affected, how exposed they are, whether exploitation is occurring, what business functions those systems support, and what risk deployment itself may introduce.
A cumulative update can address many vulnerabilities at once, but organizations still need to understand what the update changes and whether it can be deployed safely to critical workloads.
For an employee workstation, deployment may be relatively straightforward. For an identity system, production server, database, or business-critical application, the decision may require testing, coordination, maintenance windows, contingency planning, or temporary mitigation.
That is where vulnerability volume turns into operational burden.
The question we hear is no longer “Can we patch this?”
Two questions come up repeatedly in conversations with IT teams:
Where do we start?
And:
How do we manage all of this?
Those questions say a lot about where vulnerability management is heading.
For years, many organizations could operate around a predictable monthly patching cycle. Updates arrived, teams tested them, scheduled maintenance windows, deployed them, and repeated the process the following month.
That model becomes harder to sustain when vulnerability discovery and exploitation accelerate while IT teams remain constrained by the same maintenance windows, staffing levels, testing requirements, and business dependencies.
Calendar-based patching is increasingly giving way to risk-based remediation.
The question should not be, “Is it Patch Tuesday?”
It should be, “What is our risk right now, and what should we do about it?”
AI is accelerating vulnerability discovery
AI is contributing to that shift.
Microsoft says advanced AI models can now discover vulnerabilities, chain weaknesses together and generate working proof-of-concept code. Microsoft is already incorporating AI-powered vulnerability discovery into its own security development processes and has said these systems enable it to find more vulnerabilities, more quickly, across a broader attack surface.
That is good news for software security. Finding vulnerabilities before attackers do gives vendors an opportunity to address risk earlier.
But there is a downstream consequence: defenders should prepare for a world in which more vulnerabilities are discovered, and they are discovered faster.
That same acceleration exists on the offensive side. CrowdStrike reported that during the first half of 2026, 88% of the exploitation it observed involving vulnerabilities with public proof-of-concept code occurred within 48 hours of PoC release.
The implication for defenders is straightforward: the time available to make remediation decisions is shrinking.
CVSS alone cannot tell you what to patch first
When hundreds of vulnerabilities arrive at once, simply sorting them by CVSS score is not enough.
The same vulnerability can represent dramatically different levels of risk in two organizations, or even on two systems inside the same organization.
An internet-facing system handling customer data is different from an isolated internal workstation. An identity server is different from a test machine. A vulnerability that could enable privilege escalation becomes much more significant if the affected system provides an attacker with access to critical infrastructure.
Organizations need to add environmental and business context.
At a minimum, prioritization should consider:
- Active exploitation: Is there evidence that attackers are already using the vulnerability?
- Exposure: Is the affected system internet-facing or otherwise easily reachable?
- Exploitability: What conditions are required to exploit it?
- Business criticality: What happens if this system is compromised or unavailable?
- Privilege and blast radius: Could compromise provide access to other systems or identities?
- Existing controls: Are compensating controls already reducing the practical risk?
- Deployment risk: How safely and quickly can the remediation be applied?
This turns a generic vulnerability severity rating into something much more useful: the actual risk the vulnerability creates in your environment.
Start with inventory, not the vulnerability list
None of that is possible without accurate inventory.
Before an organization can make good remediation decisions, it needs to know what it has, where it is, what software is running, what vulnerabilities affect it, and what role each system plays in the business.
The next step is classification.
A payroll system, for example, carries different business consequences from an employee workstation. Identity infrastructure may deserve special treatment because compromising it can enable much broader access. Customer-facing production systems may require prioritization because downtime or compromise directly affects customers and the business.
Once assets are classified, organizations can establish policies around acceptable risk and remediation urgency.
That creates a repeatable decision framework rather than forcing administrators to reinvent the decision every time a vulnerability appears.
For smaller teams, measure the gaps between three moments
SMB and midmarket organizations often do not have dedicated vulnerability-management teams. They may have the same exposure to vulnerabilities as much larger enterprises, but considerably fewer people available to investigate and remediate them.
The answer is not to build an enormously complicated process.
Start by measuring three things:
- When did we learn that the vulnerability existed?
- When did we determine that it affected our environment?
- When did we remediate or mitigate it?
Then look at the time between those points.
If it takes days to determine whether a newly disclosed vulnerability exists in your environment, improve visibility.
If teams know exactly where the vulnerability exists but spend days deciding whether they have permission to patch it, improve the decision process.
If administrators repeatedly perform the same low-risk deployment actions manually, determine whether those actions can be automated.
The objective is not simply to make technicians work faster. It is to eliminate unnecessary delay from the remediation process.
Vulnerability management is becoming a business-continuity function
One of the biggest mistakes organizations can make is treating vulnerability management exclusively as an IT operational problem.
IT teams cannot independently decide how much downtime a revenue-generating system can tolerate, how much risk the organization is willing to accept, or whether a critical business process can be interrupted to deploy an urgent fix.
Those are business decisions.
Effective vulnerability management therefore requires clear policies and management involvement before a crisis occurs.
Teams should already know which systems are most critical, who can authorize emergency remediation, what level of risk triggers accelerated action, when mitigation is acceptable instead of patching, and when risk must be formally accepted.
The more of those decisions that can be made in advance, the faster organizations can respond when a serious vulnerability appears.
The patching model has to change
September’s record Microsoft release is an extreme example, but it points toward a broader trend.
AI-assisted discovery means vendors are becoming better at finding vulnerabilities. Attackers are becoming faster at operationalizing information. At the same time, organizations still have finite people, testing capacity, maintenance windows, and tolerance for disruption.
Trying to treat every vulnerability as equally urgent is impossible.
Treating all of them as something that can wait for the next scheduled patch cycle is increasingly dangerous.
The organizations best positioned for this environment will be the ones that can quickly answer four questions:
- What do we have?
- Where are we exposed?
- What matters most?
- How quickly can we safely reduce that risk?
The future of patch management is not about patching everything at maximum speed.
It is about knowing what requires speed, what can wait, and why.
