Microsoft’s September Patch Triggers Domain Trust Failures on Windows 11

Enterprise IT teams woke up this week to a familiar headache. Domain-joined Windows 11 machines stopped accepting valid credentials after the latest security updates landed. The trust relationship between workstations and Active Directory broke. Users saw messages claiming their passwords were wrong. Cached logons worked offline. But once the systems needed to talk to domain controllers, authentication collapsed.

This isn’t some obscure edge case. Administrators reported clusters of affected devices. One saw 11 out of 256 Windows 11 25H2 Enterprise machines fail. Another reproduced the problem on six systems in an environment running Windows Server 2019 domain controllers. The pattern repeated with Server 2022 in other reports. Symptoms included Kerberos ticket failures followed by NTLM and Netlogon fallbacks. Domain controllers logged Security Event 4625 for computer accounts. PowerShell’s Test-ComputerSecureChannel returned False. The nltest command surfaced ERROR_NO_TRUST_LSA_SECRET, error code 1786.

The Root Cause: Machine Identity Isolation

Microsoft has now confirmed the trigger. The September 2026 security updates, primarily KB5124008 for Windows 11 24H2 and 25H2 and the equivalent for 26H1, activate behavior tied to a security feature called Machine Identity Isolation. This mechanism, linked to Credential Guard and virtualization-based security, moves machine account keys into a protected enclave. It then discards the copy stored in the Local Security Authority. The intent is stronger isolation against credential theft. But the feature only functions correctly with domain controllers at Windows Server 2025 Domain Functional Level or higher.

In environments below that threshold, which describes the vast majority of current on-premises Active Directory setups, the change causes the secure channel to fail. The update doesn’t explicitly enable the feature in every case. It honors existing configurations set through Group Policy, Intune, or direct registry edits. If MachineIdentityIsolation sits at value 2 (enforcement mode) in HKLMSYSTEMCurrentControlSetControlLsaMachineIdentityIsolation or the DeviceGuard policy path, the breakage occurs. Administrators who had the setting in audit mode or had previously experimented with it discovered the update flipped effective behavior.

The Register first highlighted the widespread reports on September 17 (The Register). BleepingComputer followed with detailed coverage of Microsoft’s initial response and the official workaround (BleepingComputer). Heise Online translated the implications for European admins and confirmed the same registry keys and command sequence (heise online).

So what exactly happens under the hood? When a domain-joined Windows client boots, it uses its machine account password to establish a secure channel with a domain controller. This channel underpins Kerberos ticket requests for user logons. If the client and domain controller disagree on the machine password, or if the client no longer possesses the necessary secret, the channel breaks. Machine Identity Isolation was designed to protect that secret by isolating it inside a virtualized container. The September patches made Windows strictly observe any policy that demands this isolation. Older domain controllers simply can’t handle the resulting authentication flow. The LSA secret disappears. Interactive domain logons fail even though the supplied user credentials remain correct.

Microsoft’s documentation now carries a clear warning. The feature “is only supported for environments connected to domain controllers running at a Windows Server 2025 Domain Functional Level (DFL) and above. The feature should be disabled elsewhere.” Admins must locate every device where the setting was previously enabled and turn it off. But there’s a catch. Simply flipping the registry value from 2 back to 0 and rebooting isn’t enough. The secure channel must be explicitly repaired afterward.

The workaround steps are precise. First, set MachineIdentityIsolation to 0 in the relevant registry locations. Restart the device. Then run Test-ComputerSecureChannel -Repair -Credential (Get-Credential) in an elevated PowerShell session. Provide domain administrator credentials when prompted. This resets the machine password in Active Directory and restores the channel. Microsoft stresses that disabling the feature after it has been enforced can itself break authentication in some scenarios, potentially requiring the device to be disjoined and rejoined to the domain. Careful sequencing matters.

Enterprise environments that rely heavily on Credential Guard for privileged workstations face difficult choices. Many adopted the feature precisely because it reduces the attack surface against pass-the-hash and credential dumping. Now those same protections collide with legacy domain infrastructure. Upgrading every domain controller to Windows Server 2025 isn’t realistic on short notice. Server 2025 itself remains relatively new, and many organizations run mixed environments with 2019 and 2022 systems still in production.

The timing adds sting. September Patch Tuesday delivered fixes for roughly 966 vulnerabilities, one of Microsoft’s largest monthly releases in recent memory. Uninstalling KB5124008 restores trust in tested cases but leaves systems exposed to those patched flaws. Emergency out-of-band updates such as KB5129195 addressed unrelated problems with Remote Desktop, Hyper-V Linux virtual machines, and USB audio. They did not touch this domain trust issue. As of September 17, the workaround stands as the primary mitigation while Microsoft prepares a more permanent solution.

Administrators who monitored Microsoft Q&A forums and Reddit threads in the days before official acknowledgment pieced together the connection. One sysadmin detailed reproducing the failure on six identical Windows 11 25H2 machines. Install the update, reboot, and the secure channel vanishes. Uninstall the update, rejoin the domain, and everything returns to normal. Reapply the update and the problem reappears. Event logs showed the machine account attempting NTLM logon type 3 and failing with 0xC000006A. The pattern matched across unrelated organizations.

Larger fleets present bigger headaches. Scripting the registry change and secure channel repair across thousands of endpoints requires testing. Group Policy objects that previously set the isolation feature must be updated first. Intune configurations need review. And every change carries risk of unintended authentication regressions. Microsoft advises against enabling Machine Identity Isolation in enforcement mode on unsupported domain functional levels going forward.

This episode highlights a recurring tension in Windows security updates. Features intended to raise the bar against sophisticated attackers can disrupt stable, long-running enterprise architectures. Credential Guard has protected high-value endpoints for years. Its deeper integration through Machine Identity Isolation represents the next logical step in that progression. Yet the dependency on modern domain controller levels creates a adoption cliff. Organizations that delayed Server 2025 upgrades now pay the price in operational disruption.

Microsoft has marked the issue as “mitigated” in its Windows release health dashboard because the workaround exists. Full resolution will likely arrive in a future cumulative update that adjusts how the isolation setting interacts with older domain controllers or provides a compatibility mode. Until then, affected IT departments must act manually. Check existing policies. Disable where necessary. Repair channels. And monitor for the next patch that promises to clean up the mess.

The incident serves as a reminder. Security improvements rarely arrive without trade-offs. In this case, the trade-off arrived without sufficient warning for the many enterprises still operating pre-2025 Active Directory environments. Preparation, testing in representative lab domains, and staged rollouts remain the best defense against surprises like this one.