KB5124008 revives a dormant Credential Guard setting and breaks domain trust below Server 2025

Eight days, 628 fixes and a setting nobody remembers switching on

Microsoft's own September 2026 security data lists 628 CVEs fixed for Windows 11 versions 24H2 and 25H2 by KB5124008, the cumulative update released on 8 September. One of them, CVE-2026-81963, is marked "Exploitation Detected". On 16 September at 14:15 Pacific time, Microsoft opened a Windows release health entry admitting that the same update can cost domain-joined PCs their trust relationship with Active Directory. That was eight days after release, and 7 days, 3 hours and 18 minutes after an administrator posted a reproducible fault report on Microsoft's own Q&A forum.

Those numbers do not establish three things. They do not show that every domain-joined Windows 11 PC is at risk: Microsoft ties the failure to devices where a Credential Guard feature called Machine Identity Isolation is configured, in domains that are not at Windows Server 2025 domain functional level. They do not show how many organisations are affected: Microsoft publishes no count, and the only fleet figure in the coverage is one administrator's report, relayed by BleepingComputer, of 11 affected devices out of about 256. That is roughly 4.3 per cent of one estate, not a rate. And the eight-day gap does not prove Microsoft sat on the problem: BleepingComputer says Microsoft told it the week before that it was investigating. What the gap does show is how long IT teams worked from forum posts.

The decision for an IT lead is harder than the headline suggests, because every option carries a documented cost. Uninstalling the update reopens an exploited privilege escalation flaw. Applying Microsoft's workaround is itself a configuration change that another Microsoft document says can break domain authentication. This briefing sets out what Microsoft has put on the record, where its own documents pull against each other, and an order of work that keeps the exploited flaw closed.

What Microsoft has put on the record

The primary source is the release health entry titled "Domain-joined devices might lose their secure trust relationship with the domain". It appears on the status pages for Windows 11 versions 24H2, 25H2 and 26H1. The 24H2 and 25H2 entries are identical apart from the build number; the 26H1 entry names KB5124012 as the originating update. As fetched on the morning of 17 September, its status is Mitigated. In release health terms that means a workaround exists. It does not mean a fix has shipped.

The release health entry, read line by line. Source: Windows release health status pages for Windows 11 24H2, 25H2 and 26H1, fetched 17 September 2026.

Question	Stated by Microsoft	Not stated
Which versions	Windows 11 24H2 (build 26100.9445), 25H2 (26200.9445), and 26H1 via KB5124012. Server: None	How many devices or organisations are affected
What triggers it	The update makes Windows honour existing or policy-provisioned Machine Identity Isolation enforcement settings	How devices came to hold the setting where administrators say they never set it
Where the feature is supported	Domains at Windows Server 2025 domain functional level and above	Why lower functional levels fail
Symptoms	Secure channel lost; valid domain credentials rejected at interactive sign-in; trust relationship failure message; cached sign-in may still work	Any event IDs, error codes or log sources to look for
Domain controllers	AD replication and AD services on domain controllers are not affected	Whether domain controller patch level changes the outcome
Workaround	Disable the feature by the method that enabled it, restart, repair the secure channel	Whether an unjoin and rejoin is ever needed
Fix	A future update will temporarily prevent enforcement	A date, a KB number, or a Known Issue Rollback
Timing	Opened 16 September 2026, 14:15 PT; last updated 14:23 PT	Any later update, as of 17 September

Two more primary pages matter. The KB5124008 support article, fetched the same morning, still listed three known issues (USB audio devices, Plan9 folder shares in Hyper-V based Linux VMs, and Remote Desktop Services) and nothing about domain trust. Its change log stops at 14 September. And the out-of-band update KB5129195, released on 14 September to fix the Remote Desktop and Plan9 problems, does not mention domain trust at all. Microsoft's entry says the issue follows "KB5124008 and later updates", so moving a device to the out-of-band build does not take it out of scope.

What "breaks domain trust" means

Every domain-joined Windows machine has a computer account in Active Directory and a password for that account, stored locally. The machine uses the secret to set up a secure channel with a domain controller, and it changes the password on its own schedule. If the domain controller can no longer validate what the machine presents, the secure channel fails, and interactive sign-in by domain users fails with it. Microsoft's entry describes exactly that: valid credentials are rejected, users may see a message that the trust relationship between the device and the domain failed, and sign-in with previously cached credentials may still work. That last detail explains why some users can reach a desktop while disconnected from the network but not while connected.

