As reported by BleepingComputer, Microsoft has finally resolved persistent Always On VPN connection failures triggered by the September 2026 Windows 11 security updates — but only after mistakenly claiming the issue was fixed in October's cumulative updates. For enterprises reliant on Always On VPN for remote workforce connectivity, this two-month saga offers important lessons about resilience, vendor communication, and the hidden costs of security patches.

Security Impact: As reported by BleepingComputer, Microsoft has finally resolved persistent Always On VPN connection failures triggered by the September 2026 Windows 11 security updates — but only after mistakenly claiming the issue was fixed in October's cumulative updates.

Why This Matters Beyond the Headline

Always On VPN isn't a convenience feature — it's critical infrastructure for many organizations. It replaced DirectAccess and serves as the seamless tunnel connecting domain-joined, non-domain-joined, and Entra ID-joined devices back to corporate networks. When it breaks at scale, remote workers lose access to internal resources, help desks get flooded, and productivity grinds to halt. The fact that Microsoft's first fix attempt failed — and that the issue persisted for nearly two months — should give every Windows shop pause.

The root cause involved automatic protocol selection logic interacting badly with IKEv2 and SSTP fallback behavior. VPN clients would get stuck in a "Connecting" state or throw the error "The specified port is already in use" after an initial connection failure. This is the kind of subtle race condition that's easy to miss in testing but devastating in production.

Who Was Most Affected

Why This Matters Beyond the Headline
Fully remote and hybrid organizations with large Windows 11 fleets using Always On VPN as the primary corporate access method
Entra ID-joined device deployments where IT has less direct control over client configuration
Environments relying on automatic protocol selection rather than explicitly configuring a single tunneling protocol
Help desk and support teams burdened with repeated user complaints and no clear resolution timeline

The Vendor Communication Problem

Microsoft previously flagged this known issue as fixed in the October 2026 cumulative updates — but it wasn't. That false resolution likely caused IT teams to deprioritize workarounds, expecting the problem to resolve on the next patch cycle.

This pattern of premature "fixed" declarations erodes trust. When a vendor marks a known issue resolved and it isn't, defenders waste cycles re-verifying, re-opening tickets, and re-engaging end users. Worse, it discourages the implementation of workarounds that could have restored functionality sooner. Security teams should treat vendor advisory status updates with healthy skepticism and independently validate fixes before communicating "all clear" to their organizations.

The Workaround That Should Have Been Day-One Guidance

Microsoft's interim mitigation — switching Always On VPN profiles from automatic protocol selection to a single protocol (SSTP or IKEv2 only) — is straightforward and effective. But this guidance came late. Organizations that proactively harden their VPN profiles with explicit protocol configuration rather than relying on automatic selection would have avoided this issue entirely. This is a broader lesson: automatic fallback logic is a reliability liability in critical infrastructure. Explicit configuration reduces ambiguity and attack surface.

Shield53 Recommendations

  • Install KB5127936 (October 2026 preview update) on affected Windows 11 systems if you've been experiencing Always On VPN failures. If you prefer to wait, the fix will roll into November's Patch Tuesday cumulative update.
  • Apply the protocol workaround now if you haven't: set Always On VPN profiles to use either SSTP only or IKEv2 only based on your environment's security and connectivity requirements. Don't wait for the patch if users are currently impacted.
  • Audit VPN configuration profiles enterprise-wide for automatic protocol selection. Standardize on a single protocol where possible to reduce future exposure to similar issues.
  • Build a VPN break/fix playbook that includes vendor-independent workarounds. Don't assume the next patch will fix the problem — have fallback configurations tested and ready to deploy.
  • Track known issues independently through Microsoft's Windows Release Health dashboard and validate fixes in a pilot group before declaring resolution to your organization.
  • Review Remote Desktop issues if you use the "Administrator protection" security feature — the same KB5127936 update also fixes a known issue blocking non-admin RDP connections introduced by September's preview updates.

Broader Implications

This incident underscores a growing tension in enterprise IT: security patches are mandatory, but they increasingly ship with functional regressions that disrupt business operations. The September 2026 updates were security updates — organizations couldn't skip them without accepting risk. Yet deploying them broke VPN connectivity for weeks. This is the patch management paradox: you must patch to stay secure, but patches themselves can create operational risk.

Organizations need structured patch testing pipelines that specifically validate critical infrastructure like VPN, RDP, and authentication after every update cycle. A 24-48 hour pilot deployment with automated VPN connection health checks would have caught this issue before it hit the broader fleet. Treat patch testing as a security investment, not an operational afterthought.