A Security Update That Locks Out Legitimate Users

Microsoft is investigating reports that a recent Windows 11 security update is breaking Active Directory domain trust on some enterprise machines, leaving employees unable to sign in even when they enter completely valid credentials. The issue affects KB5124008, a cumulative security update released on September 8, 2026, for Windows 11 versions 25H2 and 24H2, and appears connected to Machine Identity Isolation, a Credential Guard feature designed to protect machine-account secrets rather than cause outages.

The irony is notable: a patch meant to close security gaps is, in some environments, actively breaking the authentication infrastructure that keeps enterprise networks secure and accessible at the same time.

How the Failure Shows Up

The most detailed report so far comes from an administrator managing Windows 11 25H2 workstations joined to a domain running two Windows Server 2019 domain controllers. The administrator reproduced the failure across six separate systems in a consistent pattern: installing KB5124008 and restarting the machine broke its secure channel to the domain, uninstalling the update and rebuilding domain membership restored normal function, and reinstalling the update triggered the same failure again.

Affected users see the frustratingly generic message “The user name or password is incorrect” during interactive logon, despite supplying credentials that are, in fact, correct. Notably, cached sign-in continues to work while the machine is offline, and network authentication can still succeed in some cases, indicating the underlying user credentials themselves remain valid; the failure sits specifically in the machine’s trust relationship with the domain.

Administrators troubleshooting the issue found that PowerShell’s Test-ComputerSecureChannel command returns False on affected machines, while nltest /sc_query:<domain> produces the error ERROR_NO_TRUST_LSA_SECRET. Domain controllers log a corresponding Security Event 4625 for the computer account, showing an NTLM authentication failure with status codes pointing to a broken trust relationship rather than a credentials problem.

Ruling Out the Usual Suspects

Administrators investigating the issue have already ruled out the typical causes of domain-trust failures: DNS discovery problems, Active Directory replication issues, time synchronization drift, account lockouts, duplicate machine security identifiers, and general domain controller health have all been checked and cleared, narrowing suspicion toward the update itself and, more specifically, toward Machine Identity Isolation.

The Credential Guard Connection

Machine Identity Isolation works by moving a computer’s machine-account secret into Credential Guard’s virtualization-based security environment and deleting the standard copy that normally lives in the Local Security Authority. Microsoft’s own documentation notes that if Credential Guard fails to complete machine authentication after a restart, domain authentication can fail outright, and recovery may require physical or remote local-administrator access to the affected machine.

In the reported environment, the registry value controlling this feature, found under HKLM\SYSTEM\CurrentControlSet\Control\Lsa, was set to enforcement mode. Disabling Machine Identity Isolation through Group Policy and the Intune security baseline, then forcing the corresponding registry value back to its off state, stopped the repeated failures for affected administrators. Others reported success resetting the machine password and running Test-ComputerSecureChannel with its repair option after disabling isolation, though some machines still required full removal from the domain, a restart, and a complete domain rejoin to fully recover.

No Official Fix Yet

As of this writing, Microsoft’s published release notes for KB5124008 acknowledge unrelated problems with USB audio, Hyper-V Plan9 folder sharing, and Remote Desktop Services, but make no mention of domain-trust failures. A subsequent out-of-band update, KB5129195, released September 14, addresses those documented RDS, Hyper-V, and audio issues but likewise says nothing about Machine Identity Isolation or domain authentication.

That leaves affected organizations relying entirely on community-discovered workarounds rather than vendor-sanctioned guidance, an uncomfortable position for any enterprise IT team. Administrators should treat the fixes circulating in community forums as exactly that: workarounds, not permanent solutions. Disabling Machine Identity Isolation reduces the virtualization-based protection covering machine-account credentials, a real security trade-off made purely in the name of restoring uptime, while uninstalling KB5124008 entirely removes whatever security fixes the September update was meant to deliver in the first place.

What IT Teams Should Do Now

Given the uncertainty, organizations managing Windows 11 fleets should consider a cautious posture until Microsoft issues definitive guidance:

• Pause broad deployment of KB5124008 across the environment rather than pushing it fleet-wide.
• Test any Machine Identity Isolation policy changes on a small, controlled group of devices before wider rollout.
• Preserve local administrator or LAPS-managed access on machines before applying the update, since recovery from a broken trust relationship may require it.
• Verify domain trust health with nltest before returning any patched endpoint to production use.
• Monitor Microsoft’s official KB documentation for updates, and audit current Machine Identity Isolation settings across the fleet in the meantime.

The episode is a useful reminder that security hardening features, however well-intentioned, can introduce their own operational risk, and that patch validation in a representative test environment remains essential even for routine-looking cumulative updates.