Crypto-agilité : la définition du NIST, un modèle de politique de crypto-agilité, les capacités d'une plateforme, des KPI et un modèle de maturité en 5 niveaux.
La crypto-agilité (agilité cryptographique) est la capacité d'une organisation à remplacer et à adapter les algorithmes, les clés et les paramètres cryptographiques de ses protocoles, applications, équipements et infrastructures sans compromettre la sécurité ni interrompre l'exploitation. Concrètement, vous savez où chaque algorithme est utilisé, les applications demandent la cryptographie par politique au lieu de la coder en dur, et changer un algorithme sur l'ensemble du parc devient un changement planifié et mesuré, pas une réécriture de plusieurs années.
L'enjeu métier : toutes les organisations doivent remplacer RSA et la cryptographie à courbes elliptiques par des algorithmes post-quantiques, et le projet de plan de transition du NIST fixe 2035 comme date de fin pour les algorithmes vulnérables au quantique. Intervenir à la main sur des milliers d'applications, de certificats et d'équipements ne permettra pas d'y arriver à temps. Changer d'algorithme en modifiant une politique, si.
Ce guide présente la définition du NIST, les cinq briques de base et trois outils concrets : une trame de politique de crypto-agilité avec des exemples de règles, une liste de contrôle des capacités d'une plateforme, et des KPI accompagnés d'un modèle de maturité en cinq niveaux.
La définition de référence vient du NIST. Son Cybersecurity White Paper 39, Considerations for Achieving Crypto Agility: Strategies and Practices, a été publié pour la première fois en version finale le 19 décembre 2025. La version actuelle, CSWP 39 upd1, intègre des mises à jour au 29 juin 2026 et remplace la publication de décembre 2025. (Le projet de mars 2025 s'intitulait Considerations for Achieving Cryptographic Agility, ce qui explique que les deux formulations circulent.) Son résumé commence ainsi :
« Cryptographic (crypto) agility refers to the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. »
(Traduction : la crypto-agilité désigne les capacités nécessaires pour remplacer et adapter les algorithmes cryptographiques dans les protocoles, applications, logiciels, matériels, micrologiciels et infrastructures tout en préservant la sécurité et la continuité de l'exploitation.)
Notez le pluriel « capabilities » (capacités) : la crypto-agilité couvre l'inventaire, l'architecture, les processus et l'outillage, pas un seul produit. « Replace and adapt » (remplacer et adapter) couvre aussi bien le remplacement de RSA par ML-DSA que la modification de paramètres ou de combinaisons hybrides. Et un changement qui exige une interruption de service, ou qui laisse ouverte une voie de rétrogradation (downgrade), ne satisfait pas l'exigence « preserving security and ongoing operations » (préserver la sécurité et la continuité de l'exploitation).
NIST IR 8547, Transition to Post-Quantum Cryptography Standards, a été publié comme projet public initial le 12 novembre 2024 et figure toujours comme projet sur csrc.nist.gov. Son calendrier proposé pour les signatures numériques vulnérables au quantique (RSA, ECDSA, EdDSA) et pour l'établissement de clés (Diffie-Hellman et MQV sur corps finis et sur courbes elliptiques, RSA) :
| Niveau de sécurité | Statut proposé |
|---|---|
| 112 bits (p. ex. RSA-2048) | Déprécié après 2030, interdit après 2035 |
| 128 bits et plus (p. ex. ECDSA P-256, RSA-3072) | Interdit après 2035 |
Le projet est aligné sur le National Security Memorandum 10, qui fixe 2035 comme année cible principale. Considérez ces dates comme une base de planification, pas comme définitives. Dans tous les cas, neuf ans, c'est court lorsque les algorithmes sont compilés dans les applications et gravés dans le firmware des équipements.
Les données chiffrées aujourd'hui avec un échange de clés RSA ou ECDH peuvent aussi être enregistrées maintenant et déchiffrées plus tard : voir store now, decrypt later.
Les implémentations PQC recevront des correctifs, des paramètres pourront évoluer, et les combinaisons hybrides finiront par céder la place au PQC seul. La crypto-agilité est ce qui fait du prochain changement une routine plutôt qu'une crise.
Les régulateurs demandent une cryptographie gouvernée et vérifiable plutôt qu'un algorithme précis :
Le fil conducteur : un auditeur demandera comment vous savez quelle cryptographie vous utilisez, qui décide de ce qui est autorisé, et à quelle vitesse vous pouvez la changer. Ces trois questions, c'est la crypto-agilité.
On ne peut pas remplacer ce qu'on ne trouve pas. L'inventaire recense chaque certificat, clé, algorithme, bibliothèque et point de terminaison, son propriétaire et les données qu'il protège ; sous forme lisible par machine, c'est une nomenclature cryptographique, ou CBOM (cryptography bill of materials ; voir notre guide CBOM). Il doit être actualisé en continu, pas constitué une seule fois.
C'est le cœur de l'architecture. Si une application appelle directement RSA_sign(), chaque changement d'algorithme implique une modification du code, une recompilation et un redéploiement. Si elle demande à un service de « signer cet enregistrement client » et que l'algorithme provient d'une politique centrale, le changement se fait à un seul endroit. L'abstraction peut être une API de service cryptographique, une interface KMS ou HSM (PKCS#11, KMIP), une passerelle TLS, ou une autorité de certification qui émet le nouvel algorithme au renouvellement.
Une politique écrite et versionnée indique quels algorithmes sont approuvés pour quelles classes de données et quelles finalités, quelle est la posture hybride, ce qui déclenche une dépréciation et à quelle fréquence les clés doivent être renouvelées. La politique est ce que lit l'auditeur. Dans un parc agile, c'est aussi ce qu'exécute la couche d'abstraction.
L'émission et le renouvellement des certificats (ACME, EST, SCEP, CMP), la rotation des clés, le déploiement et les tickets de remédiation doivent fonctionner sans étape manuelle. Le travail manuel ne passe pas à l'échelle d'une migration.
Des clés post-quantiques plus volumineuses, des clients qui ne comprennent pas ML-DSA et des équipements intermédiaires (middleboxes) qui rejettent les handshakes volumineux : tout cela provoque des pannes. La simulation, le déploiement progressif et le retour arrière font partie de l'agilité, ce ne sont pas des options.
Une politique de crypto-agilité est le document de gouvernance qui définit quelle cryptographie est autorisée, à qui elle appartient, et comment et à quelle vitesse elle évolue. Utilisez la trame ci-dessous comme point de départ. Les exemples de règles sont illustratifs ; fixez les valeurs selon votre appétence au risque, vos régulateurs et le support de vos fournisseurs.
| Section | Exemple de règle (adaptez les valeurs à votre contexte) |
|---|---|
| Algorithmes approuvés | Les nouvelles signatures utilisent ML-DSA-65 ou un composite hybride ML-DSA-65 + ECDSA P-256 ; le nouvel établissement de clés utilise ML-KEM en hybride avec un groupe classique lorsque le protocole le permet ; le chiffrement symétrique utilise AES-256. |
| Posture hybride | Les données dont la confidentialité doit être assurée au-delà de 2035 (données personnelles de clients, contrats de longue durée) sont par défaut en hybrid ; les systèmes internes dont vous maîtrisez les deux extrémités peuvent passer en pqc_only ; les interfaces historiques ne restent en classical que sous une exception enregistrée. |
| Interdit | Aucune nouvelle clé RSA ou ECC d'un niveau de sécurité inférieur à 112 bits ; aucune signature SHA-1 ; ni 3DES ni RC4. |
| Déclencheurs de dépréciation | La dépréciation commence lorsque le NIST, le BSI ou une autorité nationale déprécie un algorithme, qu'une attaque pratique est publiée ou que le support fournisseur prend fin ; une date de fin est fixée dans les 30 jours et toute nouvelle utilisation cesse immédiatement. |
| SLA de rotation | Certificats TLS renouvelés automatiquement avant expiration ; clés de chiffrement des données renouvelées au moins une fois par an ; une clé suspectée compromise est révoquée et remplacée sous 24 heures. |
| Responsabilité | Chaque clé et chaque certificat ont un propriétaire nommé et une application associée dans l'inventaire ; les actifs sans propriétaire sont signalés sous 7 jours. |
| Abstraction | Les nouvelles applications doivent demander la cryptographie via le service cryptographique ou l'interface KMS approuvés ; l'utilisation directe d'un algorithme dans le code requiert une exception. |
| Exceptions et revue | Les exceptions durent au maximum 12 mois, sont approuvées par le comité de revue cryptographique et enregistrées dans l'inventaire ; la politique est revue chaque année et à chaque déclencheur de dépréciation. |
Une plateforme de crypto-agilité transforme la politique en contrôles opérationnels : elle trouve la cryptographie, décide de ce qui est autorisé, l'applique au moyen d'une couche d'abstraction et en apporte la preuve aux auditeurs. Évaluez les capacités, pas les étiquettes.
| Capacité | Ce qu'il faut vérifier | Pourquoi c'est important |
|---|---|---|
| Découverte | Certificats, clés et keystores sur les hôtes ; inventaires des KMS cloud ; points de terminaison TLS ; détection de l'algorithme et de la taille de clé | Un inventaire que vous n'avez pas à construire à la main |
| Évaluation du risque | Risque quantique et classique par actif ; score de préparation agrégé | Permet de prioriser au lieu de tout migrer d'un coup |
| Politique centrale | Algorithmes résolus à partir d'une politique par classe de données et finalité, avec gestion des versions | Un seul endroit à modifier ; un seul document à auditer |
| Support PQC et hybride | ML-KEM, ML-DSA, SLH-DSA, composites hybrides ; postures classique, hybride et PQC seul | Le changement d'algorithme auquel vous vous préparez réellement |
| Abstraction pour les applications | API ou SDK où le code déclare une intention plutôt qu'un algorithme | Changements d'algorithme sans modification du code |
| Indépendance vis-à-vis du backend | PKCS#11 et KMIP ; HSM, KMS cloud, coffres open source | Évite de remplacer une dépendance par une autre |
| Automatisation des certificats | ACME, EST, SCEP, CMP ; autorités de certification PQC et hybrides ; connecteurs de déploiement | La plupart des changements d'algorithme atteignent les serveurs via les certificats |
| Simulation | « Qu'est-ce qui casse si nous modifions cette politique ? » avant le déploiement | Préserve la continuité de l'exploitation, comme l'exige la définition du NIST |
| Workflow de remédiation | Tickets ou pull requests adressés aux propriétaires ; intégration ITSM ; approbation humaine | Transforme les constats en changements |
| Piste d'audit | Journal infalsifiable des modifications de politique et des opérations sur les clés | Montre ce qui a changé, quand et qui l'a approuvé |
Une démonstration qui ne couvre que la découverte présente un outil d'inventaire ; une démonstration qui ne couvre que le stockage des clés présente un KMS. Une plateforme de crypto-agilité boucle la boucle, de la découverte jusqu'au changement appliqué.
Les KPI ci-dessous sont des indicateurs recommandés pour votre propre programme, pas des références sectorielles. Établissez une base de référence maintenant et suivez la tendance chaque trimestre.
| KPI | Définition | Comment le mesurer | Sens souhaité |
|---|---|---|---|
| Délai de remplacement d'un algorithme sur l'ensemble du parc | Temps écoulé entre une décision de dépréciation et la suppression de la dernière utilisation en production | Faire un exercice sur un algorithme ou une classe de données et noter les dates de début et de fin | Plus bas, c'est mieux ; c'est l'indicateur principal |
| % d'actifs inventoriés | Actifs cryptographiques découverts avec un enregistrement d'inventaire complet / total estimé | Comparer la couverture de la découverte (hôtes, comptes cloud, points de terminaison) avec la CMDB | Plus haut ; visez une couverture complète de la production |
| % de clés et de certificats ayant un propriétaire | Actifs avec un propriétaire nommé et une application / tous les actifs inventoriés | Requête sur l'inventaire | Plus haut ; les clés orphelines bloquent la migration |
| % de services derrière une couche d'abstraction | Services qui obtiennent leurs algorithmes d'une politique (API cryptographique, KMS, passerelle) / tous les services utilisant la cryptographie | Revue d'architecture et analyse du code | Plus haut ; l'indicateur avancé de la vitesse future |
| Délai moyen de rotation | Temps moyen pour renouveler une clé ou réémettre un certificat une fois la rotation requise | Horodatages des tickets ou de l'automatisation | Plus bas |
Le premier KPI répond à la question du conseil d'administration : « si nous devions remplacer cet algorithme demain, combien de temps cela prendrait-il ? » Les autres sont des leviers sur ce chiffre.
Utilisez-le pour fixer un niveau actuel et un niveau cible par unité opérationnelle ; la plupart des organisations sont hétérogènes, par exemple au niveau 3 pour les certificats TLS et au niveau 1 pour la signature applicative.
| Niveau | Nom | Inventaire | Architecture | Politique et gouvernance | Capacité de changement |
|---|---|---|---|---|---|
| 1 | Ad hoc | Aucun, ou tableurs partiels | Algorithmes codés en dur dans les applications et les équipements | Aucune politique cryptographique, ou une politique obsolète | Les changements d'algorithme sont des projets sur mesure qui se comptent en années |
| 2 | Conscient | Scan de découverte ponctuel ; lacunes connues | Certains certificats automatisés ; la plupart du code reste codé en dur | Politique écrite listant les algorithmes approuvés | Les changements sont planifiés système par système ; propriétaires souvent inconnus |
| 3 | Défini | Découverte continue ; CBOM pour les systèmes critiques | Les nouvelles applications utilisent un service cryptographique ou un KMS ; ACME/EST pour les certificats | Politique avec déclencheurs de dépréciation, SLA de rotation et processus d'exception | Feuille de route de migration datée ; KPI de référence établis |
| 4 | Géré | CBOM pour l'ensemble du parc, avec propriétaires et classes de données | La plupart des services derrière une abstraction ; PQC et hybride disponibles en production | Politique appliquée par l'outillage ; correspondance réglementaire ; revues régulières | Changements de politique simulés et déployés par étapes ; délai de remplacement mesuré |
| 5 | Agile | Inventaire en temps réel avec alertes de dérive | Algorithmes résolus à l'exécution à partir de la politique ; indépendance vis-à-vis du backend | Politique en tant que code, versionnée et auditée | Un changement d'algorithme est une modification de politique revue, sans modification du code ; la remédiation est automatisée avec approbation humaine |
Passer du niveau 2 au niveau 3 relève surtout des processus et de l'inventaire. Passer du niveau 3 au niveau 5 relève surtout de l'architecture : sortir les algorithmes du code applicatif.
L'approche de DuoKey correspond aux briques de base décrites ci-dessus. Les éléments suivants proviennent de la documentation produit de DuoKey.
La gestion de la posture cryptographique de DuoKey fonctionne en boucle continue : découvrir → évaluer → simuler → remédier. La découverte couvre les fichiers de certificats et de clés, les keystores (y compris le magasin de certificats Windows et le TPM), les inventaires des KMS AWS, Azure et Google Cloud, les domaines TLS et les coffres gérés par Cockpit. Les constats reçoivent un score de risque P1-P4, chaque scan un Quantum Readiness Score (0-100), et le résultat est un CBOM vivant avec alertes de dérive. Les rapports de simulation montrent l'effet d'un changement avant qu'il soit effectué ; les pull requests de remédiation sont rédigées par un agent et approuvées par un humain, avec synchronisation ServiceNow et correspondance avec DORA, NIS2, FINMA 05/2026, NIST IR 8547 et CNSA 2.0. Le Quantum Readiness Score gratuit constitue un point de départ qui ne nécessite aucun accès aux systèmes internes.
Le Crypto Agility Plane (CAP) est la couche d'abstraction de DuoKey. Les développeurs déclarent **ce qu'**ils protègent et pourquoi, par exemple une classe de données PII avec une finalité de signature, et non l'algorithme à utiliser. Une politique centrale propre au tenant résout à l'exécution l'algorithme, la posture post-quantique, la référence de clé et le backend :
| Le développeur déclare | Posture de la politique | Algorithme résolu (exemple) |
|---|---|---|
| PII + signature | hybrid | hybrid-ml-dsa65-ecdsa-p256 |
| PII + signature | pqc_only | ml-dsa65 |
| PII + signature | classical | algorithme classique défini par la politique |
Les trois postures sont classical, hybrid et pqc_only, avec le post-quantique hybride (ML-KEM, ML-DSA) disponible d'emblée. Passer au PQC seul est une modification de politique : le code applicatif ne change pas, et déprécier un algorithme de chiffrement ne nécessite aucune recompilation. C'est la colonne architecture du niveau 5 du modèle de maturité, pour les services qui utilisent CAP.
CAP est disponible dès aujourd'hui sur DuoKey Cockpit via une API REST et des clients de référence pour Java/Spring Boot et .NET/EF Core, ainsi qu'un plan de contrôle IA/MCP. Des SDK packagés et des annotations telles que @Protect figurent sur la feuille de route. CAP ne détient aucun matériel de clé.
DuoKey Cockpit offre une console et une API uniques au-dessus de backends logiciels, MPC, HSM et KMS cloud. Grâce à PKCS#11 et KMIP, CAP fonctionne avec les HSM Securosys, Azure Key Vault, AWS KMS, Google Cloud KMS, HashiCorp Vault et OpenBao. Avec le MPC, les clés sont fractionnées de sorte qu'aucun hôte ne détient jamais une clé complète. Cockpit tient un journal d'audit chaîné cryptographiquement, avec RBAC, ABAC et isolation des tenants.
La gestion des certificats de DuoKey émet des certificats RSA, EC, ML-DSA (FIPS 204), SLH-DSA (FIPS 205) et composites hybrides ML-DSA-65 + ECDSA-P256 depuis des autorités de certification signées par un coffre, via ACME, EST, SCEP et CMP. La documentation de DuoKey recommande le PQC lorsque vous maîtrisez les deux extrémités, et le composite hybride lorsque vous devez interopérer avec des parties de confiance classiques, car tous les clients ne comprennent pas encore ML-DSA ou SLH-DSA.
Pour les agents IA qui demandent des clés et signent de manière autonome, voir la crypto-agilité agentique.
Q: Qu'est-ce que la crypto-agilité ?
La crypto-agilité est la capacité à remplacer et à adapter les algorithmes cryptographiques dans les protocoles, applications, logiciels, matériels, micrologiciels et infrastructures tout en préservant la sécurité et la continuité de l'exploitation. C'est la définition du NIST dans CSWP 39. En pratique, elle repose sur un inventaire, une couche d'abstraction, une politique, l'automatisation et les tests.
Q: Qu'est-ce qu'une politique de crypto-agilité ?
C'est le document de gouvernance qui indique quels algorithmes sont approuvés pour quelles classes de données et finalités, la posture post-quantique et hybride, ce qui déclenche une dépréciation, les SLA de rotation, la responsabilité des clés et des certificats, et comment les exceptions sont approuvées et expirent. Dans un parc agile, cette même politique est aussi exécutée par l'outillage, et pas seulement lue par les auditeurs.
Q: Qu'est-ce qu'une plateforme de crypto-agilité ?
C'est l'outillage qui découvre les actifs cryptographiques, évalue leur risque, résout les algorithmes à partir d'une politique centrale au moyen d'une couche d'abstraction, automatise les changements de certificats et de clés, simule les changements avant leur déploiement et conserve une piste d'audit. Un produit qui ne couvre que la découverte ou que le stockage des clés traite une partie du problème, pas la boucle complète.
Q: Comment mesure-t-on la crypto-agilité ?
L'indicateur principal est le délai de remplacement d'un algorithme sur l'ensemble du parc, de la décision à la suppression de la dernière utilisation en production. Les KPI complémentaires sont le pourcentage d'actifs inventoriés, le pourcentage de clés et de certificats ayant un propriétaire, le pourcentage de services derrière une couche d'abstraction et le délai moyen de rotation.
Q: NIS2 exige-t-elle la crypto-agilité ?
Pas sous ce nom, et pas pour toutes les entités. La directive NIS2 exige des politiques et des procédures relatives à l'utilisation de la cryptographie. Pour les types d'entités spécifiques couverts par le règlement d'exécution (UE) 2024/2690, l'annexe ajoute une section dédiée à la cryptographie avec une politique documentée et une revue périodique, ce qui exige en pratique la capacité de changer d'algorithme. Les autres entités doivent vérifier leur transposition nationale. Les détails figurent dans notre article sur la crypto-agilité NIS2.
Q: Quand faut-il remplacer RSA et ECC ?
Le projet de plan de transition du NIST (IR 8547, projet public initial, novembre 2024) propose de déprécier après 2030 les algorithmes vulnérables au quantique d'un niveau de sécurité de 112 bits, comme RSA-2048, et d'interdire après 2035 tous les algorithmes de signature et d'établissement de clés vulnérables au quantique. Les régulateurs sectoriels peuvent fixer des jalons plus précoces ; voir notre guide de feuille de route de migration PQC.
Q: La cryptographie hybride fait-elle partie de la crypto-agilité ?
Oui. Une posture hybride combine un algorithme classique et un algorithme post-quantique, ce qui ajoute la résistance au quantique tout en restant interopérable avec les systèmes qui ne prennent pas encore en charge le PQC. Un parc agile fait passer une classe de données de classique à hybride puis à PQC seul en modifiant sa politique.
La crypto-agilité est une capacité mesurable : la vitesse à laquelle vous pouvez changer de cryptographie sans rien casser. L'échéance post-quantique lui donne une date, et les régulateurs en font une question d'audit. Commencez par sortir les algorithmes du code pour les placer dans la politique.
Pour savoir où vous en êtes aujourd'hui, commencez par le Quantum Readiness Score gratuit, ou parlez à DuoKey de la gestion de la posture cryptographique.
Écrit par
DuoKey Team
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
