The company corrected its Windows release health entry for the issue, tracked as WI1482218. In that notice, Microsoft said "This disclosure was mistakenly updated to Resolved status on October 13, 2026. We have returned its status to Mitigated," Microsoft said. "We apologize for any inconvenience or confusion." The bug remains open, and Microsoft has not given a date for a real fix.
What is actually broken
Always On VPN is the VPN client built into Windows for enterprise remote access. The Register describes it as a useful bit of code that quietly opens a VPN connection in the background without tiresome prompts for authentication. It dates back to Windows 10, and Microsoft alerted administrators to problems after the September 2026 Windows security update inadvertently broke it.
The bug does not hit every VPN setup. According to The Register, the problem could occur when the VPN was set to try a different connection method if the initial connection failed (Microsoft gave the example of using automatic protocol selection with IKEv2 and SSTP). Put simply, the failure is in the fallback path. When the first connection attempt fails, Windows is supposed to try the other protocol, and that switch is where things go wrong.
Microsoft lists these symptoms:
- "Affected VPN connections might remain in a 'Connecting' state or repeatedly attempt to connect without succeeding.
- Subsequent connection attempts might also display the error: 'The specified port is already in use'."
On scope, The Register reports that the issue affects Windows 11 versions from 24H2 through 26H2. Nothing in the evidence suggests VPN encryption was weakened. This is a problem with getting connected, not a security hole. That still hurts if your remote staff can't reach the file server on Monday morning.
Section summary: The bug affects Always On VPN on Windows 11 24H2 through 26H2, starting with the September 2026 security update. It only shows up when automatic protocol selection or fallback is configured. Connections hang at "Connecting" or fail with a port-in-use error.
How a fix got marked fixed
On October 13, Microsoft shipped three Windows 11 packages. As WindowsForum previously reported, KB5127648 covers versions 26H2, 25H2 and 24H2. KB5127646 is for the Arm-only 26H1 release, and KB5126653 is for 23H2. The VPN fix was one of the main items in the release notes, next to fixes for Explorer black screens on Azure Virtual Desktop and for Storage Spaces Direct disks.
Microsoft's own support pages now show the correction. The change logs for both KB5127648 and KB5127646 carry an October 20 entry saying information about the Always On VPN fix was removed from the article and that the change will be included in a future release. That detail matters for two reasons:
- The retraction covers more than one KB. Both pages were edited, including the 26H1 page for KB5127646. The Register's affected-version list names only 24H2 through 26H2, so 26H1 administrators should be careful about assuming they're in the clear.
- Old copies of the notes are now wrong. BeenCrypted pointed out that Microsoft's earlier claim appeared in both its release notes and its service alert. Admins who installed the October updates may therefore still see the bug. They cannot rely on the earlier notes to say the problem is gone. If your change-management ticket says "resolved by KB5127648," reopen it.
How does a fix get marked done when it isn't? Microsoft hasn't said. The Register summed up the situation fairly: "This disclosure was mistakenly updated to Resolved status on October 13, 2026. We have returned its status to Mitigated." That is about as plain as Microsoft gets. It's also a reminder that the "Resolved" label on the release health dashboard is a claim, and claims need testing.
Section summary: Microsoft quietly removed the VPN fix from both the KB5127648 (24H2/25H2/26H2) and KB5127646 (26H1) release notes on October 20. Any internal documentation that treats the October updates as the cure is now out of date.
The workaround: pick one protocol and stay there
The mitigation is the same as before. Microsoft's guidance, as relayed by BleepingComputer via Mezha, is to change the Always On VPN profile from automatic protocol selection to either SSTP only or IKEv2 only, depending on the organization's environment and configuration. The Register noted the frustrating part: The bad news is that, because last week's fix did not work, affected administrators will need to apply the workaround for a bit longer.
Here is a sensible way to work through it:
- Take inventory. Find out which Windows 11 versions and cumulative updates are on your fleet. The affected range is 24H2, 25H2 and 26H2 with the September 2026 update or later installed.
- Audit your profiles. Check which Always On VPN profiles use automatic protocol selection or IKEv2/SSTP fallback. Profiles already locked to one protocol aren't in the affected configuration.
- Choose the protocol that fits your environment. Microsoft doesn't name one, and the right answer depends on your gateway, authentication and network path. IKEv2 and SSTP have different firewall and network requirements, so pick based on what your infrastructure actually supports. (This is general industry knowledge, not Microsoft guidance.)
- Pilot first. Push the single-protocol profile to a test group, confirm connections succeed from the networks your users really work from, and then deploy more widely.
- Leave the pin in place until Microsoft ships a fix you've verified yourself. Don't treat a status label as proof.
You give up something with this workaround. Fallback exists so that if one protocol is blocked, for example IKEv2 on a hotel network that drops its traffic, the client can try the other one. Pinning to a single protocol fixes the hang but removes that safety net, so some users on restrictive networks may still have trouble connecting. Neither option is great until the patch arrives.
Also note what Microsoft has not recommended: uninstalling security updates. The official mitigation is a change to the VPN profile, not removing the patch.
Section summary: Lock affected profiles to IKEv2-only or SSTP-only, test before rolling out widely, and accept that you lose automatic fallback until a working fix arrives.
Don't confuse it with a different VPN gotcha
The October updates included one more change that can break VPN connections, and it's easy to blame the wrong cause. On October 15, Microsoft added a note to the KB5127648 page. It says the update changes NTLMv1 handling: when the BlockNtlmv1SSO registry value isn't set, Windows now defaults to Enforce mode and blocks NTLMv1-derived credentials for single sign-on. According to Microsoft, this applies only to devices with Credential Guard disabled and that registry value unset. It might affect Wi-Fi, Ethernet and VPN connections that use MS-CHAPv2-based authentication.
That behaves differently from the Always On VPN fallback bug. If your failures look like authentication rejections rather than hangs at "Connecting" or port-in-use errors, check your MS-CHAPv2 dependencies before you start pinning protocols. WindowsForum's earlier coverage also tracked reports of enterprise Wi-Fi authentication failures after KB5127648. Our view at the time was that those reports do not yet establish a widespread regression or justify treating every corporate wireless network as affected.
A crowded month for Windows admins
The VPN reversal comes during a messy October. Windows Report notes that the VPN issue is not the only problem affecting the October 2026 updates. Users have also reported installation errors 0x800f0845 and other failures, while Microsoft has confirmed problems with Smart App Control. The KB5127648 page also lists a known issue where non-admin Remote Desktop connections to hosts with Administrator protection enabled can fail with error 0xC000000D.
There's a lifecycle point as well. Microsoft's KB5127648 page says Windows 11 version 24H2 Home and Pro editions have reached end of updates, and the October 2026 security update is the last one for those editions. Microsoft has not said which versions and editions will get the eventual VPN fix. Organizations still running 24H2 consumer editions on business machines should plan upgrades now rather than wait to find out.
When does the real fix arrive?
Microsoft's only commitment is vague. Per BleepingComputer's reporting relayed by Mezha, a resolution for this issue is planned to be included in an update to be released in the coming weeks. "Planned" is not a release date, and the October episode shows that even a published fix needs checking. When the update ships, test it on a pilot group with fallback re-enabled before you remove the protocol pin across the fleet.
For now, Always On VPN on Windows 11 24H2 through 26H2 should be treated as broken when fallback is enabled, whatever the old release notes said. Lock profiles to one protocol, record why you did it, and verify any future fix yourself.