Domain trust failures after KB5124008: Machine Identity Isolation explained for Intune admins

Since the September 2026 Windows security update, some domain-joined Windows 11 devices greet users with "the trust relationship between this workstation and the primary domain failed" even though the password is right. The cause is a Credential Guard feature called Machine Identity Isolation that Windows now honours if it was ever configured. In this post I'll stick to what Microsoft has published about the issue, then add the part Microsoft leaves to you: finding which Intune or Group Policy setting enabled it, rolling it back cleanly, and confirming the device is healthy again.

Symptoms#

As documented by Microsoft:

• After installing KB5124008 or a later update, some Credential Guard protected machine accounts lose their secure channel with the on-premises Active Directory domain.
• Users can't sign in interactively with valid domain credentials and may see a message that the trust relationship between the device and the domain failed.
• Offline sign-in with previously cached credentials might still work. AD replication and AD services on the domain controllers aren't affected.

For an Intune admin this usually surfaces as hybrid joined devices that stop checking in, users who can only sign in while disconnected from the corporate network, and helpdesk tickets that look like a password problem.

Why it happens#

Microsoft explains that KB5124008 and later updates enable the Machine Identity Isolation feature. The update doesn't directly turn enforcement on; it makes Windows begin honouring any existing or policy-provisioned settings that had already enabled Machine Identity Isolation enforcement. The feature is only supported when the device talks to domain controllers running at a Windows Server 2025 domain functional level (DFL) or higher, and Microsoft says it should be disabled everywhere else. Devices configured for it that aren't connected to Windows Server 2025 domain controllers hit this issue and need the feature disabled.

Two pieces of Microsoft documentation help you understand the setting itself. The Windows Server page on Credential Guard protected machine accounts describes Machine Identity Isolation as moving the machine account secret into Credential Guard, with three states: Disabled, Enabled in audit mode, and Enabled in enforcement mode. It also notes the feature had been temporarily disabled since the April 2025 security update (KB5055523) because of a machine password rotation problem, which explains how a setting could sit in your environment for a long time without visible effect. The DeviceGuard Policy CSP documents the matching MDM setting: ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/MachineIdentityIsolation with values 0 (Disabled), 1 (audit) and 2 (enforcement), mapped to the Group Policy Turn On Virtualization Based Security › Machine Identity Isolation Configuration under Computer Configuration › Administrative Templates › System › Device Guard, stored under SOFTWARE\Policies\Microsoft\Windows\DeviceGuard.

Enforcement is value 2, and that's the state Microsoft's workaround looks for.

How to fix it#

1. Confirm it on an affected device#

Sign in with cached credentials or a local administrator account, open an elevated PowerShell session and check both registry locations Microsoft names, plus the secure channel:

$paths = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa',
         'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard'
foreach ($p in $paths) {
    $v = (Get-ItemProperty -Path $p -Name MachineIdentityIsolation -ErrorAction SilentlyContinue).MachineIdentityIsolation
    '{0} : {1}' -f $p, $(if ($null -eq $v) { 'not set' } else { $v })
}
Test-ComputerSecureChannel

A value of 2 in either location together with False from Test-ComputerSecureChannel is the documented issue. The same lines work as a Remediations detection script (detection only; exit 1 when a value of 2 is found) if you want a tenant-wide count before anyone else calls the helpdesk.

2. Find out what set it#

Microsoft's workaround is to disable Machine Identity Isolation using the same management method that enabled it, so you need to know the source. For Intune, search the Settings catalog for "Machine Identity Isolation" (Device Guard category) in your configuration profiles, and check custom OMA-URI profiles for the CSP path above. Graph PowerShell can scan both:

Connect-MgGraph -Scopes 'DeviceManagementConfiguration.Read.All'
$base = 'https://graph.microsoft.com/beta/deviceManagement'
$catalog = (Invoke-MgGraphRequest -Method GET -Uri "$base/configurationPolicies").value
foreach ($p in $catalog) {
    $settings = (Invoke-MgGraphRequest -Method GET -Uri "$base/configurationPolicies/$($p.id)/settings").value
    if (($settings | ConvertTo-Json -Depth 20) -match 'machineidentityisolation') { "Settings catalog: $($p.name)" }
}
$custom = (Invoke-MgGraphRequest -Method GET -Uri "$base/deviceConfigurations").value |
    Where-Object { $_.omaSettings.omaUri -match 'MachineIdentityIsolation' }
$custom | ForEach-Object { "Custom OMA-URI: $($_.displayName)" }

Both calls return the first page only; follow @odata.nextLink if you have more than a hundred policies. For hybrid joined devices also check Group Policy: run gpresult /h report.html on the device and look for Turn On Virtualization Based Security with a Machine Identity Isolation Configuration value. Baselines and hardening templates imported as JSON are a common hiding place.

3. Disable it the same way it was enabled#

• Intune: edit the policy and set Machine Identity Isolation to Disabled (value 0) rather than simply unassigning the profile, so the device receives an explicit change. Keep the assignment until every device has taken it.
• Group Policy: set the Machine Identity Isolation Configuration element to Disabled in the same GPO.
• Registry only: Microsoft's steps are to set MachineIdentityIsolation from 2 to 0 in both locations listed above. Back up the registry first, as Microsoft reminds you.

4. Restart and repair the secure channel#

After disabling the feature, restart the device, then reset the secure channel from an elevated session with a domain account that can reset the computer account:

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

If the repair fails, Microsoft's Credential Guard protected machine accounts documentation notes that a device previously in enforcement mode may need to be unjoined and rejoined to the domain, using a local administrator account.

Verify the fix#

• Test-ComputerSecureChannel returns True and both registry values read 0 or are absent.
• A domain user signs in while connected to the corporate network, and dsregcmd /status still shows the device as hybrid joined.
• The device checks in to Intune again and the edited profile shows Succeeded for that device.
• Your Remediations detection returns no devices with value 2.

Prevent it next time#

• Check prerequisites before enabling security features. Machine Identity Isolation requires domain controllers at Windows Server 2025 DFL; confirm with Get-ADDomain (the DomainMode property) before anyone touches the setting.
• When a setting offers an audit mode, start there and pilot on a small ring before enforcement.
• Read every setting in imported baselines and hardening JSON; don't deploy what you can't explain.
• Hold a pilot ring on the new cumulative update for a few days and follow Windows release health, so a documented known issue reaches you before the broad rollout does.

References#

• Windows 11, version 24H2 known issues and notifications (Domain-joined devices might lose their secure trust relationship with the domain)
• Credential Guard protected machine accounts
• Policy CSP - DeviceGuard