Applies To
Win 10 Ent LTSB 2016 Win 10 Ent LTSC 2019 Windows 10 IoT Enterprise LTSC 2021 Windows 10, version 22H2, all editions Windows 11 Home and Pro, version 22H2 Windows 11 Enterprise Multi-Session, version 22H2 Windows 11 Enterprise and Education, version 22H2 Windows 11 IoT Enterprise, version 22H2 Windows 11 SE, version 23H2 Windows 11 Home and Pro, version 23H2 Windows 11 Enterprise and Education, version 23H2 Windows 11 Enterprise Multi-Session, version 23H2 Windows 11 version 24H2, all editions Windows 11 version 25H2, all editions Windows Server 2012 ESU Windows Server 2012 R2 ESU Windows Server 2016 Windows Server 2019 Windows Server 2022 Windows Server 2025

Original publish date: November 21, 2025

KB ID: 5073121

Introduction

The October 14, 2025, Windows updates addressing CVE-2024-30098 revealed issues in applications where the code does not correctly identify which provider is managing the key for certificates propagated from a smart card to the certificate store. This misidentification can cause cryptographic operations to fail in certain scenarios. This document provides guidance for application developers on how to detect the correct handler and resolve these issues.

Summary

When certificates are propagated from a smart card to the Windows certificate store, the propagation process can use either of the following providers:

  • Legacy Cryptographic Service Provider (CSP), which relies on the legacy Cryptographic Application Programming Interface (CAPI)

  • Key Storage Provider (KSP), which relies on Cryptography API: Next Generation (CNG). This was the modern replacement introduced in Windows Vista.

Prior to the fix for CVE-2024-30098, the propagation algorithm used CSP for RSA-based certificates and KSP for all others. This approach was insecure because CAPI does not support modern cryptographic algorithms, limiting security capabilities.

The October 14, 2025, security updates removed this special handling and now KSP is used for all certificates.

Determine the API set to use

Applications that rely on RSA keys being managed by CSP may fail when the key is managed by KSP. To resolve this, applications must detect which provider manages the key and use the corresponding API set (CAPI or CNG).

Important: Do not use the CryptAcquireContextW or the CryptAcquireContextA functions as the API is deprecated. Instead, use the CryptAcquireCertificatePrivateKey function.​​​​​​​

CryptAcquireCertificatePrivateKey function

Calling CryptAcquireCertificatePrivateKey returns a handle (phCryptProvOrNCryptKey) of type HCRYPTPROV_OR_NCRYPT_KEY_HANDLE. This handle can be:

  • CSP handle (HCRYPTPROV): Use CryptoAPI functions like CryptSignHash.

  • CNG handle (NCRYPT_KEY_HANDLE): Use CNG functions like NCryptSignHash.

Note: When calling CryptAcquireCertificatePrivateKey, be sure to include the CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG in the dwFlags parameter.

To determine the handle type, check the pdwKeySpec value:

pdwKeySpec value

Crypto API to use

AT_KEYEXCHANGE or AT_SIGNATURE

CAPI

CERT_NCRYPT_KEY_SPEC

CNG

Workaround

A temporary work around is available for customers that are impacted by the enforcement of this change. A temporary registry key is available to switch the behavior from Enforcement to Audit mode.

Important: Support for this registry key will be removed in the April 2026 updates.

Registry path

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais

Type

REG_DWORD

Value name

DisableCapiOverrideForRSA

Value data

  • 1 = enable the fix

  • 0 or key removed = disable the fix – switch to audit mode

References

Key Storage and Retrieval

CryptAcquireCertificatePrivateKey function (wincrypt.h)

CVE-2024-30098 | Windows Cryptographic Services Security Feature Bypass Vulnerability

.

Need more help?

Want more options?

Explore subscription benefits, browse training courses, learn how to secure your device, and more.