Windows 11 Trust Relationship Failed After KB5124008? Machine Identity Isolation Is Why

A user signs in on Monday morning and gets this:

That error has been around for decades and usually means one thing: the machine account password is out of sync with Active Directory. Since 8 September 2026 it means something else on a growing number of devices, and the old fix makes things worse rather than better.

If the device installed KB5124008 or later, the likely cause is a Credential Guard feature called Machine Identity Isolation enforcing in an environment that cannot support it.

The diagrams in this guide illustrate the diagnostic logic and the fix sequence. Screenshots from a live affected system will be added once a reproduction environment is available.

What you will actually see

Microsoft’s description is specific, and the details matter for triage:

• Users cannot sign in interactively with valid domain credentials
• The trust relationship error appears at sign-in
• Offline sign-in using cached credentials may still work
• Active Directory replication is unaffected
• AD services on the domain controllers are unaffected

That third point is the one that misleads people. Some users carry on working all day on cached credentials and only hit the wall after a password change or a cache expiry, so the failures arrive staggered rather than all at once. It rarely looks like an update-related outage at first.

Why it happens, precisely

This is the part most coverage gets slightly wrong, and the distinction changes how you investigate.

Microsoft’s wording is careful, and it turns on one word. KB5124008 and later updates enable the Machine Identity Isolation feature. They do not directly enable enforcement. What they do is cause Windows to begin honoring any existing or policy-provisioned settings that already enabled enforcement.

So the setting was almost certainly already on your devices, sitting inert. The September update is what started acting on it.

That reframes the question you should be asking. Not “what did the update change?” but “who enabled Machine Identity Isolation here, and when?” — because the answer determines how you switch it off.

Machine Identity Isolation is a Credential Guard feature that protects the computer account secret by moving it out of the traditional LSA path into a virtualisation-isolated environment. That protection is only supported when the device talks to domain controllers running at Windows Server 2025 Domain Functional Level or above. Below that level the domain’s authentication infrastructure cannot support it, and the machine’s secure channel can fail.

Which gives you a clean three-part test:

All three yes, and you have found the failure pattern Microsoft describes. Any one no, and you may be looking at the classic machine account password problem instead — which has a different fix.

Step 1: Check your domain functional level

Do this first, because it decides everything that follows. From any machine with the AD PowerShell module, or from a domain controller:

Get-ADDomain | Format-List DomainMode, DNSRoot
Get-ADForest | Format-List ForestMode

If DomainMode returns anything below Windows2025Domain, Machine Identity Isolation is not supported in your environment and should be switched off on every affected client.

Step 2: Confirm Machine Identity Isolation on the device

On an affected machine, check both registry locations. Either one can hold the setting depending on how it was applied:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
  -Name MachineIdentityIsolation -ErrorAction SilentlyContinue

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' `
  -Name MachineIdentityIsolation -ErrorAction SilentlyContinue

A value of 2 means enforcement is on. In an environment below Windows Server 2025 Domain Functional Level, that is the setting you need to remove or disable.

Step 3: Disable it using the method that enabled it

This matters. If you clear the registry value while a Group Policy or Intune policy still sets it, the policy reapplies and the machine breaks again at the next refresh. Match the fix to the source.

If you genuinely do not know how it was set — which is common, because it may predate whoever is on call — check Group Policy first with gpresult /h report.html on an affected machine, then Intune, then assume registry.

Step 4: Restart first, then repair the secure channel

The order is not optional. After disabling Machine Identity Isolation, restart the device so the change takes effect. Then repair the secure channel:

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

Supply an account with permission to reset the computer account. Run Test-ComputerSecureChannel on its own afterwards to confirm it returns True.

Repairing before the restart does not stick. Enforcement is still active, so the channel can break again immediately.

What not to do

Do not rejoin the domain as your first fix. It is the reflex for this error message and it is the wrong move here. Removing and rejoining can destroy the existing computer object or create a duplicate, can lose Group Policy scoping and BitLocker recovery key escrow, and takes far longer. If Machine Identity Isolation is still enforcing, the rejoined machine can break again anyway.

The secure channel is not the underlying problem. It is the symptom of a feature enforcing where it cannot work.

Do not uninstall KB5124008 as the long-term fix. It is a security update, and removing it leaves the underlying configuration in place for the next cumulative update to enforce again. Disable Machine Identity Isolation instead, then repair the secure channel.

Do not raise the domain functional level under outage pressure. If you want Credential Guard machine account protection later, plan the Windows Server 2025 DFL move properly after service is restored.

Finding affected machines before they call you

Because cached credentials mask the failure, waiting for tickets means discovering the scope slowly over several days. If your fleet includes Windows 11 Enterprise on 24H2 or later against a pre-2025 DFL domain, it is worth checking proactively.

This proactive check is most useful before users start calling. Machines already in a failed sign-in state may not respond to remote PowerShell, so treat the output as an at-risk list, not a complete inventory.

$computers = Get-ADComputer -Filter 'OperatingSystem -like "Windows 11*"' |
  Select-Object -ExpandProperty Name

Invoke-Command -ComputerName $computers -ErrorAction SilentlyContinue -ScriptBlock {
    $lsa = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
      -Name MachineIdentityIsolation -ErrorAction SilentlyContinue
    $dg  = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' `
      -Name MachineIdentityIsolation -ErrorAction SilentlyContinue

    [PSCustomObject]@{
        Computer = $env:COMPUTERNAME
        Lsa      = $lsa.MachineIdentityIsolation
        Policy   = $dg.MachineIdentityIsolation
    }
} | Where-Object { $_.Lsa -eq 2 -or $_.Policy -eq 2 } |
    Format-Table Computer, Lsa, Policy

Combine it with whatever your management platform reports on Credential Guard configuration. If you are working through AD housekeeping alongside this, our guides to running Active Directory Users and Computers and finding stale and disabled accounts cover the tooling.

Telling this apart from the classic cause

The same error message has a much older and more common cause: the machine account password falling out of sync, typically after a device is restored from a snapshot, left offline past the 30-day machine password rotation, or cloned without Sysprep.

If Test-ComputerSecureChannel -Repair works and then fails again within a day or two, that is a strong sign the feature is still enforcing and Step 3 did not actually take — most often because a policy reapplied it.

What Microsoft plans to do

Microsoft has stated it plans to resolve this in a future Windows update by temporarily preventing Machine Identity Isolation enforcement while improvements are made to the feature.

That means two things. First, machines you fix now should stay fixed if the source policy no longer enables the feature. Second, when enforcement eventually returns, the domain functional level requirement will still matter. If Credential Guard machine account protection is something you want, raising the domain functional level to Windows Server 2025 is the real prerequisite — planned properly, not during an incident.

The current status and any change will appear on the Windows 11 release health page and, where applicable, in tenant-specific Microsoft 365 Message Center notices.

Final thoughts

The awkward part of this one is that nothing was misconfigured last month. The setting was already there, inert, and an update turned it from dormant to enforced. That is worth remembering the next time a cumulative update appears to break something that was working — the update may have changed enforcement rather than configuration.

If you administer Windows 11 Enterprise clients against a domain below Windows Server 2025 functional level, check the registry value now rather than waiting for the sign-in failures. It takes a single query and it tells you whether you have a problem coming.