Trust Relationship With the Primary Domain Failed After 26H2: The Fix

"The trust relationship between this workstation and the primary domain failed" has a brand-new cause as of September 29, 2026, the day Windows 11 version 26H2 shipped. In plain words: every work PC that belongs to a company network has a password of its own, separate from yours, and it uses that password at every boot to prove to the company's servers that it is the same machine as yesterday. 26H2 quietly starts honoring a setting called Machine Identity Isolation, which moves that password into a locked part of memory named Credential Guard. The servers can only work with it there if they run at the Windows Server 2025 level. On any older setup the check fails, the PC is treated as a stranger, and nobody with a company account can sign in on it. Your password is fine. The computer's is simply in a place the server cannot reach.

The fix is to turn Machine Identity Isolation off in the same place it was turned on (Intune, Group Policy or the registry), restart, then repair the PC-to-server connection with one PowerShell command, Test-ComputerSecureChannel -Repair. Here is the part that makes this one strange: Microsoft switched this exact feature off in April 2025 because of a bug, so a setting you may have made and forgotten eighteen months ago has just been switched back on by a 174 KB update.

Ethan looks after a forty-seat domain for a logistics firm as a side contract. On Tuesday he let 26H2 through to the four pilot laptops, and by Wednesday morning two of them greeted their owners with the trust relationship message. He did what every admin does first: signed in with the local admin account, ran the secure-channel repair, rebooted. One laptop came back. The other failed the same way before lunch. That second failure is what this page is about, because the classic repair only sticks if you remove the thing that keeps re-breaking the channel, and in 26H2 that thing is a Group Policy value nobody has looked at since 2025.

If you are here from a home PC that is not joined to a domain, this error cannot be yours; a different message with similar words is covered in the black screen after sign-in fix ladder. Everyone else: the next section explains the mechanism, the one after that is a diagnosis you can finish before your coffee cools, and the fix follows in the order that holds.

What "the trust relationship between this workstation and the primary domain failed" means

Every domain-joined computer has its own account in Active Directory, with its own password. Windows rotates that password on its own, every 30 days by default, and uses it to build a secure channel to a domain controller each time the machine boots. When a user signs in with domain credentials, the request travels over that channel. If the password the computer holds and the password the domain holds no longer agree, the channel cannot be built, and Windows reports the mismatch with the sentence that brought you here. The user's own password is fine. The computer's is not.

The classic causes have not changed, and if you have been an admin for more than a year you can recite them: a virtual machine restored from a snapshot older than the last password rotation, a cloned machine with a duplicate name, a computer object reset or deleted in Active Directory, a clock more than five minutes off the domain controller so Kerberos refuses the ticket, or a machine that was offline so long its stored password lapsed. The classic causes section near the end has the table and the fix for each, including the "error 1789" and "RDP" variants that people search for by name.

What is new is a cause that produces the same message on a machine that did nothing wrong. The machine's password is correct. It has simply been moved somewhere the domain controller cannot work with, and that is the 26H2 story.

Why Windows 11 26H2 breaks the trust: Machine Identity Isolation in plain English

Credential Guard has protected user credentials inside a virtualization-based enclave since Windows 10. What it did not protect, until recently, was the computer account's own password, which lived in the registry under the LSA secret $MACHINE.ACC, readable by anyone who could get SYSTEM on the box. That mattered more every year, because Kerberos armoring and the newer group and delegated managed service accounts lean on the machine account to add entropy and to grant access to service accounts. Dump the machine secret and you had a path to accounts that were supposed to be hard.

Windows Server 2025 introduced the answer: Credential Guard protected machine accounts, controlled by a setting called Machine Identity Isolation. It has three states, and the numbers matter because they are what you will find in the registry:

The feature is only supported when the device talks to domain controllers running at the Windows Server 2025 domain functional level or higher. Microsoft's own wording is that it "should be disabled elsewhere". And it is an Enterprise and Education policy; Pro editions do not carry it.

The April 2025 switch-off, and the September 2026 switch-on

