RSA Product/Service Type: MFA Authentication Agent for Windows
RSA Version/Condition: 2.x
RSA Passwordless Authentication
Microsoft Windows computers joined to Active Directory
Microsoft Remote Desktop
Microsoft Virtual Smart Card

RSA Passwordless authentication succeeds during the initial Remote Desktop connection to a Windows computer.
After the remote Windows session is locked, another RSA Passwordless authentication attempt fails with:

Unsuccessful Authentication

The Microsoft Virtual Smart Card, certificate, TPM (Trusted Platform Module), and Smart Card service may all appear healthy before and after the failure.

This behavior occurs when the Microsoft Virtual Smart Card used by RSA Passwordless is provisioned on the target Windows computer rather than on the RDP client.

Windows limits a remote session’s Smart Card Resource Manager to readers redirected from the RDP client. A Virtual Smart Card provisioned locally on the target computer is not visible from inside the RDP session running on that computer.

The initial RDP connection can succeed because Network Level Authentication occurs on the client side. Windows forwards the resulting credential to the target through CredSSP, so the target computer’s locally provisioned Virtual Smart Card is not required.

Unlocking the established session uses a different authentication path. The unlock is processed inside the remote session. RSA Passwordless must complete a certificate-based smart card operation against the enrolled Virtual Smart Card container, but that target-resident container is not available inside the RDP session.

Unlocking a locked RDP session when the RSA Passwordless Virtual Smart Card resides on the target computer is not a supported topology. This is expected Windows architecture rather than a certificate, TPM, Smart Card service, or RSA credential defect. 

Supported Configurations

Physical Console Access

RSA Passwordless can be used for physical console logon and lock or unlock operations because the locally provisioned Virtual Smart Card is available to the local Windows session.

RDP with a Client-Resident Virtual Smart Card

RDP authentication and in-session operations can be supported when:

• The RDP client computer has its own enrolled Virtual Smart Card.
• Smart card redirection is enabled.
• The RDP file contains:

redirectsmartcards:i:1

In this configuration, the credential resides on the RDP client and Windows redirects it into the remote session.

Unsupported Configuration

The following topology is not supported:

• The RSA Passwordless Virtual Smart Card resides on the target computer.
• A user accesses that target through RDP.
• The user locks the remote Windows session.
• The user attempts to use the target-resident Virtual Smart Card to unlock the same remote session.

There is no target-side registry setting, Group Policy setting, certificate change, or reader configuration that makes the target computer’s locally provisioned Virtual Smart Card visible inside that RDP session. 

Symptoms and Log Findings

The following findings may be observed when investigating this scenario.

Credential Provider Serialization Messages

RSA Credential Provider logs may contain messages similar to:

The SIDCredentialProvider is not the intended handler of the serialization.

pKerbInteractiveUnlockLogon is NULL

SetSerialization = E_UNEXPECTED

These messages occur because the Credential Provider cannot complete the expected smart card credential serialization when the enrolled Virtual Smart Card container is unavailable inside the RDP session.

These messages do not necessarily indicate that the credential, certificate, or Credential Provider registration is damaged. 

Virtual Smart Card Availability Messages

RSA Passwordless logs may report:

VSC reader not available for user

or errors while retrieving the list of smart card readers.

These messages can occur even though certutil -scinfo later shows that the reader and certificate are healthy. The Virtual Smart Card can remain fully operational on the target computer while still being unavailable from inside the remote session.

Smart Card Device Enumeration

Microsoft Smart Card Device Enumeration logs may show the Virtual Smart Card node being created, removed, and recreated within the RDP session.

This activity reflects changes in smart card redirection state. It does not establish that the target computer’s Virtual Smart Card was damaged or permanently removed, and it is not itself the root cause.

Healthy Certificate and TPM Results

The following results are expected and do not contradict this explanation:

• certutil -scinfo detects the Microsoft Virtual Smart Card.
• The same certificate remains present before and after the failed unlock.
• Public-key matching succeeds.
• The Smart Card Logon certificate chain validates.
• Smart Card Logon and Client Authentication EKUs are present.
• The Smart Card service is running.
• TPM is enabled and operational.
• No Kerberos certificate-validation failure is recorded.
• No standard Windows failed-logon event is generated.

These checks validate the health of the target computer’s credential infrastructure. They do not establish that the credential container is visible from inside the RDP session.

Diagnostic Questions

Before opening a support case, or collecting extensive logs, confirm:

Connection Context

• Is the affected operation a physical console logon or unlock?
• Is the affected operation an initial RDP connection?
• Is the affected operation an unlock of an existing RDP session?

Credential Location

• Is the RSA Passwordless Virtual Smart Card provisioned on the RDP client?
• Is it provisioned only on the target computer?
• Does the customer expect the target computer to use its own Virtual Smart Card from inside the RDP session?

Smart Card Redirection

• Is smart card redirection enabled?
• Does the RDP file contain redirectsmartcards:i:1?
• Is the credential that is being redirected enrolled on the RDP client?

The most important troubleshooting question is:

Where does the enrolled Virtual Smart Card reside: on the RDP client or on the target computer?

If the card resides only on the target and the failure occurs while unlocking a locked RDP session, the behavior matches the unsupported topology described in this article.

To resolve this issue, use one of the supported configurations:

Console Access

Use RSA Passwordless while physically accessing the target computer for logon and lock or unlock operations.

Client-Resident Credential

Enroll RSA Passwordless on the RDP client and enable smart card redirection so the client’s credential is available inside the remote session.

Alternative Authentication

If neither supported configuration is compatible with the customer’s workflow, use another permitted authentication method for unlocking the remote session.

What to Do When Health Checks Pass

If all health checks pass, do not change your smart card setup. A successful health check means that your Virtual Smart Card, certificate, and TPM are working correctly. The behavior you're seeing comes from how Windows handles smart cards in a Remote Desktop (RDP) session. It isn't caused by a problem with your smart card configuration.

Because of this, we recommend NOT doing any of the following, since they won't change this behavior:

• Deleting or recreating the Virtual Smart Card
• Reissuing a valid certificate
• Changing certificate trust settings
• Changing the TPM configuration
• Changing Smart Card service settings

Making these changes could also cause new problems in a setup that is working correctly.

Version Note

A later RSA MFA Agent release includes a pre-flight check for this condition. Instead of returning only a generic Credential Provider serialization failure, the agent reports that the smart card is unavailable in the session.

The improved message makes the condition easier to identify. It does not change the Windows architecture or add support for unlocking an RDP session using a Virtual Smart Card that resides on the target computer.