Machine Identity Isolation changes where the machine secret lives. Microsoft's DeviceGuard Policy CSP documentation defines three values:

• 0, disabled (the default): the machine password is bound only to LSASS and stored in the $MACHINE.ACC registry key.
• 1, audit mode: the password is bound to both LSASS and IUM, the isolated user mode in which Credential Guard runs, and stored in both $MACHINE.ACC and $MACHINE.ACC.IUM.
• 2, enforcement mode: the password is bound only to IUM and stored only in $MACHINE.ACC.IUM.

The security case is genuine. Microsoft's Learn page on Credential Guard protected machine accounts says machine account secrets "can be easily extracted from the registry" and then used against highly secured service accounts, including gMSA and dMSA accounts that now rely on machine accounts. Moving the secret into Credential Guard puts it out of reach of unprivileged users, administrators and drivers. The same page carries its own warning: if Credential Guard fails to start after a reboot, domain authentication cannot complete and a local administrator may be needed to recover.

What Microsoft does not explain is why enforcement fails against domains below Windows Server 2025 functional level. The entry says only that the feature is supported there and should be disabled elsewhere. Administrators on the Q&A thread offer theories about how the domain controller handles the isolated secret. None is confirmed, and this briefing does not repeat them as fact.

A feature switched off in April 2025 has woken up

The Learn page, last updated on 11 April 2025, opens with a notice that the April 2025 security update KB5055523 temporarily disabled Credential Guard protected machine accounts in Windows Server 2025 and Windows 11 version 24H2. The reason given is a machine password rotation issue involving Kerberos. The KB5055523 release notes say the same, and that the feature stays disabled until a permanent fix is available.

The September entry now says KB5124008 and later updates enable the feature, and that Windows begins to honour any existing or policy-provisioned settings that turned on enforcement. From 8 April 2025 to 8 September 2026 is 518 days. The following is inference, not a Microsoft statement: a device whose policy or registry held value 2 at any point in that period could have carried it silently while Windows ignored it, then acted on it after the September update. That would fit the administrators who insist they never enabled the feature. It does not explain everything on the thread, which also includes a policy registry value of 3, a number the CSP does not define.

The workaround is a change that can break trust too

Microsoft's published workaround runs in this order. Disable Machine Identity Isolation using the same management method that enabled it: Intune, Group Policy or the registry. For the registry route, check two paths and, where the value is 2, set it to 0. Restart. Then repair the secure channel. These are the paths and the command exactly as Microsoft publishes them:

Registry paths named by Microsoft:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation

If either value is 2, set it to 0. Restart the device. Then run:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Now read the Learn page on the same transition. For the Disabled option it says that if the policy was previously set to enforcement mode, the device must be unjoined and rejoined to the domain because it cannot authenticate otherwise, and that only the local administrator account can do that. The release health entry says restart and repair. Both are Microsoft documents, and they describe different recovery costs for the same change. Community reports sit on both sides: the accepted answer on the Q&A thread says a registry change, a restart and a secure channel repair held; the original poster, before the cause was known, found only a full leave and rejoin worked.

One report describes the workaround itself going wrong. An administrator who disabled the feature through Group Policy across their estate wrote on 16 September that, four to five days later, workstations began losing their secure channel one after another, including machines that had never received the update. This is a single forum account, not a Microsoft finding, and its cause is not established. It is consistent with the Learn page's warning, and it is the strongest reason to pilot the disablement itself, not only the update.

What rolling back would give up

KB5124008 is cumulative. Uninstalling it returns a device to its August build and removes all 628 September fixes for 24H2 and 25H2. In Microsoft's September CVRF data, 53 of those are rated Critical and 575 Important; 53 are marked "Exploitation More Likely" and one "Exploitation Detected". Microsoft marks two CVEs across the whole September release as exploited, and only one of them applies to these Windows 11 versions.

The two September 2026 CVEs Microsoft marks as exploited, and where they apply. Sources: MSRC September 2026 CVRF, NVD records, CISA KEV catalogue version 2026.09.16.

CVE	What it is	Applies to Windows 11 24H2 and 25H2?
CVE-2026-81963	Windows Update Stack elevation of privilege (link following) to SYSTEM. Important; CVSS 3.1 base 7.8, assigned by Microsoft	Yes. Fixed by KB5124008 (builds 26100.9445 and 26200.9445). Also affects 23H2, 26H1 and Server 2025
CVE-2026-85880	Windows ALPC heap-based buffer overflow, elevation of privilege. Important; CVSS 3.1 base 7.8, assigned by Microsoft	No. Windows 10 versions 1607, 1809, 21H2 and 22H2, and Windows Server 2012 to 2022 only