Here is the sequence that turned a known limitation into a Wednesday-morning outage. In April 2025, with the KB5055523 security update, Microsoft temporarily disabled Credential Guard protected machine accounts on Windows Server 2025 and Windows 11 24H2 because of a problem with machine password rotation over Kerberos. The policy setting stayed in the Group Policy editor and in the Intune catalog. Admins who had tested the feature in early 2025 and left the policy in place saw nothing happen for eighteen months, because Windows was ignoring the value.

Windows 11 26H2 starts honoring it again. The enablement package does not enable Machine Identity Isolation itself; Microsoft is careful to say that. What it does is cause Windows to "begin honoring any existing or policy-provisioned settings that enabled Machine Identity Isolation enforcement". If that value is 2 and your domain controllers are at a 2016, 2019, or 2022 functional level, the first reboot after 26H2 moves the machine password into the enclave, deletes the LSA copy, and the domain controller can no longer complete the exchange. The machine still has a valid secret. The domain cannot use it.

Microsoft's stated plan is to resolve this in a future update "by temporarily preventing Machine Identity Isolation enforcement while improvements are made to the feature". Until that lands, the fix is yours to apply, and it is the next two sections.

How to tell the 26H2 cause from the ordinary one, in five minutes

Ethan's second laptop taught him the order. The repair command works on both causes, but on the 26H2 cause it does not hold, because policy re-isolates the secret at the next refresh or reboot. So before you repair anything, confirm which cause you have.

1. Sign in with a local administrator account. Not a domain account; the secure channel is the thing that is broken. If you use LAPS, pull the password from Intune or Active Directory now. If the device has no local admin you can reach, the no-local-admin section has the workaround.
2. Confirm the device is on 26H2. Run winver. Build 26300 is 26H2. If it says 26200 or 26100 and the error appeared anyway, you have a classic cause; skip to the classic table.
3. Read the two registry values. In an elevated PowerShell:

   Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name MachineIdentityIsolation -ErrorAction SilentlyContinue
   Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name MachineIdentityIsolation -ErrorAction SilentlyContinue

   A value of 2 in either place is your answer. A 1 means audit mode, which usually survives but is worth removing on a domain that cannot support it. Nothing returned, or 0, means Machine Identity Isolation is not your cause.
4. Check where the policy came from. gpresult /h C:\gp.html and search the report for "Machine Identity Isolation" under Computer Configuration, System, Device Guard. If it is not in Group Policy, look in the Intune Settings catalog for the DeviceGuard area. If it is in neither, somebody set the registry by hand in 2025, which is exactly the case Microsoft's third workaround exists for.
5. Check the domain functional level, from any domain-joined machine that still works: (Get-ADDomain).DomainMode. Anything below Windows2025Domain confirms the mismatch.

Two symptoms that point here before you touch a registry key: users whose credentials were cached can still sign in offline, because cached logon does not need the secure channel, and the error appears on a machine that was healthy the day before the 26H2 restart. Snapshot and clone causes almost never line up with a feature update that cleanly.

The fix, in order: turn off Machine Identity Isolation, restart, repair the channel

The rule that makes this work is Microsoft's own: disable the setting using the same management method that enabled it. If Intune set it, a registry edit will be overwritten at the next sync. If Group Policy set it, the same thing happens at the next refresh. Fix it at the source, then fix the machine.

Step 1: disable Machine Identity Isolation where it was set

If Intune set it. In the Settings catalog, the DeviceGuard area, change Machine Identity Isolation to Disabled, value 0. If you deployed it by OMA-URI, the path is ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/MachineIdentityIsolation with an integer value of 0. Sync the device from the Company Portal or from the Intune console once it is back on the network.

If Group Policy set it. Open the GPO and go to Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Inside that one setting, the dropdown labeled Machine Identity Isolation Configuration is the control. Set it to Disabled, not Not Configured; Not Configured leaves the existing registry value in place, which is the trap here. Then gpupdate /force on the affected machine while signed in as the local admin.

If the registry was set directly. Back up both keys first, then in an elevated PowerShell:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" C:\lsa-backup.reg /y
reg export "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" C:\deviceguard-backup.reg /y

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name MachineIdentityIsolation -Value 0 -Type DWord
Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name MachineIdentityIsolation -Value 0 -Type DWord

Set whichever of the two exists; if both do, set both. Microsoft's guidance is specifically "if the value is 2, set it to 0".

Step 2: restart

