KB5124008 Breaks Domain Trust via Machine Identity Isolation: Why and How to Fix It

KB5124008 and KB5124012, released as part of the September 2026 Windows update cycle, are breaking domain trust relationships on Windows 11 devices whose environments had Machine Identity Isolation configured but whose domain controllers aren’t yet running at Windows Server 2025 Domain Functional Level. Affected machines reject correct domain credentials with errors that look exactly like a wrong username or password, when the real cause is an update changing how an already-configured security feature gets enforced. Microsoft has confirmed the issue and published a workaround.

What Machine Identity Isolation actually is

Machine Identity Isolation is a Credential Guard-related security feature that relocates a device’s machine account credentials away from the registry and into Credential Guard’s isolated, trusted execution environment, making it significantly harder for an attacker who compromises a device to extract and misuse its machine identity. This is a genuinely good security improvement in principle, it’s specifically the enforcement timing and domain compatibility requirements that are causing real breakage right now.

Why this is breaking now, specifically

Machine Identity Isolation is only supported when domain controllers are operating at Windows Server 2025 Domain Functional Level (DFL) or higher. Below that DFL, it isn’t compatible with the domain’s authentication infrastructure. KB5124008 didn’t newly enable this feature, the important distinction Microsoft has clarified, it changed how Windows behaves when the feature was already configured in an environment. Where an organization had Machine Identity Isolation settings in place but domain controllers weren’t yet at the required DFL, that mismatch, previously not enforced strictly, now breaks the domain trust relationship outright, and affected machines start rejecting correct domain credentials.

How to check if you’re affected

# Check your domain controllers' current functional level
Get-ADDomain | Select-Object DomainMode

# Check if Machine Identity Isolation is configured on a client
# via registry (look for MachineIdentityIsolation value)
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

If your domain controllers are below Windows Server 2025 DFL and either of those registry values is set to 2 (enforcement), you’re in the affected configuration, whether or not you’ve installed KB5124008/KB5124012 yet on any given client.

Microsoft’s official workaround

Disable Machine Identity Isolation until your domain controllers are actually at the required functional level:

# Registry workaround: change the value from 2 to 0 in both locations
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "MachineIdentityIsolation" -Value 0
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" -Name "MachineIdentityIsolation" -Value 0

Organizations managing this via Group Policy should set the Machine Identity Isolation policy setting to Disabled in the relevant GPO instead of editing the registry directly on individual machines, and organizations using Intune should disable the equivalent Intune policy rather than fighting policy reapplication on managed devices. Microsoft has stated it plans to address the underlying domain trust problem in a future update by temporarily preventing enforcement while a proper fix is developed, but don’t wait on that timeline if you’re actively experiencing lockouts now, apply the workaround immediately.

The real lesson: audit configured-but-not-yet-enforced security settings before update cycles

This specific bug is a useful reminder that a security setting configured in your environment but not actively enforced yet is still a latent risk when an update changes enforcement behavior. Before any major Windows update cycle, it’s worth auditing which security features are configured in your GPOs and Intune policies but depend on infrastructure prerequisites (functional levels, specific server versions, licensing tiers) that your actual environment hasn’t fully met yet, since exactly this kind of mismatch is what turns a routine update into an unplanned outage.

Frequently asked questions

If we’ve never intentionally configured Machine Identity Isolation, can this still affect us?
It’s possible if the setting was configured indirectly, inherited from a security baseline template, a third-party hardening tool, or a policy applied by someone no longer at the organization, without anyone actively tracking it as “configured.” Check the actual registry values and GPO/Intune policy state directly rather than relying on memory of what was intentionally set.

Is raising our domain controllers to Windows Server 2025 DFL a better long-term fix than disabling the feature?
If your organization is planning that DFL upgrade anyway, yes, that’s the actual resolution rather than a workaround, since it removes the underlying incompatibility rather than just disabling a security feature. If the DFL upgrade isn’t imminent, disabling Machine Identity Isolation via the documented workaround is the appropriate interim step rather than leaving affected machines locked out while you plan a larger domain infrastructure upgrade.

Does this affect Windows Server itself, or only Windows 11 clients?
The confirmed, widely reported symptom is on Windows 11 client devices (24H2, 25H2, and 26H1 via the respective KBs), specifically around domain trust relationships for client machines. Server-side domain controller functional level is the relevant prerequisite, but the breakage itself has been reported on client machines losing their domain trust relationship, not on the domain controllers.