Windows 11 Domain Trust Fix: Repair the KB5124008 Secure Channel Error

Windows 11 PCs joined to an on-premises Active Directory domain can lose their secure connection to the domain after the September 2026 security update KB5124008. The failure is especially confusing because valid domain passwords may be rejected while previously cached credentials can still work offline. Microsoft has confirmed the problem and provides a workaround involving Machine Identity Isolation, a Credential Guard-related security setting, followed by a secure-channel repair.

Why KB5124008 can break Windows 11 domain trust

The problem affects some Windows 11 version 24H2 and 25H2 devices after KB5124008 or later updates. Microsoft says the update causes Windows to start honoring existing or policy-provisioned Machine Identity Isolation enforcement settings. That feature is supported only when the Active Directory environment uses a Windows Server 2025 Domain Functional Level or higher; Microsoft says it should be disabled in other environments.

The important distinction is that KB5124008 does not simply break Active Directory itself. Microsoft says Active Directory replication and domain-controller services are not affected. Instead, some protected machine accounts can lose the secure channel that a domain-joined PC uses to authenticate its computer account. The result can look like an ordinary password problem even though the user's credentials are correct.

Check whether your PC has the Windows 11 domain trust problem

Start by checking whether the machine received the September 8, 2026 security update. KB5124008 moves Windows 11 version 25H2 to build 26200.9445 and version 24H2 to build 26100.9445. You can check the installed build from Settings under System and About, or inspect the installed updates in Windows Settings.

The strongest clue is the combination of a recent Windows update and a domain sign-in failure. Microsoft describes affected machines as losing their secure channel with an on-premises Active Directory domain. Users may see a message saying that the trust relationship between the device and the domain failed, while cached credentials can continue to allow an offline sign-in.

If you can still sign in with a cached domain account, do not immediately remove the computer from the domain. That cached session can give an administrator the access needed to investigate and apply Microsoft's workaround without first taking the more disruptive route of rebuilding the machine's domain membership.

Find out whether Machine Identity Isolation is enabled

Microsoft identifies Machine Identity Isolation as the setting behind this particular problem. If your organization manages Windows through Intune or Group Policy, check those policies first. Do not make a local registry change and assume it will remain in place, because a centrally managed policy can simply put the problematic value back.

For a device where the setting was configured directly in the registry, Microsoft identifies two locations to inspect. Open Registry Editor with administrator privileges and check these paths:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation

HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation

Microsoft's documented workaround applies when the relevant MachineIdentityIsolation value is set to 2. That value should be changed to 0 to disable the feature. If your organization manages the setting through Intune or Group Policy, make the change through that management system instead of relying on the local registry.

Disable Machine Identity Isolation before repairing the secure channel

If the registry is the method that originally configured the setting, change the applicable MachineIdentityIsolation value from 2 to 0. Check both registry locations identified by Microsoft because either one may be involved in the configuration. Do not change unrelated Credential Guard or security settings simply because they appear nearby in the registry.

After making the change, restart the Windows 11 PC. The restart matters because Windows needs to load the changed security configuration before you attempt to repair the domain relationship. If the setting is being delivered by Group Policy or Intune, confirm that the management configuration is disabled first; otherwise, the value may return after policy processing.

Repair the Windows 11 domain secure channel

Once the computer has restarted, open PowerShell with administrator privileges. Microsoft recommends repairing the secure channel with the following command:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

The Test-ComputerSecureChannel cmdlet checks the trust relationship between the local computer and its domain. The -Repair option tells Windows to repair that relationship, while -Credential allows you to supply credentials with permission to perform the operation. Enter an appropriate domain account when the credential prompt appears.

A successful repair should allow the workstation to communicate with the domain normally again. Test the result by signing out and attempting a normal domain sign-in, then check access to an ordinary domain resource such as a network share or another service that requires domain authentication. If the machine repeatedly loses trust after a reboot or later policy refresh, the underlying Machine Identity Isolation configuration has probably not been fully disabled.

What to do if the secure-channel repair does not hold

A successful repair is not necessarily proof that the configuration is fixed permanently. Reports from administrators on Microsoft's Q&A forum describe machines that repaired successfully but lost their secure channel again until Machine Identity Isolation was disabled. That makes policy inspection important on managed PCs, particularly when the registry value keeps returning after Group Policy or device-management synchronization.

If the device was previously configured with Machine Identity Isolation in enforcement mode, a more involved recovery can be necessary. Microsoft's documentation for the underlying policy notes that leaving an enforcement configuration can require the computer to be unjoined and rejoined to the domain. That is a substantially bigger operation than repairing the secure channel, so it should be treated as a controlled recovery step rather than the first thing to try.

Before an unjoin and rejoin, make sure you have a working local administrator account and the information required to join the computer back to the domain. For business-managed devices, test the procedure on an affected machine before applying it across a fleet. The goal is to restore domain authentication without accidentally creating a second configuration problem.

Installing KB5129195 does not remove this workaround

Microsoft released the out-of-band KB5129195 update on September 14 to address several problems introduced by the September security updates, including Remote Desktop Services instability and Hyper-V Plan9 folder-sharing failures. However, Microsoft's KB5129195 documentation also lists the domain-trust problem as a known issue and repeats the Machine Identity Isolation workaround.

That distinction matters when troubleshooting an affected workstation. Installing KB5129195 is still relevant because it contains other fixes and security improvements, but you should not assume that installing it alone repairs a machine that has already lost its domain secure channel. Microsoft says the domain-trust issue is being addressed in a future Windows update by temporarily preventing Machine Identity Isolation enforcement while the feature is improved.

Keep the security update while applying the targeted workaround

Rolling back KB5124008 may look like the quickest answer when a workstation suddenly cannot authenticate against the domain, but removing a security update also removes the protections it delivered. Microsoft released KB5124008 as the September security update, so an enterprise should avoid treating an uninstall as the default long-term fix.

The safer troubleshooting path is to identify whether the affected machine has the documented Machine Identity Isolation configuration, disable that setting through its controlling management mechanism, restart the device, and repair the secure channel. This isolates the workaround to the configuration Microsoft has identified rather than undoing the entire month's security update. Administrators should continue monitoring Microsoft's Windows release-health documentation for the permanent resolution and reassess the policy once Microsoft changes the status from mitigated to resolved.

What administrators should check across a Windows 11 fleet

If one workstation has developed this problem, it is worth checking whether other Windows 11 24H2 and 25H2 machines have the same configuration before the symptom appears. Inventory the Windows build, domain membership, Machine Identity Isolation configuration, and management source for the setting. This turns an individual login failure into a configuration check that can be performed consistently across the fleet.

Also separate the client problem from the health of the domain itself. Microsoft says the September issue does not affect Active Directory replication or domain-controller services. If multiple unrelated domain operations are failing, investigate the domain infrastructure independently rather than assuming every authentication problem comes from KB5124008.

For an affected Windows 11 workstation, the practical sequence is therefore straightforward: identify the September update, confirm the domain-trust symptoms, find the source of Machine Identity Isolation, disable it using the appropriate management method, restart, repair the secure channel, and verify that the repair survives another sign-in and policy refresh. That gives administrators a targeted recovery path while keeping the underlying Windows security update in place.