KB5124008 breaks certificate-based Always On VPN on Windows 11 (September 9, 2026)
Chapters
What broke
An administrator described Always On VPN profiles using certificate-based authentication that simply stop connecting once KB5124008 is installed. The back end is RRAS with NPS on Windows Server 2019, and the profiles reach the clients through Microsoft Intune. Clients on both Windows 11 24H2 and 25H2 behave the same way.
The thread went up at 08:45:16 UTC on September 9, 2026 and had an answer 40 minutes later, at 09:25 UTC. That is the whole public record for this one on the day it appeared: one detailed report, one answer, no vendor statement.
| Layer | What the report describes |
|---|---|
| Clients | Windows 11 24H2 and 25H2 |
| Update | KB5124008, builds 26200.9445 (25H2) and 26100.9445 (24H2) |
| VPN | Always On VPN with certificate-based authentication |
| Back end | RRAS with NPS on Windows Server 2019 |
| Management | Microsoft Intune deployed VPN profiles |
| Recovery | Uninstall KB5124008 and reboot |
TL;DR
Certificate-based Always On VPN tunnels on Windows 11 stopped connecting after KB5124008, the September security update, according to a Microsoft Q&A thread opened at 08:45 UTC on September 9, 2026. The tunnels worked before the update, failed after it, and came back as soon as the update was uninstalled and the device rebooted, consistently and across several client devices. As of September 9, 2026 there is no Microsoft known-issue entry for it and no fix.
- The environment is Windows 11 24H2 and 25H2 clients with certificate-based authentication, RRAS plus NPS on Windows Server 2019, and VPN profiles deployed by Microsoft Intune.
- The reproduction is clean: uninstall KB5124008, reboot, and the tunnel connects again. Reinstall it and the failure returns.
- KB5124008 brings 25H2 to OS build 26200.9445 and 24H2 to 26100.9445, and its known issues list covers USB audio, Hyper-V host folder shares and Remote Desktop Services, not VPN.
- The workaround in the thread is to block KB5124008 on VPN endpoints in WSUS or Intune, which means deferring September's security fixes on exactly the machines that connect from outside.
- The other suggestions in the thread, EAP-TLS via Intune or SSTP with failover instead of IKEv2, are answers from the thread rather than Microsoft guidance.
Why the reproduction matters
Most VPN failures are configuration failures. This one is not shaped like a configuration failure. The tunnels worked immediately before the update, failed immediately after it, and resumed the moment the cumulative update was removed and the device restarted. The administrator was able to repeat that cycle, and it held across multiple client devices in the same environment.
That pattern points at the client networking stack or at how IPsec handles the machine and user certificates, rather than at a profile that was always wrong. What nobody has published is which component changed in KB5124008 and why. I am not going to guess at a mechanism that is not documented.
What Microsoft has said
Nothing about VPN. Microsoft Support published the KB5124008 article on September 8, 2026, with OS builds 26200.9445 and 26100.9445. Its known issues section lists USB audio devices failing to start, host folder shares becoming unavailable in Hyper-V based Linux virtual machines, and Remote Desktop Services not responding.
Always On VPN is not on that list as of September 9, 2026. So an administrator deciding what to do has a first-day user report on one side and an update with no acknowledged VPN defect on the other. That is worth stating plainly rather than dressing up.
The workaround, and what it costs
The workaround offered in the thread is to block KB5124008 in WSUS or Intune on the affected VPN endpoints until a corrected build exists. The cost is direct: those machines sit without September's security fixes, and they are the laptops that connect from hotel networks. Deferring a security update on your remote fleet is a decision to make with your eyes open and with a date attached to it.
Two other stopgaps appear in the thread: retargeting the Intune profile to EAP-TLS, and moving from IKEv2 to SSTP with failover. Neither is Microsoft guidance, both change how your users authenticate, and both need testing on a handful of devices before they go anywhere near the fleet.
What you can do today
1. Establish the correlation on one machine. Note the exact build with winver, uninstall KB5124008, reboot, and test the tunnel. If it connects, you have the same pattern the report describes.
2. Collect evidence while the failure is live, because it is what any support case will ask for: the rasphone.pbk profile, the RasClient entries in Event Viewer on the client, and the NPS logs on the server.
3. Decide the scope. If only certificate-based Always On VPN clients fail and everything else on the patched machines is healthy, hold KB5124008 on VPN endpoints in WSUS or Intune and leave the rest of the fleet patched.
4. Write down the deferral with an end date and a named owner. An update paused informally on a remote fleet is how a machine ends up six months behind.
5. Test any authentication change, EAP-TLS or SSTP, on two or three devices first. These are suggestions from a public thread, not vendor guidance, and reverting an authentication method on 200 laptops is a worse day than the one you are having.
Frequently asked questions
Is there a Microsoft known issue for the VPN failure?
Not as of September 9, 2026. The KB5124008 known issues list covers USB audio, Hyper-V host folder shares and Remote Desktop Services. The VPN reports exist only in the Microsoft Q&A thread opened that morning.
Does uninstalling KB5124008 really bring the tunnel back?
In the reported environment, yes. The tunnels resumed as soon as the cumulative update was removed and the device rebooted, and the cycle was reproducible across several clients. That recovery is not a fix, it is a rollback that leaves the machine without September's security fixes.