Summary
- Microsoft incorrectly marked an Always On VPN connection failure as resolved by its 13 October Windows updates.
- On 20 October, the company withdrew the fix claim and returned the issue to mitigated status.
- Affected organisations can configure a supported single VPN protocol while Microsoft develops a permanent correction.
Microsoft has withdrawn its claim that October’s Windows security updates fixed an Always On VPN connectivity problem, acknowledging that the issue remains unresolved for affected enterprise systems.
The company corrected its position on 20 October, a week after describing the problem as fixed in the cumulative updates released on 13 October. Microsoft’s revised service communication returned the issue to mitigated status, with a permanent correction planned for a future update.
The fault concerns Windows 11 devices using automatic VPN protocol selection or fallback. Following certain September security updates, a failed connection attempt can leave the VPN client unable to establish a subsequent connection, disrupting access to corporate networks and services.
Microsoft’s October correction does not withdraw the security updates themselves. It concerns the accuracy of a specific fix claim and the continued need to manage the underlying connectivity problem.
Connection failures followed September updates
Always On VPN provides managed Windows devices with a way to establish secure connections to an organisation’s network, including configurations that initiate a tunnel automatically when the device connects to the internet.
The feature can support user and device authentication, central network policy enforcement and access to applications that are not directly available over public networks.
Microsoft acknowledged problems affecting Windows 11 version 24H2 and later after September 2026 security updates were installed.
Under affected configurations, an initial connection failure could leave the client in a persistent connecting state, preventing further attempts from completing normally.
Some devices displayed an error indicating that the required connection port was already in use. The problem was particularly associated with profiles configured to select a tunnel protocol automatically or fall back to another protocol when the original connection failed.
Those symptoms describe a failure of connectivity rather than a demonstrated compromise of the underlying VPN encryption or authentication mechanisms.
An affected organisation might find that employees could not reach internal applications or that devices failed to establish their expected managed connections. Whether other network access remained available depended on its configuration and policies.
The issue could also affect support procedures because repeated attempts to reconnect might reproduce the failure rather than restore access.
October’s resolved status proved incorrect
Microsoft initially described the fault as corrected in the 13 October cumulative updates, including KB5127648 for Windows 11 versions 24H2, 25H2 and 26H2, and KB5127646 for version 26H1.
The company also changed its service advisory to resolved, indicating that the corrective release had been delivered.
That designation was subsequently withdrawn.
Microsoft’s published KB5127646 change log records the removal of the Always On VPN fix information on 20 October and states that the correction will instead be included in a future release.
A separate administrator communication, identified as WI1482218, explains that the issue had been incorrectly marked resolved on 13 October and was being returned to mitigated status.
The service communication has been reported by BleepingComputer and The Register. Its contents are not available through the public KB documentation without administrator access.
Public release information has also been inconsistent. While Microsoft’s correction is reflected in the KB5127646 change history, versions of the KB5127648 support page have continued to display the original fixed entry.
The discrepancy does not override the explicit withdrawal or establish that the connection fault was successfully corrected on a different affected Windows branch.
Until Microsoft delivers and confirms a replacement fix, the October cumulative update should not be treated as proof that automatic protocol selection is functioning reliably in the affected configurations.
Single-protocol configuration remains the workaround
Microsoft’s temporary mitigation involves replacing automatic protocol selection with a fixed tunnelling protocol in the affected VPN profile.
The company’s administrator guidance identifies Secure Socket Tunnelling Protocol, or SSTP, and Internet Key Exchange version 2, or IKEv2, as alternatives for supported configurations.
The choice is not interchangeable across every VPN deployment. A particular gateway, certificate arrangement or network policy may support one protocol more effectively than another.
Microsoft’s documentation also distinguishes user tunnels from device tunnels. Device tunnels support IKEv2 only, so an SSTP-only approach cannot be applied indiscriminately to every Always On VPN profile.
Organisations using central device management can distribute the appropriate profile configuration, although the change must remain compatible with their existing remote access infrastructure.
Restricting the profile to one protocol can restore a more predictable connection path for affected devices while avoiding the automatic selection behaviour implicated in the failure.
It remains a mitigation rather than a repair to the Windows component responsible for the problem.
Incorrect patch status affects operational decisions
Enterprise maintenance records often distinguish between a known issue that has been mitigated and one that has been resolved by a vendor correction.
Those states can lead to different administrative decisions. A temporary configuration may be retained while a fault remains mitigated, but removed once the vendor identifies a permanent remedy and the organisation has verified the fix.
Microsoft’s original designation could therefore have led administrators to expect that installing October’s update was sufficient to retire the workaround.
Because the fault remains, restoring automatic protocol selection solely on that basis could reintroduce connection failures.
The problem also intersects with remote working and managed access. An unavailable tunnel can prevent devices from reaching systems that depend on corporate connectivity, although the published issue does not establish that protected data was transmitted insecurely.
The distinction between service availability and confidentiality is important when classifying the incident. The known failure affects the establishment and recovery of network connections, not a confirmed bypass of VPN security controls.
Microsoft has not identified the exact update that will contain the permanent correction. Its administrator advisory describes a fix planned for the coming weeks, while the 20 October change log confirms that the previously advertised remedy has been deferred.
