Blog · 6 min read ·
ShareKB5124008 + Machine Identity Isolation: lost domain trust
Microsoft opened this Windows 11 known issue September 16, 2026 at 14:15 PT and lists it Mitigated, not Resolved, as of the same timestamp. KB5124008 (September 8, 2026) and later updates cause Windows to honor previously configured Machine Identity Isolation settings, which are supported only where domain controllers run at Windows Server 2025 Domain Functional Level and above. Microsoft has not set a fix date.
If you manage a domain-joined Windows 11 fleet against an on-premises Active Directory domain, Microsoft has confirmed a known issue worth reading if you have not yet deployed the September 8, 2026 update fleet-wide. After installing the September 8, 2026 update (KB5124008) or later, some Credential Guard protected machine accounts might lose their secure channel with the domain — users might be unable to sign in with valid domain credentials and might see a message that the trust relationship between the device and the domain failed.
Microsoft opened the known issue September 16, 2026 at 14:15 PT and lists its status as Mitigated — not Resolved — as of the same timestamp. The underlying feature, Machine Identity Isolation, was temporarily disabled starting with the April 2025 update (KB5055523) — a change Microsoft documented publicly on its Learn page for Credential Guard protected machine accounts — and KB5124008 is what makes Windows begin honoring previously configured settings for it.
What Microsoft's known issue says
Microsoft's release-health entry, identical on both the Windows 11 25H2 and 24H2 status pages, states: "After installing the September 8, 2026, Windows security update (KB5124008), or later updates, some Credential Guard protected machine accounts might lose their secure channel with an on-premises Active Directory (AD) domain. Users might then be unable to sign in interactively with valid domain credentials and might receive a message stating that the trust relationship between the device and the domain failed. Offline sign-in using previously cached credentials might continue to work. AD replication and AD services on the domain controllers are not affected."
Affected platforms, per Microsoft:
- Client: Windows 11, version 26H1; Windows 11, version 25H2; Windows 11, version 24H2
- Server: None
We also checked Microsoft's release-health pages for Windows Server 2025, Windows Server 2022, the Windows 10 1809/Server 2019 page, the Windows 10 1607/Server 2016 page, and Windows 10 22H2 — this issue is not listed on any of them.
Microsoft's general troubleshooting article for a broken domain trust relationship gives the on-screen text, verbatim: "The trust relationship between this workstation and the primary domain failed." The Machine Identity Isolation known-issue note itself uses softer language — "a message stating that the trust relationship between the device and the domain failed" — and we can't confirm every occurrence of this specific issue displays the classic wording verbatim.
Why a setting from months ago is only failing now
Microsoft's documentation for Credential Guard protected machine accounts states the feature was "temporarily disabled" starting with the April Windows security update (KB5055523) in Windows Server 2025 and Windows 11, version 24H2, because of "an issue with machine password rotation using Kerberos," and "remains disabled until a permanent fix is available." The KB5124008 release-health entry explains what changed in September: "This issue occurs because KB5124008 and later updates enable the Machine Identity Isolation feature. While the update does not directly enable Machine Identity Isolation enforcement, it does cause Windows to begin honoring any existing or policy-provisioned settings that enabled Machine Identity Isolation enforcement." In plain terms: an enforcement setting your organization configured earlier can start to take effect once the September 8, 2026 update is installed.
Who's actually exposed
Microsoft is specific about scope: "this 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."
For most mid-market shops on-premises, that's a real constraint: Microsoft never shipped a Server 2019 or Server 2022 functional level — msDS-Behavior-Version jumps from 7 (Server 2016) straight to 10 (Server 2025) — so a forest of Server 2019/2022 domain controllers correctly tops out at Server 2016 DFL. If Machine Identity Isolation is enabled there, KB5124008 turns a dormant setting into a locked-out user.
The symptom can look intermittent. Microsoft's known-issue note says offline sign-in using previously cached credentials might continue to work — in practice, that could mean a laptop signs in fine off-network and then fails once it re-establishes its secure channel, though that specific sequence is our inference from Microsoft's wording, not something Microsoft states directly. AD replication and DC services aren't affected, per Microsoft. The generic advice — rejoin the domain — treats the symptom; the setting that caused it is still on.
How to check if you're exposed
Confirm whether Machine Identity Isolation is configured, on whichever surface your organization manages it:
- Intune — the DeviceGuard/MachineIdentityIsolation setting in the Policy CSP.
- Group Policy — Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security, under the Machine Identity Isolation Configuration option.
- Registry, on the Windows 11, version 24H2 or 25H2 device itself — check both:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolationHKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation
0"(Disabled)",1"(Enabled in audit mode)" and2"(Enabled in enforcement mode)" — and a value of2is exactly what the release-health workaround tells you to look for.
The fix — and two Microsoft pages that don't fully agree
Microsoft's release-health workaround is procedural: disable Machine Identity Isolation "using the same
management method that was used to enable it" — Intune, Group Policy, or the registry keys above (set
MachineIdentityIsolation = 0) — restart the device, then reset the secure channel:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential) Microsoft's separate documentation on the underlying Group Policy setting describes the same "Disabled" option differently depending on prior state. If previously "Enabled in audit mode," it says "no further action is needed." If previously "Enabled in enforcement mode," it instead says "the device must be unjoined and rejoined to the domain, as it's unable to authenticate otherwise," and that "only the local administrator account can be used to unjoin and rejoin the machine." That page also notes that if cached logon is enabled, "local logon will still work while the cache is fresh, but domain authentication will break" — the same intermittent pattern described above.
The two pages don't reconcile, and we won't invent one. Try the release-health procedure first —
disable, restart, Test-ComputerSecureChannel -Repair — it's written specifically for this
issue. Keep a local admin credential on hand: if enforcement mode won't repair, the fallback is an
unjoin and rejoin, which only a local admin account can perform.
What Microsoft says is next
Microsoft's stated next step: "We plan to resolve this issue in a future Windows update by temporarily preventing Machine Identity Isolation enforcement while improvements are made to the feature." No fix date is published as of September 16, 2026.
Related reading
- Domain Functional Level on Server 2019 and 2022 — why most on-premises forests sit at Server 2016 DFL.
- RDS can stop responding after the September 2026 update — a separate known issue, same KB5124008 update cycle.
- Active Directory Audit service page.
Sources
- Microsoft — Windows 11, version 25H2 release health
- Microsoft — Windows 11, version 24H2 release health
- Microsoft Learn — Credential Guard protected machine accounts in Windows Server 2025
- Microsoft Support — KB5124008
- Microsoft Learn — Policy CSP: DeviceGuard/MachineIdentityIsolation
- Microsoft Support — How to back up and restore the registry in Windows
- Microsoft Learn — Broken trust relationship between a domain-joined device and its domain
The 30-second version
KB5124008 (September 8, 2026) and later updates make Windows 11, 24H2, 25H2, and 26H1 begin honoring
previously configured Machine Identity Isolation settings — a Credential Guard feature Microsoft
documented as temporarily disabled starting with the April 2025 update (KB5055523). It's supported only at
or above Windows Server 2025 Domain Functional Level; below that, previously configured or enabled devices
can lose their secure channel and show a domain trust error. Status: Mitigated, not Resolved, as of
September 16, 2026, no fix date set. Check Intune, Group Policy, and the registry keys above, disable it,
restart, and run Test-ComputerSecureChannel -Repair. Keep a local admin credential handy —
enforcement mode may need an unjoin and rejoin instead.
If you want a senior engineer to check where Machine Identity Isolation is configured across your fleet, the project intake form takes about three minutes. We'll come back with scope and a fixed-fee range.
Pro IT NW does senior-led identity work for mid-market and regulated organizations. Vendor-neutral, labor-only. This post reflects Microsoft's published documentation as of September 18, 2026, plus our own judgment on sequencing — not Microsoft's guidance.
Questions we get asked
- What causes the domain trust relationship error after KB5124008?
- After installing the September 8, 2026 Windows security update (KB5124008) or later updates, some Credential Guard protected machine accounts might lose their secure channel with an on-premises Active Directory domain. Affected users might be unable to sign in interactively with valid domain credentials and might see a message stating the trust relationship between the device and the domain failed. Per Microsoft, the cause is that KB5124008 and later updates cause Windows to begin honoring existing or policy-provisioned settings that enabled the Machine Identity Isolation feature's enforcement — the update does not directly enable that enforcement itself. Offline sign-in using previously cached credentials might continue to work, and AD replication and AD services on the domain controllers are not affected. Microsoft's general troubleshooting article for domain trust issues gives the on-screen text as, verbatim, "The trust relationship between this workstation and the primary domain failed" — though we can't confirm this specific issue always displays that exact wording.
- Does this issue affect Windows Server?
- No. Microsoft's release-health entry lists affected platforms as Client: Windows 11, version 26H1, 25H2, and 24H2; Server: None. We also checked Microsoft's release-health pages for Windows Server 2025, Windows Server 2022, the combined Windows 10 1809/Server 2019 page, the combined Windows 10 1607/Server 2016 page, and Windows 10 22H2 — this issue is not listed on any of them. Where Windows Server does matter is on the other side of the trust relationship: Microsoft says Machine Identity Isolation is only supported for environments connected to domain controllers running at Windows Server 2025 Domain Functional Level and above, and should be disabled elsewhere.
- How do I check if Machine Identity Isolation is enabled in my environment?
- Check whichever management surface your organization uses. In Intune, it's the DeviceGuard/MachineIdentityIsolation setting in the Policy CSP. In Group Policy, it's Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security, under the Machine Identity Isolation Configuration option. Directly in the registry, on a Windows 11, version 24H2 or 25H2 device, check both HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation and HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation — look for a value of 2, which Microsoft's DeviceGuard Policy CSP page defines as "Enabled in enforcement mode" (1 is audit mode, 0 is disabled).
- What is the fix?
- Microsoft's release-health workaround is to disable Machine Identity Isolation using the same management method that was used to enable it — Intune, Group Policy, or, if it was set directly, the registry keys above (set MachineIdentityIsolation to 0) — then restart the device, then reset the secure channel with Test-ComputerSecureChannel -Repair -Credential (Get-Credential). Microsoft's separate documentation on the underlying Group Policy setting describes a different path out of enforcement mode: it states that if the policy was previously set to Enabled in enforcement mode, the device must be unjoined and rejoined to the domain, and that only the local administrator account can do it. The two pages don't reconcile. Our advice is to try the release-health procedure first, since it is written specifically for this known issue, and keep a local administrator credential available in case the device needs an unjoin and rejoin instead.
- Will Microsoft release a permanent fix, and when?
- Microsoft's stated next step, verbatim, is: "We plan to resolve this issue in a future Windows update by temporarily preventing Machine Identity Isolation enforcement while improvements are made to the feature." No fix version or date has been published as of the issue's last update, September 16, 2026.
- Is this related to the Remote Desktop Services issue from the same update?
- They share an originating update but are separate known issues. KB5124008, released September 8, 2026, is also the Windows 11, version 24H2/25H2 package in a September 2026 update cycle that carries a separate, unrelated Remote Desktop Services known issue affecting RDP connections, sign-in, and related tools. See our post on that RDS issue for its own status and workaround; it is not the same defect as the Machine Identity Isolation trust-relationship problem described here.
Related service
Active Directory Audit serviceWritten by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle and the Pacific Northwest, delivered USA-wide.