Not a sign-out, a restart. The machine password location is decided when LSA starts. Until the reboot, the enclave still owns the secret.

Step 3: repair the secure channel

Signed in as the local admin again, in an elevated PowerShell, with a domain account that has rights to reset the computer object:

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

Enter the domain credentials at the prompt as DOMAIN\user. The command returns True when the channel is rebuilt. Sign out, and a domain user should be able to sign in normally. Ethan's second laptop came back on this exact sequence, and stayed back, because the policy that re-broke it was gone before the repair ran.

Step 4: if the machine will not authenticate at all after enforcement mode

Microsoft's documentation carries a warning that matters for the worst case: a device that was in enforcement mode and is then set to Disabled "must be unjoined and rejoined to the domain, as it's unable to authenticate otherwise", and "only the local administrator account can be used to unjoin and rejoin". If the repair command fails after the restart, this is why. The sequence, as local admin:

Remove-Computer -UnjoinDomainCredential (Get-Credential) -WorkgroupName WORKGROUP -Force -Restart
# after the restart, as local admin again:
Add-Computer -DomainName corp.example.com -Credential (Get-Credential) -Restart

The computer object keeps its name, group memberships survive if you do not delete the object in between, and user profiles on the machine are untouched because the SID of the domain does not change. It is ten minutes, and it is the one case where no shortcut exists.

The PowerShell commands for the trust relationship error, exactly

"Trust relationship failed PowerShell" is its own search for a reason: three commands do the same job in slightly different circumstances, and the guides rarely say which to use when.

Two details that save a retry. Test-ComputerSecureChannel without -Repair only reports; it is a fine first command to see whether the channel is really down. And on all of these, the -Credential prompt wants a domain account, not the local admin you are signed in as; the local admin is the key to the room, not to the domain.

"No local admin": getting in when the only admin account is a domain one

The search phrase "trust relationship failed no local admin" describes the admin's nightmare and it has a clean answer. Disconnect the machine from the network, wired and wireless. Sign in with a domain account that has signed in on that machine before; cached credentials work with the network off because Windows cannot reach a DC and falls back to the cache. Once on the desktop, reconnect the network, open an elevated PowerShell with that same cached account, and run the repair with -Credential pointing at a different domain admin account. If cached sign-in has been disabled by policy, the remaining doors are a LAPS password, Safe Mode with the built-in Administrator enabled, or a recovery boot to enable it, in that order of effort.

Fixing it remotely

When the machine is in a branch office, the trick is that the broken secure channel blocks domain-authenticated remote tools, so WinRM and PsExec with domain credentials fail. What works: a remote session as the local admin, for example Enter-PSSession -ComputerName LAPTOP07 -Credential LAPTOP07\localadmin once PowerShell remoting is allowed for local accounts, or an Intune remediation script, which runs as SYSTEM and does not need the channel. For the 26H2 cause, an Intune script that sets both registry values to 0 and schedules a restart, followed by the repair run remotely as local admin, is the whole fix without a site visit. The WMIC replacement post has the PowerShell patterns for fleet-wide registry reads if you want to find every machine with a 2 before it reboots into 26H2.

Stop the rest of the fleet from hitting it

Two laptops out of four is a pilot ring doing its job. The point of the next hour is to make sure the other thirty-six never see the message.

