As reported by BleepingComputer, Microsoft has confirmed that its September 2026 Windows 11 security updates are disrupting Always On VPN connections, leaving remote workers unable to establish corporate tunnels. The root cause appears to be a regression in how the VPN client handles automatic protocol selection — specifically the fallback behavior between IKEv2 and SSTP — causing connections to hang indefinitely or throw a "port already in use" error.
This is not an isolated incident. The September 2026 patch cycle has been unusually destructive, with Microsoft already issuing emergency out-of-band fixes for Hyper-V, Remote Desktop Services, and USB audio failures, plus acknowledged but unresolved bugs affecting domain credential logins and File History backups. The Always On VPN breakage compounds an already painful Patch Tuesday for enterprise IT teams trying to balance security hygiene against operational stability.
Why This Matters More Than a Typical Patch Bug
Always On VPN is the successor to DirectAccess and is heavily deployed in enterprise environments where seamless, zero-touch remote access is a requirement. Unlike a user-initiated VPN connection that someone can simply retry or switch protocols on manually, Always On VPN operates as a background service — meaning affected users may have no idea their corporate tunnel is down until they try to access an internal resource and fail silently. This creates a particularly dangerous scenario for organizations that route DNS, identity validation, or security tooling telemetry through the VPN tunnel.
The connections don't fail loudly — they hang in a perpetual "Connecting" state. That means security agents, compliance checks, and internal certificate revocation checks may all be quietly failing in the background while the user appears to be working normally.
Affected Updates and Versions
| Windows Version | Originating Update | Impact |
|---|---|---|
| Windows 11 26H1 | KB5124012 | Always On VPN fails with auto protocol selection |
| Windows 11 25H2 | KB5124008 | Always On VPN fails with auto protocol selection |
| Windows 11 24H2 | KB5124008 | Always On VPN fails with auto protocol selection |
No CVE is associated with this specific regression — it is a functional defect introduced by the security update, not a vulnerability itself. However, organizations that choose to delay patching to avoid this issue are exposing themselves to whatever vulnerabilities the September updates were designed to address. That trade-off is the real risk.
Who Is Most Exposed
Shield53 Recommendations
Immediate Actions
- Identify affected endpoints now: Query your MDM/UEM inventory for devices running KB5124012 or KB5124008 and cross-reference with Always On VPN profile deployment. Prioritize devices with automatic protocol selection configured.
- Apply Microsoft's workaround: Modify the Always On VPN profile to use a single protocol — either IKEv2 only or SSTP only — rather than automatic selection. This can be pushed via Intune custom XML, PowerShell, or Group Policy depending on your management stack.
- Choose the protocol deliberately: IKEv2 offers faster reconnection and better performance for mobile users but requires UDP port 500/4500 egress. SSTP uses TCP 443, which traverses restrictive networks better but has higher overhead. Match the protocol to your users' network environments, not just your infrastructure preference.
- Monitor for silent failures: Deploy a detection check that validates actual tunnel connectivity (not just service status) — query the VPN interface state or test reachability to an internal endpoint. Service running ≠ tunnel connected.
Strategic Actions
- Reassess patch deployment cadence: The September 2026 cycle has produced five confirmed regressions across different Windows subsystems. If your organization deployed these updates broadly without a staged rollout, this is a signal to reinstate ring-based deployment with health validation gates.
- Review VPN architecture resilience: A single protocol fallback bug should not take down remote access entirely. Consider whether a secondary access method (ZTNA, conditional access with app-level proxies) should be part of your remote access strategy as a failover path.
- Document the rollback plan: If Microsoft does not resolve this quickly and the workaround is insufficient for your environment, know which KB to uninstall and what security exposure that creates. Have the risk acceptance documented before you need it.
Microsoft has not provided a timeline for a permanent fix. Given the pattern of this patch cycle, we recommend treating the workaround as the operational baseline for the foreseeable future rather than a stopgap you expect to remove next week.
