Windows 11 Remote Desktop Connection Invalid Token

Hello ardavawf,
Microsoft has documented a September 2026 Remote Desktop Services issue, but not this exact “token supplied to the function is invalid” message. The known issue described RDP connection or sign-in failures and other RDS components becoming unresponsive after KB5124008. Microsoft says KB5129195 (build 26200.9457) addresses that RDS issue. The published notes don’t identify Dell laptops or the invalid-token error specifically, so a Dell-specific cause isn’t confirmed.

1. Check both ends of the connection. Run winver on an affected laptop and its target PC, and confirm whether each has KB5129195 or a later cumulative update. If either is behind, install the latest applicable Windows update and restart.
2. If both are already updated and the error continues, narrow down where it occurs: try the same laptop against a different PC, and a different client against the affected PC. Note whether it affects all users or only particular accounts.
3. Collect the exact error and timing, plus relevant entries from Event Viewer under Windows Logs > System and Applications and Services Logs > Microsoft > Windows > TerminalServices around a failed attempt. Avoid changing registry settings or uninstalling updates until the affected endpoint and logs are clearer.

Official notes: KB5124008 and KB5129195.

"The token supplied to the function is invalid" is SEC_E_INVALID_TOKEN, which comes back from the CredSSP/TLS handshake before the session starts. I'd connect from one affected Dell laptop to the same desktop by its IP address and then by its full hostname, because a connection by IP uses NTLM and a connection by name uses Kerberos. If only the hostname connection fails, look at Kerberos on those laptops, and if both fail, check the System log on the laptop and the desktop for Schannel errors (events 36871, 36874, or 36888) at the time of a failed attempt. Until you find it, pause the rollout of KB5124008 and KB5129195 to the machines that haven't received them.

Drafted with AI.

ET Ducky, testing the same desktop by IP address and full hostname is a useful diagnostic. One qualification: SEC_E_INVALID_TOKEN (0x80090308) identifies an invalid SSPI token; the message alone does not establish that TLS, rather than another part of authentication, failed. By default, an IP-address connection generally won’t attempt Kerberos, but a hostname connection can also fall back to NTLM. So a difference between the two tests is a clue, not proof of which protocol was used.
I’d suggest ardavawf:

1. Try both connections from one affected laptop to the same desktop, using the same account, and record the result and time of each attempt.
2. Check the System log on both machines for Schannel events at those times. If none appear, don’t rule out an authentication issue; share any relevant TerminalServices events as well.

I would not recommend pausing both updates across the environment solely on this evidence. Microsoft documents an RDS issue following the September security update and says KB5129195 resolves that documented issue; it does not specifically identify this invalid-token error. If rollout is still in progress, a targeted hold while comparing affected and unaffected machines is more defensible than treating KB5129195 as a confirmed cause.