How to Fix RDP Error 0xC000000D After the October 2026 Windows Update

There’s a special kind of panic when Remote Desktop — the thing that just works, every single day — suddenly refuses to connect. You type your credentials, hit Connect, and instead of your desktop you get a cryptic dialog: error 0xC000000D, “The token that was passed to the function is invalid.”

If that started happening in the last couple of weeks, it’s probably not your network, your firewall, or a typo in your password. Microsoft has confirmed that the September 2026 preview update (KB5124010) and the October 2026 Patch Tuesday update (KB5127648) broke RDP for non-admin users on Windows 11 machines with Administrator Protection switched on. The good news: it’s a known issue with a documented workaround. This guide explains what’s actually happening, how to check whether you’re affected in about a minute, and how to fix RDP error 0xC000000D safely — without permanently trading away the security feature that triggered it.

Table of Contents

What RDP Error 0xC000000D Actually Means

Let’s decode the message first, because “The token that was passed to the function is invalid” sounds like your login token expired — and that’s not what’s going on.

This error fires on the host side (the PC or server you’re connecting to), not on your client. When Administrator Protection is enabled, Windows changes how user tokens are built at logon. The October updates introduced a mismatch in that token-building path for Remote Desktop sessions: the RDP service hands the logon process a token the updated code no longer accepts, and the connection dies before you ever see a desktop. Your credentials are fine. Your network is fine. The handshake itself is what’s broken.

That’s also why this error looks different from the usual RDP failures. Timeouts, “cannot connect to the remote computer,” and credential rejections each point at network, firewall, or account problems — and if you’ve ruled out the October update, our general RDP connection troubleshooting guide covers those usual suspects. Error 0xC000000D is narrower: it means this specific update bug, on this specific configuration. Which brings us to the updates in question.

Which Windows Updates Broke RDP

Two updates are at the center of this, and understanding which one got you matters for the fix:

Update	Released	Type	What it did to RDP
KB5124010	September 22, 2026	Optional preview (non-security)	First introduced the bug — but only for people who install optional previews
KB5127648	October 13, 2026 (Patch Tuesday)	Cumulative security update	Carried the bug to everyone; this is when most people started seeing it

Microsoft’s confirmed scope: Windows 11 versions 24H2, 25H2, 26H1, and 26H2 acting as Remote Desktop hosts, with Administrator Protection enabled, when the connecting user doesn’t have admin rights. All four conditions have to be true. Miss any one of them and you’re looking at a different problem.

A quick word on Administrator Protection, since it’s the co-star of this bug. It’s a UAC-hardening feature Microsoft started rolling out in October 2025: instead of your account quietly holding admin rights, you’re always a standard user, and anything needing elevation asks you to authenticate with Windows Hello (PIN or fingerprint). It’s genuinely good security — which is why it’s now switched on by default in Microsoft’s published security baselines for 24H2 and later. Plenty of organizations adopted those baselines as-is, so the October update effectively flipped the bug on for their whole fleet at once.

One honest caveat on scope: you’ll see reports online about Windows Server 2019/2022/2025 having RDP meltdowns after the September updates too — sessions stuck at “Connecting…”, servers needing hard resets, traced to a deadlock in the RDS teardown routine. Those reports are real, but they’re a related, separate issue. Microsoft’s confirmed 0xC000000D notice covers Windows 11 only. Don’t conflate the two when you’re diagnosing.

Are You Affected? A 60-Second Check

Before touching any settings, run through this checklist on the host machine (the one you’re trying to reach). You need all four to be true:

1. The host runs Windows 11 24H2 or newer. Press Win+R, type winver, hit Enter. If it says 23H2 or Windows 10, this isn’t your bug.
2. KB5124010, KB5127648, or a later cumulative update is installed. Open PowerShell as admin and run:

   Get-HotFix | Where-Object {$_.HotFixID -match "KB5124010|KB5127648"} | Select-Object HotFixID, InstalledOn

   If either shows up — or if your last cumulative update is dated after October 13, 2026 — you’re in the window.
3. Administrator Protection is on. Go to Settings → Accounts → Sign-in options, or check with your IT admin. If your organization uses Microsoft’s security baselines, assume it’s on.
4. The account you’re connecting with is NOT an administrator. This is the cruelest part of the bug: admins connect fine, standard users get 0xC000000D. If you’re unsure which kind of account you have, our guide on creating and managing RDP users explains the difference.

All four true? You’ve found your culprit. Now the fixes — in order of “official” to “pragmatic.”

Fix 1 — Microsoft’s Official Workaround (For IT Admins)

Microsoft’s published workaround is straightforward: temporarily disable Administrator Protection on the affected host through your policy management tool. In practice that means resetting the “User Account Control: Type of Admin Approval Mode” policy via Microsoft Intune or Group Policy.

Here’s the honest part most write-ups skip: this is a real security downgrade, not a harmless toggle. Administrator Protection exists to keep admin rights out of every process’s hands until explicitly approved. Turning it off — even temporarily — reopens the exact attack surface it was closing. Microsoft calls the workaround temporary for a reason, and so should you:

• Apply it only to affected hosts, not fleet-wide “just in case.”
• Document which machines have it disabled and why.
• Plan to re-enable it the day Microsoft ships the permanent fix.

If you’re the security-conscious type (good), our VPS security checklist is worth a skim while you’re in a hardening mindset — the same principles apply to any Windows box you expose to RDP.

Fix 2 — Group Policy Steps, Click by Click

If you manage the host yourself and have admin access to it (via console, your host’s control panel, or another admin account that can still connect), here’s the exact path:

1. On the host, press Win+R, type gpedit.msc, and hit Enter.
2. Navigate to:

   Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

3. Find “User Account Control: Type of Admin Approval Mode” and open it.
4. Change it from the Administrator Protection mode back to the standard approval mode (the pre-Administrator-Protection behavior).
5. Open an elevated Command Prompt and run gpupdate /force, then reboot the host. The reboot matters — the token behavior only changes at startup.
6. Have the affected user try connecting again. Error 0xC000000D should be gone.

Two gotchas worth knowing. First, if your only access to the host was RDP as a non-admin user, you’re locked out of applying this yourself — you’ll need your hosting provider’s console/VNC access, IPMI/iLO, or someone with an admin account. Second, on domain-joined machines, a domain Group Policy may override your local change within minutes; in that case the fix has to come from whoever manages your domain policies (or Intune), not from the local gpedit.

Fix 3 — If It’s Your Own Windows VPS

Running a Windows VPS for yourself — for trading, automation, or just a remote desktop you control? Your playbook is slightly different:

• Check what’s installed first. Use the PowerShell one-liner from the checklist above through your provider’s console access. Knowing whether KB5127648 is actually on the box saves you from “fixing” the wrong thing.
• Apply Fix 2 via console. Every serious VPS provider gives you out-of-band console access (often labeled VNC or emergency console). That’s your way in when RDP itself is broken.
• Don’t forget which accounts are admin. Since only non-admin accounts hit this bug, one pragmatic short-term option is connecting with an admin account while you sort the policy — but don’t live in an admin account day-to-day. If your user setup is fuzzy, revisit it with our new VPS setup checklist.
• Resist the urge to nuke the update. Uninstalling KB5127648 would likely restore RDP — and simultaneously remove October’s security patches. On an internet-facing VPS, that’s a bad trade. The policy workaround keeps you patched and connected.

What Not to Do

When RDP breaks, the internet suggests a lot of things. Most of them won’t help here, and a few will make things worse:

• Don’t uninstall the October security update and sit unpatched. KB5124010 was an optional preview — skipping that one cost you nothing. KB5127648 is a security update. Rolling it back to fix RDP trades a connectivity bug for missing security patches, which on any internet-exposed machine is the worse deal.
• Don’t disable the firewall or NLA “to fix RDP.” This bug has nothing to do with the firewall or Network Level Authentication. Turning those off doesn’t touch the token problem and weakens the box. If you’re fuzzy on what’s actually protecting your RDP, read is RDP safe? before changing security settings out of frustration.
• Don’t reinstall the RDP client or switch clients. mstsc isn’t the problem. Neither is your laptop. The bug lives on the host.
• Don’t assume it’s your ISP or VPN first. If RDP worked on October 12 and broke on October 14, the calendar is telling you the answer — check the four conditions before you spend an hour on the phone with your ISP.

When Will Microsoft Fix This Permanently?

As of October 23, 2026, Microsoft has acknowledged the issue and published the workaround, but no permanent fix has shipped yet — the company says it’s still working on one. That’s worth stating plainly: everything in this guide is the bridge, not the destination.

Practically, that means two things. First, keep the workaround temporary and tracked (Fix 1’s documentation advice). Second, watch the known-issues section of the KB5127648 changelog — that’s where Microsoft will list the resolution when it lands, and it’s the signal to re-enable Administrator Protection on every host where you disabled it. Microsoft has a track record here: similar RDP/RDS breakage in March 2025 got fixed, and the September 2026 Server issues got emergency updates. The fix is a matter of when, not if.

FAQ

Does this affect Windows 10?
No. Microsoft’s confirmed scope is Windows 11 24H2 and newer. Windows 10 doesn’t have Administrator Protection, so this specific bug can’t hit it. If your Windows 10 RDP broke recently, it’s something else — start with the general RDP troubleshooting guide.

I’m connecting with an admin account and still can’t get in. Is this my issue?
No — admin accounts aren’t affected by this bug. Your problem is elsewhere: credentials, network, firewall, or the RDP service itself.

Does this affect my Linux VPS?
Not at all. This is purely a Windows 11 RDP-host issue. Your Linux boxes, SSH sessions, and everything else are untouched.

Will uninstalling KB5127648 fix it?
Probably — but you’ll lose October’s security patches along with the bug. The Group Policy workaround in Fix 2 keeps you patched and connected, which is strictly better on any machine facing the internet.

Is it safe to disable Administrator Protection temporarily?
“Safe” is doing a lot of work in that sentence. It’s safer than sitting unpatched, and Microsoft itself recommends it as the interim fix — but it genuinely lowers the host’s protection while it’s off. Apply it narrowly, document it, and re-enable it when the permanent fix ships.

Where can I follow Microsoft’s official word on this?
Microsoft confirmed the issue publicly — Bleeping Computer’s coverage has the full statement and the workaround details straight from the source.

Conclusion

RDP error 0xC000000D after the October 2026 update is annoying, but it’s one of the good kinds of broken: Microsoft-confirmed, narrowly scoped, and fixable with a documented workaround. If your host is Windows 11 24H2+, has KB5124010 or KB5127648 installed, runs Administrator Protection, and you’re connecting as a non-admin — you’ve found it, and Fix 2 gets you back in within minutes.

The one thing I’d leave you with: treat the workaround as what it is — temporary. Disable Administrator Protection narrowly, write down where you did it, and re-enable it when Microsoft ships the real fix. Your RDP will work either way; the difference is whether your security posture quietly degrades while nobody’s watching. And if your RDP problems don’t match this pattern, the broader RDP troubleshooting guide is your next stop.