Remote desktop lock after 60 seconds

Hello tom nancy,,

I'm following up to check if the proposed solutions stabilized your RDP reconnection behavior. To briefly recap, the locking loop is caused by a race condition where the host's Certificate Propagation Service (CertPropSvc) polls the smart card during the session handle re-instantiation, triggering a false "Device Removal" event that activates your security policy. The immediate remediation is to set the CertPropSvc startup type to Disabled on the remote servers. If the issue persists despite that service change, the definitive architectural fix is to standardize the use of the /remoteguard switch, which completely decouples the authentication mechanism from the host's hardware removal policies and eliminates the conflict root cause entirely.

If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP

Hi tom nancy,

The most common culprit for this polling instability is the Certificate Propagation Service on the remote server. This service aggressively attempts to read the smart card upon insertion (or session reconnection) to populate the user's certificate store. In 24H2, this polling can conflict with the RDP redirection driver, causing the "Removal" event to fire.

Please perform this on the remote host (server):

Open Services (services.msc) as Administrator.

Locate Certificate Propagation.

Stop the service and set its Startup type to Disabled.

Reconnect via RDP and test the behavior.

Note: Disabling this service does not prevent Smart Card Logon. It only stops the automatic copying of certificates to the user's personal store, which is rarely critical for the logon session itself.

If disabling CertPropSvc does not stabilize the legacy redirection, you have identified the ultimate solution yourself: Remote Guard.

Technically, the "problem" is that Legacy Smart Card Redirection (which sends high-level APDU commands over the network) is becoming deprecated in favor of the Remote Guard model (which processes requests on the client).

Legacy Mode: The server sees a "Virtual Smart Card." If the network hiccups or the driver resets, the card is "Removed." -> Lock triggers.

Remote Guard: The server does not "mount" the card. It asks the client to sign a challenge. There is no "Smart Card" device on the server to be "removed." -> Lock policy is never triggered.

Since your organization has strict security standards, Remote Guard is the superior security choice (it prevents Pass-the-Hash attacks and credential theft). I strongly advise updating your deployment .rdp files or usage procedures to include the /remoteguard switch as the standard for Windows 11 24H2 clients, rather than treating it as a workaround. It is the architectural resolution to the conflict between "Strict Locking Policy" and "RDP Session Handoff."

VP