Les mises à jour de sécurité diffusées par Microsoft le 8 octobre 2025 perturbent l’authentification par carte à puce sur de nombreuses versions de Windows, côté client comme côté serveur. En cause, une modification dans le traitement cryptographique des certificats RSA. L’éditeur ne signale pas de vulnérabilité active, et propose une clé de registre pour restaurer les fonctions, en attendant un correctif.
Le problème est documenté depuis le 14 octobre 2025 sur la page de statut de Windows 11 25H2. Selon Microsoft, la mise à jour de sécurité KB5031354 provoque des erreurs d’authentification dès lors que le certificat de la carte à puce repose sur un fournisseur CSP (Cryptographic Service Provider) classique. Le système exige désormais l’usage d’un fournisseur KSP (Key Storage Provider), une architecture plus récente introduite avec la Cryptography Next Generation (CNG). Cette bascule casse la compatibilité avec certaines applications 32 bits, avec des modules logiciels de signature, et avec des pilotes de cartes à puce encore basés sur CSP.
Les symptômes incluent une impossibilité de s’authentifier à un domaine Active Directory, l’échec de la signature de documents via carte à puce, et des erreurs dans les applications nécessitant une certification logicielle. Le journal des événements système peut afficher une erreur Smart Card (ID 624), indiquant qu’un certificat incompatible a été présenté. Microsoft précise que les versions clientes de Windows 10 et 11, ainsi que les éditions serveur jusqu’à Windows Server 2025, sont potentiellement concernées.
Pas une faille, mais un risque de contournement MFA
Microsoft ne signale pas de vulnérabilité de sécurité active ni de code d’exploitation associé. Toutefois, l’impact fonctionnel est significatif. De nombreux postes configurés pour une authentification forte par carte à puce se retrouvent bloqués ou doivent temporairement repasser à une authentification par mot de passe. Cette situation induit un contournement non planifié des politiques MFA et expose les systèmes à un baisse momentané du niveau de sécurité. Certaines organisations ont dû désactiver des GPO strictes ou restaurer des images systèmes pour maintenir leur activité.
Cette bascule forcée de CSP vers KSP reflète une volonté de durcir la chaîne de confiance cryptographique, mais elle met en difficulté les environnements qui s’appuient encore sur des certificats hérités ou des applications non migrées. Il en résulte un coût de gestion non négligeable pour les DSI et les administrateurs PKI : test de compatibilité, déploiement de contournement via registre, requalification des certificats, voire réécriture de procédures de signature et d’authentification.
La cryptographie Microsoft a déjà causé des pannes majeures
Ce n’est pas la première fois qu’un changement dans les mécanismes d’authentification Microsoft engendre des effets de bord critiques. En mai 2022, une mise à jour cumulative avait causé une panne mondiale des services d’authentification Kerberos, bloquant de nombreux domaines Active Directory. L’éditeur avait dû publier un correctif en urgence. En décembre 2022, un correctif mal maîtrisé sur LSASS avait entraîné des redémarrages en boucle de serveurs Windows Server 2019 et 2022, mobilisant les équipes sécurité et production pendant plusieurs jours.
Plus tôt encore, en 2019, Microsoft avait durci la validation des certificats pour les cartes à puce, rendant impossible l’authentification dans certains environnements non conformes aux nouvelles règles. Enfin, la transition SHA-1 vers SHA-256, entamée en 2017, a provoqué des défaillances en chaîne sur les chaînes PKI d’entreprise mal préparées. Ces précédents illustrent une constante : chaque évolution de la pile cryptographique Windows, même motivée par une meilleure sécurité, engendre des risques élevés pour la compatibilité des systèmes métiers.
Une résolution partielle en attendant un correctif
Microsoft propose une solution temporaire via une clé de registre (DisableCapiOverrideForRSA) à définir dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais. L’éditeur considère le problème comme « résolu » depuis le 20 octobre, mais uniquement par ce contournement manuel. Aucun correctif cumulatif n’intègre pour l’instant un retour en arrière ou une gestion automatique des CSP existants. Il revient donc aux responsables techniques de déployer cette clé sur les postes concernés, et de prévoir une campagne de migration vers des certificats et des fournisseurs compatibles KSP à moyen terme.
Cette situation met en lumière une faiblesse persistante dans la gouvernance des infrastructures à certificats des entreprises. Nombre d’organisations ignorent encore le type de fournisseur associé à leurs certificats, l’âge de leur pile PKI ou la compatibilité de leurs cartes à puce avec les nouvelles normes. À mesure que Microsoft poursuit la modernisation cryptographique de Windows, ces angles morts deviendront autant de points de rupture potentiels. Une cartographie des usages, une migration vers des certificats CNG et une stratégie de test des mises à jour critiques doivent s’imposer comme des priorités pour les DSI.
