TL;DR: September 2026 brought 995 Microsoft patches, 119 critical vulnerabilities and two actively exploited zero-days, according to Action1, but the real issue is that discovery and exploitation are outpacing the capacity to assess, prioritise and safely remediate them. Risk-based remediation now matters more than calendar-driven patch cycles.
At a glance
What this is: This is a patch-management analysis arguing that record vulnerability volume is making calendar-based remediation less effective than risk-based prioritisation.
Why it matters: It matters because IAM, NHI and platform teams must now decide faster which systems expose privilege, identity infrastructure or business-critical services to exploitation risk.
By the numbers:
- September 2026 delivered 995 Microsoft patches, including 119 Critical vulnerabilities and two actively exploited zero-days, according to Action1.
- CrowdStrike reported that 88% of exploitation involving vulnerabilities with public proof-of-concept code occurred within 48 hours of PoC release, according to Action1.
Context
Patch volume is becoming a governance problem, not just an operations problem. When a single monthly release contains hundreds of issues, teams cannot rely on a fixed cadence and a generic severity score to decide what to fix first.
That pressure is especially relevant where identity systems, production servers and externally reachable services are in scope, because the blast radius of a missed patch is often determined by access pathways, privilege and business dependency rather than the vulnerability description alone.
Key questions
Q: What breaks when organisations rely on calendar-based patching for high-volume releases?
A: Calendar-based patching breaks when vulnerability disclosure and exploitation move faster than the next maintenance window. Teams end up treating every issue as either urgent or deferrable, which creates backlog, decision fatigue and avoidable exposure. Risk-based remediation works better because it ties patch timing to asset criticality, privilege, exposure and the likely impact of delay.
A: A software flaw becomes more dangerous when the impacted system can reach privileged accounts, tokens, or secrets stores, because attackers can convert one foothold into broader access. Patch timing matters, but standing privilege and stale credentials often determine the real blast radius. Teams should map these identity dependencies before a vulnerability is disclosed.
Q: What are the warning signs that patch prioritisation is failing?
A: The clearest signs are a backlog dominated by critical flaws, repeated exceptions for internet-facing assets, and remediation orders that ignore where privileged data or admin reach actually sits. If teams can list vulnerabilities but not explain which ones can reach sensitive systems fastest, prioritisation is failing.
Q: How should security teams decide when to mitigate instead of patching immediately?
A: Use mitigation when the deployment risk is higher than the temporary exposure and when compensating controls can reduce the chance of exploitation. That decision should be pre-authorised for critical services, based on asset class, exposure, and the operational cost of downtime. The goal is not to avoid patching, but to choose the safest sequence under pressure.
Technical breakdown
Why cumulative patch releases create operational backlog
Modern operating systems bundle many fixes into cumulative updates, which reduces deployment complexity but does not reduce analysis work. Security teams still need to understand what changed, which assets are affected, whether the update is safe to apply, and what dependencies could break. In practice, the hard part is not installation but deciding where testing, coordination and outage tolerance are required. That decision load scales faster than most remediation teams can absorb when release sizes spike.
Practical implication: build classification and change-impact review into the patch workflow before the update reaches production.
Why CVSS alone fails for patch prioritisation
CVSS describes vulnerability severity in general terms, but it does not capture whether the affected system is internet-facing, whether exploitation is active, or whether compromise would expose identity systems or other high-value assets. A medium-scoring issue on a privileged or externally reachable system can matter more than a higher-score issue on an isolated host. Risk-based remediation therefore depends on environmental context, business criticality and blast radius, not score alone.
Practical implication: pair vulnerability scoring with asset exposure and privilege context before assigning remediation priority.
How exposure windows shrink when discovery accelerates
AI-assisted vulnerability discovery is shortening the window between public disclosure and real exploitation. The article notes that proof-of-concept release can trigger rapid weaponisation, which means defenders often have hours or days, not weeks, to decide whether to patch, mitigate or isolate. That changes patch management from a scheduled maintenance activity into a time-sensitive risk decision process tied to detection, inventory and safe deployment capacity.
Practical implication: reduce time-to-identify and time-to-action so that remediation decisions are made before exploitation begins.
Threat narrative
Attacker objective: The attacker aims to convert a short remediation window into reliable access, privilege escalation or service disruption before defenders can respond.
- Entry begins when publicly disclosed vulnerabilities are discovered and exploited faster than teams can classify and patch affected systems.
- Escalation occurs when an exposed system or identity-adjacent workload remains unremediated long enough for attackers to chain it into higher privilege or broader access.
- Impact is operational and security disruption, especially when the vulnerable system supports business-critical services or identity infrastructure.
Breaches seen in the wild
- ShinyHunters FBI breach claim 2026: ShinyHunters claims it used a PeopleSoft flaw to breach the FBI and pivot into AWS GovCloud; the FBI has confirmed only an investigation.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Patch velocity is no longer the control that matters most. When disclosure outpaces testing and deployment, the decisive governance question becomes which systems can safely wait and which cannot. That shifts the centre of gravity from monthly patch cadences to risk acceptance, asset criticality and business dependency.
Identity infrastructure deserves separate remediation policy. The article correctly notes that some systems, such as identity platforms, have outsized blast radius when compromised. That is a governance issue as much as a technical one, because access paths can turn a routine vulnerability into an enterprise-wide exposure. Practitioners should treat privileged and identity-bearing systems as a distinct remediation class.
Operational backlog is now a security signal, not just an IT inefficiency. When teams cannot determine exposure, classify impact and authorise action quickly, the remediation process itself becomes part of the attack surface. The named concept here is remediation latency debt, meaning the accumulated delay between disclosure, internal validation and action. Organisations that let that debt grow will always lose ground to faster exploitation.
Risk-based patching is becoming a governance discipline. This article reinforces a broader truth across vulnerability management: the organisation must pre-decide who can approve urgency, what constitutes acceptable temporary mitigation and where downtime is tolerable. Without those decisions, every serious patch turns into an ad hoc business debate.
For IAM and NHI teams, patch management and privilege management are now intertwined. A vulnerable system with elevated access is not just a patching problem, because compromise can expand through credentials, service accounts and administrative pathways. That means patch prioritisation must account for privilege, not just software exposure.
From our research library:
- Only 26% of known exploited vulnerabilities were fully remediated in 2025, down from 38% the year before, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: Vulnerability Management Guide
What this signals
Remediation latency debt: The real risk is the accumulated delay between discovery, environmental validation and action. Once that delay grows, the organisation is no longer responding to vulnerabilities as a governed process but as a queue of emergencies, which is exactly how exploiters gain advantage.
Teams should treat patch management as part of resilience planning, not a narrow endpoint task. That means pre-defining which systems can tolerate delay, which require accelerated approval and which need compensating controls when immediate patching is unsafe.
For practitioners
- Define risk-based remediation tiers Classify assets by exposure, business criticality and privilege so that patch urgency reflects blast radius rather than release size alone.
- Separate identity systems from standard maintenance queues Create a distinct approval path for identity infrastructure, privileged platforms and systems whose compromise would expand access across the environment.
- Measure remediation latency in three points Track the time from disclosure to environmental identification, from identification to decision, and from decision to mitigation or patch.
- Automate low-risk deployments where change impact is predictable Use automation for repeatable, low-risk updates so human effort stays focused on systems where testing, coordination or rollback planning is required.
Key takeaways
- Record patch volume is only part of the problem, because the harder issue is deciding what matters first when vulnerability discovery accelerates.
- The control failure is often organisational rather than technical, since slow classification and approval can matter more than the patch itself.
- The most effective response is a risk-based remediation model that prioritises exposure, privilege and business criticality before the next maintenance window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0004; TA0006 — Privilege Escalation; Credential Access | Patch delay increases the chance that attackers convert flaws into privilege or credential access. |
| Recommendation — Map high-risk vulnerabilities to privilege-escalation and credential-access tactics when prioritising remediation. | ||
| NIST CSF 2.0 | ID.RA-05 — Vulnerabilities are identified and prioritized in context | The article centres on prioritising vulnerabilities using exposure and business context. |
| Recommendation — Use contextual risk analysis to rank vulnerabilities by exposure, privilege and business impact. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The piece is fundamentally about continuous remediation under accelerating disclosure pressure. |
| Recommendation — Operate continuous vulnerability management with asset inventory, prioritisation and fast remediation cycles. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The article argues for faster identification and action as vulnerability volume rises. |
| Recommendation — Use RA-5 to improve vulnerability detection, tracking and response timelines across the environment. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Patch governance and remediation timing are central to technical vulnerability management. |
| Recommendation — Apply A.8.8 to govern vulnerability intake, triage and remediation across critical assets. | ||
Key terms
- Risk-Based Remediation: A remediation approach that ranks vulnerabilities by business impact, exploitability, asset criticality, and ownership rather than by severity alone. It depends on normalised data and clear accountability so that automation supports decision-making instead of replacing it.
- Remediation Latency: The time between identifying a security issue and fully removing or reducing the risk. For NHIs and SaaS access, this metric matters because stale credentials, over-shared files, and dormant integrations stay usable until the control finally acts.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Continuous vulnerability governance: A governance model where vulnerability priority is recalculated as conditions change, rather than assigned once at discovery. It depends on fresh evidence, clear ownership and records that show why a remediation or exception decision was made.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM and secrets management. It helps practitioners connect identity controls to the broader security programme they run every day.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org