We have faced the same issue at our organization, from both KB5072033 and KB5074109 updates. And we've dealt with it by uninstalling both updates, and hiding them from Windows Update by using the PowerShell command "Hide-WindowsUpdate -KBArticleID KB507xxx -Verbose".

But we may have stumbled across a more permanent fix late last week, without the need to uninstall any updates. In the RD connection window, within the Advanced tab, there's an option to use a web account to sign in to the remote computer.

By activating this option it utilizes the Microsoft 365 credentials instead. We have also SSO active, though I'm not sure how much that affects this sign-in method.

But the strange thing is, prior to the December update this option did not work for us. So something has evidently changed, either the updates have fixed or enabled it, or Microsoft has changed something without notifying us.

I'm not sure if Microsoft would see this as a permanent fix or not, since they have yet to acknowledge the issue at all. But I would recommend trying out enabling this option, or at least looking into it.

We have the same issue on both 24h2 and 25h2 Win11 after installing KB5072033.
using rdp /remoteguard breaks sso browser auth. (network shares are still fine ; which is something that also broke in the past when remotecredential guard was broken)

I wonder if @Steve Syfuhs has any more thoughts on this.

We have the same issue...
Revert to November Patch, not working
An Idea, to quick fix this?

We have the same issue.

OS Builds 26100.7171, 26200.7171 work fine (KB5068861).

If i upgrade the same PCs to 26100.7462, 26200.7462 (KB5072033), Kerberos Double-Hop Delegation (using Remote Credential Guard) stops working. The RDS servers are Windows Server 2025 session hosts.

A client machine with this update installed can no longer access backend network resources (e.g., file shares, SQL databases) from within an RDP session that was established using Remote Credential Guard.

If the RDP session is locked, and then unlocked with password, Kerberos works again.

When attempting to access the backend resource, a credential prompt appears with the error: "The system cannot contact a domain controller to service the authentication request."

• Diagnostic analysis shows that the RDSH server's LSA fails the request internally; no Kerberos request is ever sent to the Domain Controller. This is confirmed by the absence of corresponding failure audits (Event ID 4769) on the DC. The issue appears to be that the security context created on the RDSH server by the updated RDP client is considered invalid for delegation.

Rolling back the update does NOT fix the problem! It seems that KB5072033 makes a persistent and non-reverting change to a core component of the OS.

Same problem. Could someone please urgently look into it ... ?