We are receiving a high volume of notifications from clients using CryptoCard Graphite family cryptographic cards about issues with using them in many popular market applications that utilise smart cards for generation of electronic signatures, particularly those signatures verified using qualified certificates and deployed within eIDAS-compliant environments.
This concerns many popular public administration systems in Poland, “Płatnik”-type applications and commercial accounting software.
Unfortunately, the root cause of these problems is, as yet, an unidentified change in the operation of essential Windows operating system components/services critical to the use of smart cards.
As part of the Windows 10 and 11 system updates, Microsoft introduced a modification to at least the Certificate Propagation service, which is responsible for the automatic import and registration, in the Windows Certificate Store, of X.509 certificates located on a smart card inserted into a card reader (automatic certificate import upon card insertion).
How to deal with the problem ?
The most elegant workaround (transient) is to toggle the flag in the system registry, which Microsoft introduced precisely to enforce backward compatibility with applications that still depend on the legacy cryptographic service provider interface (CSP) supporting among others electronic signatures.
A temporary workaround is to force the Certificate Propagation Service (CertPropSvc) to register certificates in the Windows Certificate Store with an indication of the legacy Cryptographic Services Interface (CSP) type instead of the KSP interface already introduced as the default interface by Microsoft (as part of the October 2025 Windows Update).
You should:
– run Registry Editor (regedit.exe) as an Administrator,
– find (if there is) or ADD (if it is not present) in such a place like in the picture below, the DisableCapiOverrideForRSA key and give it a value of 0 (zero!) or change it (if it is currently 1) to 0 (zero),
– force restart of the Certificate Propagation service (also with Administrator privileges) or perform a Windows restart,
– remove and re-insert the smart card into the reader (or the USB dongle with smart card inside),
– this time the certificates from the card will be registered in the Certificate Store “correctly” for many problematic applications, i.e. as they were registered before,
– but NOTE (!) this is a temporary workaround and it will stop working in April 2026 according to the information presented by Microsoft, and until then, application manufacturers must switch to other, newer cryptographic services APIs used to implement electronic signatures (KSP).
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais
DisableCapiOverrideForRSA DWORD 0
This will restore the operation of smart cards with older applications (based on CryptoAPI and CSPs), and thanks to the mechanism of binding KSP to CSP, new applications (based on CNG APIs) will also work correctly
Detailed description of the problem
Certificates imported from smart cards are registered in the Certificate Store along with additional information (not displayed when viewing the contents of these Certificate Stores using standard system tools available to you), which includes an indication of the appropriate cryptographic service provider that supports the private key associated with the certificate registered in the Windows Certificate Store. This indication can only lead to one cryptographic service provider, it can alternatively (!) be a “CSP-type” or “KSP-type” provider.
Since the launch of Windows Vista, Microsoft has been trying to popularize a new CryptoAPI standard, i.e. CryptoAPI Next Generation (CNG API), which is supposed to be the successor to the older CryptoAPI that has been present “forever” in Windows systems. This also applies to the term CSP (older standard) or KSP (newer standard).
In practice, most cryptographic smart cards currently used on the market have both programming interfaces (APIs): CSP and KSP, allowing the card to be used with older applications (e.g. generating electronic signatures) based on the Crypto API, and newer applications using the CNG API.
For more than 20 years, the Certificate Propagation service has registered certificates read from a smart card inserted into the reader along with an indication of the appropriate cryptographic service provider, and if both types of cryptographic service providers (CSP and KSP) were registered in the system, Windows would register certificates with an indication of CSP.
Unfortunately, in the Windows Update of October 14, 2025, Microsoft changed this strategy and certificates from cards are registered with an indication of the “more modern” standard of the cryptographic service provider, i.e. KSP.
In principle, Microsoft changed this strategy already in 2024 (as a reaction to certain security vulnerabilities related to the use of CSP APIs), but temporarily set the above-mentioned flag in the registry in a way that de facto causes a continuation of the previous strategy and gives Administrators the opportunity to switch the service provider’s registration in a controlled manner with KSP standards, keeping a close eye on possible problems with the applications utilising cryptography.
As part of the October 14, 2025 Windows Update, Windows switched this flag to the announced and recommended standard for registering certificates imported from smart cards in KSP-type pairing mode.
This has caused massive problems for legacy applications (e.g. Platnik), which are built on the basis of the old CryptoAPI standard and use CSP cryptographic service providers. Such applications, when browsing the Windows Certificate Store, see the certificates imported there, but omit them, because these certificates are currently associated with the KSP cryptographic service provider, i.e. an API standard that these applications do not support (we are talking about older applications built using CryptoAPI).
Microsoft’s decision is somewhat controversial, as the situation of registering certificates in the Certificate Store with an indication of the CSP module, which has existed for 20 years, also worked (!) for new applications based on KSP, thanks to the existence of a special mechanism in the system that allows for logical linking of KSP and CSP modules supporting the same type of keys. Unfortunately, this mechanism works only “one way”: applications based on CryptoAPI Next Generation (CNG API) and using KSP modules can use certificates registered in the Certificate Store with an indication of an older CSP module, but Windows does not have a reverse mechanism for CryptoAPI and older applications receiving a reference to a new type of module (KSP) in the certificate description refuse to use such a registered certificate.
By changing the flag in the system registry in the above-mentioned way, we inform Windows applications and services that when importing a certificate to the Certificate Store, they should register it with an indication of CSP, despite the presence of an alternative (newer) KSP service provider in the system that also supports the same electronic card.
An important piece of information that should urge Software Vendors to release updates for various applications using smart cards to redeem electronic signatures is Microsoft’s information that the above-mentioned key in the registry controlling the decision to select the type of cryptographic services interface for freshly registered certificates (CSP vs KSP) will cease to function in April 2026 and from then on, the strategy of registering certificates in the Certificate Store will be implemented by default with the indication to the KSP interface, if only such an interface is available in the system for a specific electronic card.
Update – February 10, 2026 – As part of the February 10, 2026 KB5077181 patch, Microsoft has changed its strategy again, essentially reverting to the pre-October 2025 state and pushing back the cut-off date for the forced transition of all applications to use the KSP type service provider for electronic cards to February 2027.
Here are the details of the February 10, 2026 change:
- Return to Default CSP Enrollment (CAPI)
Microsoft has de facto withdrawn from enforcing KSP as the default standard in the absence of a key in the registry.
An earlier change (from October 14, 2025) caused the system to “tag” private keys as KSP without additional entries, which spoiled the operation of older applications (e.g. Płatnik, e-signature systems).
- Current state: If the smart card has an available CSP, Windows 11 (build 26100.7840+) again prefers the CSP during automatic certificate propagation, even if the DisableCapiOverrideForRSA key doesn’t exist.
- CryptoCard Graphite, Graphite Plus, and Graphite PRO supports both CSP and KSP, so they work correctly with any PKI application.
- Postponement of the “End of Life” deadline to February 2027
The original timeline assumed that the ability to enforce CSPs (via the registry key) would disappear in April 2026.
Due to the scale of the problems in the administration and finance sectors (especially in Europe), Microsoft has decided:
- Extend support for CSPs for another year, until February 2027tag.
- Change the logic so that the system is “out-of-the-box” compatible with older software by default, instead of forcing administrators to manually edit the registry on thousands of workstations.
- The following logs are currently in force to control support for CSK vs KSP based on the DisableCapiOverrideForRSA key in the registry:
- DisableCapiOverrideForRSA does not exist – registration of the key for use with a CSP is preferred (if the card supports such a service provider)
- DisableCapiOverrideForRSA = 0 – Registration of the key for use with the CSP is preferred (if the card supports such a service provider)
- DisableCapiOverrideForRSA = 1 – registration of the key for use with the KSP service provider is preferred (if the card supports such a service provider)