1. Hold 26H2 at the ring. In Intune, pause the feature update policy or leave the ring on 25H2. In Group Policy, Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Update > Select the target Feature Update version, product Windows 11, version 25H2. The registry equivalent under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate is TargetReleaseVersion = 1, TargetReleaseVersionInfo = 25H2, ProductVersion = Windows 11. Devices already on 26H2 are not rolled back by this; it only stops the offer.
2. Find every machine carrying the value. From a working admin workstation, against your list of domain computers:

   $computers = Get-ADComputer -Filter {OperatingSystem -like "Windows 11*"} | Select-Object -ExpandProperty Name
   Invoke-Command -ComputerName $computers -ErrorAction SilentlyContinue -ScriptBlock {
     $a = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name MachineIdentityIsolation -ErrorAction SilentlyContinue).MachineIdentityIsolation
     $b = (Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name MachineIdentityIsolation -ErrorAction SilentlyContinue).MachineIdentityIsolation
     [pscustomobject]@{ Computer=$env:COMPUTERNAME; LsaValue=$a; PolicyValue=$b; Build=(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').CurrentBuild }
   } | Sort-Object LsaValue, PolicyValue -Descending | Format-Table -AutoSize

   Any row showing 2 on build 26100 or 26200 is a machine that will break on its first 26H2 restart. Any 1 is worth clearing while you are there.
3. Remove the policy at the source before the hold is lifted: the Intune setting to Disabled, or the Group Policy dropdown to Disabled, then let the fleet refresh. Confirm with the same scan; it should return 0 or nothing everywhere.
4. Decide whether you want the feature at all, which is the section below, and only re-enable it on a domain that has reached the Server 2025 functional level, in audit mode first.
5. Lift the hold ring by ring. 26H2 itself is a 174 KB enablement package on top of the September cumulative, and the KB5124008 post covers the rest of what that month changed. There is also a hard date behind this: Windows 11 24H2 Home and Pro editions stop receiving updates on October 13, 2026, so any 24H2 Pro machines on your floor need either 25H2 or 26H2 before Patch Tuesday. Enterprise 24H2 runs to October 2027.

"The security database on the server does not have a computer account for this workstation trust relationship"

This longer message gets searched almost as often as the short one and it is a different fault. The short message says the passwords disagree. This one says the domain controller cannot find the computer account at all: the object was deleted, moved to a tombstone, or the machine is talking to a domain controller that has not yet received the object through replication, which happens when a machine is joined at one site and boots at another within the replication interval.

The fix order: check Active Directory Users and Computers, or Get-ADComputer LAPTOP07, from a working machine. If the object is missing, restore it from the Recycle Bin if the forest has it enabled (Get-ADObject -Filter 'isDeleted -eq $true -and Name -like "LAPTOP07*"' -IncludeDeletedObjects | Restore-ADObject), then run the secure-channel repair. If the Recycle Bin is not enabled, rejoin the domain, which recreates the object with a new SID and loses group memberships, so note those first. If the object exists and the machine still says the database has no account, force replication with repadmin /syncall /AdeP on a domain controller and wait a few minutes before repairing. Machine Identity Isolation does not produce this message; if you see this one on 26H2, it is a coincidence of timing, not the feature.

Error 1789, the RDP variant, VMware snapshots, and Windows 10: the classic causes

The 26H2 cause will be the common one for a few weeks and then fade as fleets clean the policy out. The causes below are permanent. If your diagnosis in the five-minute section came back with no Machine Identity Isolation value, you are in this table.

If a Windows 10 machine on your floor is the one with the error, it is also worth knowing that its clock is not the only thing running out: the Windows 10 Extended Security Updates now run to October 12, 2027, which changes the replace-or-repair math for a lot of small fleets.

Should you be using Machine Identity Isolation at all?

Yes, eventually, and no, not today, for most of the people reading this. The threat it closes is real: a machine account secret readable from the registry by anyone with SYSTEM is a path into gMSA and dMSA service accounts and into Kerberos armoring, and Credential Guard is the right place for it. The conditions attached are what decide the timing.

It requires the Windows Server 2025 domain functional level, which means every domain controller in the domain on Server 2025 and the level raised, a step many organizations have not taken because raising the level is one-way. It requires Credential Guard to be running, and Microsoft's documentation carries a blunt warning: if Credential Guard fails to start after a reboot, the device "results in the inability to complete domain authentication, potentially requiring intervention from a local administrator account to recover". And the feature was pulled in April 2025 for a password-rotation bug that Microsoft has not yet described as fixed; the 26H2 release note says enforcement will be temporarily blocked again while "improvements are made".

Ethan's rule for the logistics firm, which is on a 2022 functional level: policy set to Disabled everywhere, explicitly, so the registry value is written as 0 and cannot be re-read as a stale 2. When the domain reaches Server 2025, audit mode on one ring for a month, then enforcement ring by ring. That is also the order Microsoft's own documentation describes, with the extra note that moving from enforcement back to audit or disabled on a device requires the unjoin and rejoin.

For IT admins: the checklist for the 26H2 wave

Everything above, in the order a ticket would run, plus the pieces of 26H2 that touch domain machines and did not make the consumer headlines.

Before the ring opens

1. Scan the fleet for MachineIdentityIsolation values with the script in the fleet section; clear every 1 and 2 unless the domain is at the Server 2025 level and you meant it.
2. Confirm KB5124010, the September 22 preview cumulative, or a later update is on each device. The 26H2 enablement package requires it and will not offer without it.
3. Devices on 26H1, the new-hardware branch, are not eligible for the 26H2 package; do not chase the offer on them.
4. Note the 24H2 Home and Pro end-of-updates date, October 13, 2026, and move any Pro machines first.
5. Pilot ring only, with the Select the target Feature Update version policy holding everyone else at 25H2.

The 26H2 known issues, as of October 1

Three are open, all marked mitigated by Microsoft. The domain trust issue is this page. The second is a black screen or desktop that does not load after sign-in, seen mostly on Azure Virtual Desktop session hosts using FSLogix profiles; the quick workaround is Task Manager, Run new task, explorer.exe, and the fleet fix is the Known Issue Rollback Group Policy MSI Microsoft published for 24H2, 25H2, and 26H2 under the name KB5124010 260924_20021 Known Issue Rollback, with a separate one for 26H1. The third is USB Audio Class 1.0 devices failing with Code 10, which dates from the September 8 update rather than 26H2 itself; the USB audio Code 10 post has every symptom and the out-of-band update that fixed the multichannel part.

What else 26H2 changes for a domain fleet

• Administrator protection ships, off by default: just-in-time elevation with profile separation instead of standing admin rights. Enable through Intune or Group Policy, and test every installer that assumes a persistent admin token.
• Sysmon is built into Windows, off by default, with the same configuration-file model as the Sysinternals download. Your SIEM pipeline gains a native source once you turn it on.
• Cross-signed driver trust is removed. Only WHCP-signed drivers and an allow list of legacy drivers load. Windows audits for at least 100 hours and three restarts before enforcing, which means the driver failures will arrive a week or two after the upgrade, not on the day. Audit your hardware vendors now; the honest guide to updating drivers explains why "latest from the vendor" and "WHCP-signed" are not the same claim.
• WMIC is gone on 24H2 and later and is no longer available as a feature on demand. Login scripts that still call it fail silently. The "wmic is not recognized" post is the one your helpdesk will need, and the replacement post has the PowerShell for each command.
• Batch files get a more secure processing mode, administratively enabled, that prevents a batch file from changing during execution. Self-modifying logon scripts stop working under it.
• NTLM remains deprecated and NTLMv1 removed since 24H2; Kerberos armoring and the Negotiate package are the direction, which is exactly why the machine account secret became worth protecting.
• Post-quantum APIs for ML-KEM and ML-DSA arrive in CNG and .NET. Nothing to do yet, and the first thing a compliance questionnaire will ask about next year.
• Policy-based removal of preinstalled apps extends to additional MSIX and APPX packages by package family name through Group Policy, which retires a lot of provisioning scripts.
• Point-in-time restore and quick machine recovery are both present; on domain-joined devices quick machine recovery stays off until you enable it.
• Windows settings backup turns on by default for eligible commercial devices; existing admin policies are honored, but check that you have one.

One housekeeping note for the same morning: if an enablement package fails to apply with a component-store error, the 0x80073712 repair post is the order of operations, and the 0x80070005 access-denied post covers the permissions variant that shows up on machines with aggressive endpoint protection.

Ethan told Jake the story over the counter at the shop, mostly because Jake had asked whether a feature update could really break a sign-in. It can, and this one did, through a setting that had been politely ignored for a year and a half. The logistics firm's thirty-six other laptops never saw the message, because the scan found four more machines carrying a 2, and the policy was cleared before the ring opened. If your Wednesday looked like Ethan's, you did nothing wrong; you set a feature up in 2025 the way the documentation told you to, and Windows changed its mind about honoring it. The registry value is a two-minute fix. The decision about when to turn it back on is the part worth an afternoon.

Revision note. Written October 2, 2026, three days after Windows 11 26H2 started rolling out. If two of your pilot machines locked their owners out this week, that is the feature misfiring, not your rollout. Good luck with the rest of the ring.