CISA added both to its Known Exploited Vulnerabilities catalogue on 8 September, with a due date of 22 September, 14 days later. That deadline applies to US federal agencies, not UK organisations, but the listing is a second, independent signal that exploitation has been seen. Neither KEV entry records known ransomware use; both say "Unknown". Microsoft marks neither as publicly disclosed.

The table cuts two ways. On the Windows 11 fleet, the exploited flaw a rollback would reopen is CVE-2026-81963. It is a local escalation that needs an attacker already running code as a low-privileged user, which makes it a second-stage tool: the step after a phishing foothold, not the foothold. On the domain controllers, CVE-2026-85880 applies to Windows Server 2016, 2019 and 2022, the versions run by the environments reporting this issue. Microsoft lists the server platforms affected by the trust issue as None. Nothing in the record supports pausing domain controller patching, and there is a reason not to.

The out-of-band update does not change the arithmetic. KB5129195 adds protection for CVE-2026-62721, a User-Mode Power Service elevation of privilege first published on 11 August 2026, which is not in the KEV catalogue. Its fixes for Remote Desktop Services and Plan9 shares are real, but it does not address domain trust.

Roll back, pause, or deploy with a mitigation

The options, with what each buys and costs. Sources: release health entry, Learn page on Credential Guard protected machine accounts, MSRC September 2026 data, Microsoft Q&A thread (labelled where used).

Option	What it buys	What it costs or leaves unknown
Uninstall KB5124008	Restores sign-in on affected devices, according to administrator reports	Reopens 628 CVEs, including exploited CVE-2026-81963. Microsoft does not suggest it. One administrator still needed a leave and rejoin
Pause further deployment	Stops new breakage while you inventory	Unpatched devices stay exposed to CVE-2026-81963. The out-of-band build does not help. No fix date
Disable the feature, then deploy	Microsoft's documented route; security fixes stay in place	Learn page says leaving enforcement mode needs an unjoin and rejoin. One report of delayed estate-wide failures
Deploy where the value is 0 or absent	Closes the exploited flaw now on the clean majority	Depends on your inventory being right and Microsoft's scope description being complete
Deploy at Server 2025 functional level	Microsoft says the feature is supported there	Not stated: whether any failures occur in supported domains

Put plainly, Microsoft's own description says the failure comes from the update meeting a value on the device. That makes this an inventory problem before it is a patching problem. An estate that can read one registry value from every Windows 11 device in an afternoon can release the update to the clean majority this week and handle the rest with care. An estate that cannot answer that question has a wider gap than KB5124008.

Method, sources and interests

The diagnosis came from administrators, not from Microsoft. The accepted answer identifying the registry value was posted on 11 September at 06:00 UTC, 5 days and 15 hours before Microsoft's entry opened. Community evidence needs care in both directions. On the same thread, an answer from an account badged "Independent Advisor" attributed the fault to Netlogon hardening against Server 2019 domain controllers and advised uninstalling the update or moving domain controllers to Server 2022. Microsoft's later entry points to Machine Identity Isolation instead. That answer was not a Microsoft statement, and it shows why confident forum advice is a lead, not a source.

Interests are worth naming without overstating them. Microsoft promotes Machine Identity Isolation as hardening for service accounts, a legitimate security aim, and its entry describes the coming fix as temporarily preventing enforcement while improvements are made, not as withdrawing the feature. BleepingComputer's report drew on forum and Reddit posts and said Microsoft had not confirmed the root cause; it was published about 35 minutes before Microsoft's entry opened, so that was accurate when written. The Reddit posts it cites refused automated access for this briefing (HTTP 403), so figures from them are labelled as reported by BleepingComputer.

Microsoft's entry names no event IDs or error codes. Administrators on the thread posted several; because Microsoft has not documented them, this briefing does not reproduce them as detection guidance.

What to do, in order

The question that exposes the gap

Microsoft's workaround opens with an instruction that assumes knowledge many estates do not have: disable the feature using the same management method that was used to enable it. So the question for every IT lead this week is not really roll back or push on. It is this: for every Windows 11 device you own, can you say what value MachineIdentityIsolation holds, and which system put it there? If the answer is no, KB5124008 did not create that gap. It found it.

Key facts