KB5066835: KSP vs CSP transition and recommendations for Personal Desktop Client

Executive summary

On October 14, 2025, Microsoft released security update KB5066835, introducing a significant change to how Windows handles cryptographic operations for smart cards. This update enforces the use of the Key Storage Provider (KSP) model over the legacy Cryptographic Service Provider (CSP) model for RSA-based certificates. While this improves security, it also caused compatibility issues for environments relying on CSP-based middleware and applications.

To mitigate this, Microsoft introduced the registry setting DisableCapiOverrideForRSA as a temporary workaround. With the release of Personal Desktop Client 5.20, which is designed for KSP-native operation, this workaround is no longer required.

Background: CSP vs KSP

Cryptographic Service Provider (CSP)

CSP is part of the legacy Windows CryptoAPI (CAPI) model and has historically been used by:

• Smart card middleware

• Certificate-based authentication applications

• Many legacy and 32-bit applications

However, CSP has limitations:

• Older security model

• Less flexible key management

• Not aligned with modern Windows cryptography architecture

Key Storage Provider (KSP)

KSP is part of the Cryptography Next Generation (CNG) framework and represents Microsoft’s modern cryptographic model.

Key benefits include:

• Improved security isolation

• Better support for hardware-backed keys

• Alignment with modern cryptographic standards

Microsoft’s direction

Microsoft is actively transitioning away from CSP in favor of KSP.

The KB5066835 update enforces KSP usage for RSA smart card certificates, effectively removing reliance on legacy CSP paths.

What KB5066835 changed

Security enforcement (October 2025)

The October 2025 cumulative updates (including KB5066835 for Windows 11 and corresponding updates such as KB5066791 for Windows 10) introduced:

• Mandatory use of KSP instead of CSP for RSA smart card certificates

• A security hardening tied to CVE‑2024‑30098

Observed impact

Following the update, many environments experienced:

• Smart cards not recognized as CSP providers

• Failures in certificate-based authentication

• Inability to sign documents

• Errors such as:

  • “Invalid provider type specified”

  • CryptAcquireCertificatePrivateKey error

These issues occurred because applications attempted to access keys via CSP, which was no longer allowed.

Purpose of the change

This change was introduced to:

• Strengthen cryptographic security

• Remove legacy and potentially vulnerable execution paths

• Standardize key access through the modern CNG/KSP model

The DisableCapiOverrideForRSA Registry Key

Purpose

To mitigate compatibility issues, Microsoft introduced a registry setting:

HKLM\SOFTWARE\Microsoft\Cryptography\Calais\DisableCapiOverrideForRSA (DWORD)

This acts as a temporary compatibility switch.

Behavior

Customer usage

Many customers used this registry key:

• Set to 0

• To restore CSP-based behavior and maintain compatibility with legacy middleware or applications

Important considerations

• This key is not a long-term solution

• It is intended as a temporary workaround

• Microsoft has indicated that:

  • The compatibility path will be removed in future updates

  • KSP-only behavior will become mandatory

Using this key prolongs reliance on deprecated cryptographic paths.

Personal Desktop Client 5.20: KSP-only Architecture

Overview

Personal Desktop Client 5.20 introduces a KSP-native architecture for smart card operations.

This aligns fully with:

• Microsoft’s cryptographic direction

• The enforcement introduced in KB5066835

CSP usage scope

CSP is retained only for a limited case:

• Soft tokens

• Used by a small subset of customers

Important clarification:

• This exception does not affect smart card workflows

• Smart card operations are fully KSP-based

Implications

Personal Desktop Client 5.20:

• Does not depend on CSP for smart card operations

• Is fully compatible with enforced KSP environments

• Does not require registry-based compatibility overrides

Recommendations

For customers using Personal Desktop Client 5.20

This ensures:

• Native Windows behavior is used

• No fallback to legacy CSP paths occurs

• Alignment with Microsoft’s security model

Why removal is preferred

Removing the key:

• Uses default Windows behavior

• Avoids unnecessary configuration

• Eliminates dependency on a temporary workaround

When the key may still be needed

The registry key may still be required in environments where:

• Legacy CSP-based middleware is still in use

• Applications depend on CryptoAPI (CAPI)

• Third-party solutions have not migrated to KSP

In such cases:

• Use as a temporary mitigation

• Plan a transition to KSP-compatible solutions

Migration guidance

Identify legacy dependencies

Check for:

• CSP-based middleware

• Legacy smart card applications

• 32-bit applications using CryptoAPI

Migration steps

1. Upgrade to Personal Desktop Client 5.20

2. Remove:

   • DisableCapiOverrideForRSA

3.  Validate:

   • Authentication flows

   • Digital signing, Windows Logon, S/MIME etc.

   • Certificate access

4. Monitor:

   • Application behavior

   • Event logs for legacy usage attempts

Expected outcome

• Stable and secure operation

• Full alignment with KSP-based cryptography

• Reduced risk of future compatibility issues

Key takeaways

• KB5066835 introduces a fundamental shift in Windows cryptography

• CSP is being phased out

• The registry key:

  • Is a temporary workaround

  • Should not be relied upon long term

• With Personal Desktop Client 5.20:

  • You are ready for KSP-only Windows environments

  • Best practice: remove the registry key