KB5124008, the Windows 11 security update Microsoft shipped on September 8, 2026, is breaking certificate-based Always On VPN tunnels on some enterprise clients. The pattern being reported is consistent and specific: the tunnel works right up until the update installs, fails immediately after, and comes back the moment the update is removed and the device rebooted. Reinstall it, and the failure returns. That cycle points at a client-side regression in how the update handles IPsec certificate negotiation, not a bad Intune profile or a misconfigured NPS server.
The affected environments share a specific shape: Windows 11 24H2 (build 26100.9445) or 25H2 (build 26200.9445) clients, an Always On VPN profile pushed through Intune, machine-certificate authentication over IKEv2, and a backend running RRAS and NPS on Windows Server 2019. Microsoft’s own support article for KB5124008 doesn’t list this as a known issue as of this writing, and there’s no fix or Known Issue Rollback yet.
What’s actually happening?
Always On VPN’s IKEv2 machine-tunnel setup depends on a chain of checks succeeding: the client’s machine certificate has to be valid, chain up to a trusted root, and match the expected certificate usage, before IKE authentication completes and the tunnel comes up. Something in KB5124008 is interrupting that chain, and it’s happening consistently enough — reproduced on multiple machines by more than one organization — that it isn’t a one-off certificate expiry coincidence.
Complicating things: this isn’t a cosmetic patch you can safely sit out. KB5124008 also closes two elevation-of-privilege vulnerabilities reported as actively exploited. Pulling the update to restore VPN access trades a confirmed exploit path for a confirmed outage, and neither side of that trade is free.
Confirm you’re actually looking at this issue
Before treating every VPN complaint as this bug, check whether the affected devices actually have KB5124008 installed and match the failure signature — connects fine pre-patch, fails post-patch, recovers on uninstall and reboot. If that pattern doesn’t hold, you’re probably looking at an expired certificate or an NPS policy change instead, and chasing this specific regression will waste time.
Where to actually look:
- Event Viewer > Applications and Services Logs > Microsoft > Windows > RasClient for the client-side connection failure and any IKE error code attached to it. Error codes in the 13801–13806 range point at IKE authentication or machine certificate problems specifically.
- rasphone.pbk, at
C:\ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk, to rule out the update having mangled the connection profile itself rather than the certificate handshake. - NPS server logs and RADIUS accounting logs on the Windows Server 2019 backend, to confirm the request is failing at the client’s certificate presentation rather than being rejected by an NPS policy change on the server side.
Pull all three before opening a case. A regression this specific gets resolved faster with logs attached than with a description of symptoms.
What to do while there’s no fix
If you haven’t rolled KB5124008 out broadly yet, hold it at the ring or WSUS/Intune deployment level for devices that depend on certificate-based Always On VPN, and treat that decision as a security tradeoff to document, not a routine pause — two actively exploited vulnerabilities are sitting in the update you’re withholding.
If the update is already out and pulling it isn’t realistic across the whole fleet, one reported stopgap is switching the affected VPN profiles to EAP-TLS authentication via Intune instead of the certificate-based configuration that’s failing. It reportedly gets tunnels reconnecting on patched devices, but nobody’s calling it a stable long-term fix — pilot it on a small ring before pushing it anywhere near production scale, and expect to revert once Microsoft actually fixes the regression.
Uninstalling KB5124008 and rebooting is the only recovery method confirmed to work consistently right now. If you go that route on remote-access-critical devices, compensate for the exposed vulnerabilities some other way — network-level mitigations, tighter monitoring, whatever your security team can stand up faster than Microsoft can ship a fix.
Whichever way you land, write the decision down somewhere more durable than a Slack thread. “We held KB5124008 on the VPN gateway ring because of a confirmed Always On VPN regression, tracked against [ticket]” is the kind of note that saves an uncomfortable conversation later, whether that’s an auditor asking why a patched vulnerability sat open for two weeks, or a different admin six months from now wondering why your update rings still exclude a build that’s long since been fixed.
Where this stands
As of this writing, Microsoft hasn’t acknowledged the issue in KB5124008’s own documentation, and there’s no hotfix or Known Issue Rollback. Given how specific and reproducible the failure signature is, a known-issue entry and a fix both seem likely to follow — this has the shape of a regression Microsoft moves on quickly once enough enterprise telemetry lands, not an obscure edge case. Until then, the choice for remote-access-dependent organizations is between an unpatched zero-day exposure and a broken VPN, and there’s no version of that choice that doesn’t need a decision made deliberately rather than by default.
Read more: Microsoft 365 Web Access Is Moving to copilot.cloud.microsoft — Check Your Allow List Now
Frequently Asked Questions
Which Windows 11 versions are affected by the KB5124008 VPN issue?
Windows 11 24H2 (build 26100.9445) and 25H2 (build 26200.9445), specifically clients using certificate-based Always On VPN against an RRAS/NPS backend.
Does uninstalling KB5124008 actually fix it?
Yes, uninstalling and rebooting has consistently restored connectivity in reported cases. It also removes the fixes for two actively exploited vulnerabilities the update patches, so weigh that before doing it fleet-wide.
What error codes should I look for?
IKE authentication and machine certificate errors in the 13801–13806 range, visible in the RasClient event log on the client.
Is there a workaround that doesn’t involve removing the update?
Some administrators report that switching affected profiles to EAP-TLS authentication via Intune restores connectivity while keeping the update installed. Treat it as a pilot-first stopgap, not a confirmed fix.
Does this affect home users?
No. This is specific to enterprise Always On VPN deployments with certificate-based authentication; home users without that configuration aren’t affected.
References
Microsoft Q&A — Always On VPN Fails After Installing KB5124008 on Windows 11 https://learn.microsoft.com/en-us/answers/questions/5998351/always-on-vpn-fails-after-installing-kb5124008-on
Cyber Security News — Windows 11 Security Update KB5124008 Breaks Always-On VPN Connections https://cybersecuritynews.com/windows-11-security-update-kb5124008/
Cyber Updates 365 — Windows 11 KB5124008 VPN Bug: Always On VPN Fails After Update https://cyberupdates365.com/windows-11-kb5124008-vpn-bug-always-on-fix/
