RDP Authentication failure when using certificates

I found the resolution. Please see

https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-24h2#3697msgdesc

Smart card authentication and other certificate operations might intentionally fail after installing Windows Updates released on or after October 14, 2025 (KB5066835) that contain protections for the security vulnerability, CVE-2024-30098. As part of this cryptography improvement, RSA-based smart card certificates are required to use KSP (Key Storage Provider) instead of CSP (Cryptographic Service Provider).

I used the process stated in the "Workaround" section and was able to successfully use certificate authentication again:

Workaround:
If you encounter this issue, you can temporarily resolve it by setting the DisableCapiOverrideForRSA registry key value to 0. This is documented in CVE-2024-30098. Detailed steps to modify the registry key are listed below. Note: This option will be removed in Windows updates, planned for release in April 2026.

Please forward the details in the "Resolution" section to the developers:

Resolution:
For a permanent resolution, developers should update their authenticating app to perform Key Storage Retrieval using Key Storage API documented at Key Storage and Retrieval. Developers should complete this change before Windows updates released in April 2026, at which time the DisableCapiOverrideForRSA workaround listed below is planned to be removed.

Hello

First, I'm glad you found a workaround for the problem, at least for the medium-term. And thank you for posting the details here.

I'm concerned about this, but also feel like I don't fully understand the issue - especially why you would have this problem in RDM but not mstsc. Can you describe your setup a little for me? Are you using an X.509 credential entry to hold the certificate? I'm wondering because you also mentioned using a .cer; which obviously has no private key (so where is the private key coming from in this case?). Are you using a smart card?

It seems like something we need to address before your workaround is removed by Microsoft next year. So I'd appreciate any extra information you can give.

Thanks and kind regards,

Hey guys,

I'd like to add something to this issue as I think I am seeing this exact problem as well.
@ryanadams
Does your certificate have a PIN?
Because mine does. I have a smardcard certificate on a yubikey and I am using a PIN to open RDP connections with it.

I started to see this error that you described. What currently works for is this:
All I had to do was to go into the properties of my smardcard credential in my RDP Managers user vault and remove the PIN from there!
So now, when I double click a connection in RDP Manager the standard Windows login pop up comes up with my yubikey certificate already selected and "all" I have to do is enter my PIN manually.

I am a bit suprised that this maybe comes from these recent Microsoft changes that you posted and that I would have to temper with the registry which apparently is only a temporary fix.
I am surprised because as of right now my certificate on my yubikey still works fine. It works fine when I open an RDP connection manually through mstsc.exe. It is fine when I do it through Remote Desktop Manager. But only if I remove the PIN from being automatically used by the program.

Do you think removing the PIN from your RDP Manager credential would work as well? Without the registry changes?
I am kinda hoping it would as that would point toward what you posted under the "Resolution" section and that maybe all that needs to be done is a change "in the authenticating app" as Microsoft puts it.

BR,
Will

Hello @willenae0

This is the scenario I'm familiar with for certificate-based authentication.

Here's how it works: the RDP ActiveX control (the Microsoft component that provides integrated RDP inside RDM) doesn't accept a certificate for authentication, it only accepts username / password credentials. There is a Microsoft API that we use to workaround this: CredMarshalCredentialW. If you provide it with the certificate thumbprint, it converts it into a "magic" string that can be passed to another API that only accepts text credentials.

The marshaled credential should be passed as the user name string to any API that is currently passed credentials [...] For certificate credentials, the PIN of the certificate should be passed to that API as the password.

That's exactly what we do. So, all we provide is the string-marshalled certificate and (optionally) the smart card PIN to the RDP control; and then the Windows credential provider does what it will with that information.

(Separately - and this might be related to your specific problem - I've noted that this API can behave unexpectedly. We had another case where a user had trouble with it selecting the wrong certificate when a PIN was provided, leading to a similar error message; and it was not something we could get to the bottom of - our involvement here is very "thin")

It's the Windows Credential Provider that talks to cryptographic services in the kernel, so I'm not sure this is related. Because I would expect that component to be unaffected (one would assume it uses the modern KSP); however there's a different piece which is the smart card driver and/or middleware (in your case, the Yubikey mini driver if installed) that might also be affecting things here.

So, there are a lot of moving pieces here of which RDM is only the "middleman". Like I wrote, I'd be interested if @ryanadams can provide more context to their specific scenario. Perhaps it will shed further light.

Please, let me know if something isn't clear or you have further questions

Kind regards

Hello

Just to provide an update; we've had multiple reports of this issue this week and we're investigating it. I've opened a ticket and linked it back to this thread so you can be notified once we have some more information. In the meantime, the registry workaround from the CVE can be used.

Thanks and kind regards,

Hello

A quick update here that we didn't forget about this, we are still investigating.

In the meantime the deadline for the registry workaround has been extended by Microsoft to February 2027. I guess lots of vendors are struggling with this.

Thanks and kind regards,