La crypto-agilité est la capacité à changer d'algorithme, de paramètre ou de fournisseur cryptographique sans réécrire l'application et sans interruption de service. C'est le véritable objectif du programme : ML-KEM sera peut-être remplacé ou complété par HQC, et les drafts IETF évoluent encore.
Centraliser la terminaison cryptographique. Plus TLS est terminé à peu d'endroits (reverse proxies, ingress, service mesh), plus la migration est une affaire de configuration.
Externaliser la politique. Les listes d'algorithmes autorisés vivent dans une configuration versionnée (policy as code), pas dans le code.
S'appuyer sur la politique crypto du système. Sur RHEL et dérivés, update-crypto-policies permet d'appliquer une politique cohérente à OpenSSL, GnuTLS, NSS, OpenSSH et Java.
Abstraire les primitives dans le code. Les applications appellent « chiffre ce message pour ce destinataire » ou « signe ce document », jamais RSA/ECB/PKCS1Padding.
Prévoir la place. Champs de base de données, en-têtes, formats de message, tailles de tampons : prévoir des clés et signatures 50 à 70 fois plus grandes.
Identifier l'algorithme dans les données. Tout objet chiffré ou signé stocké doit porter un identifiant d'algorithme et de version de clé, pour permettre la cohabitation et la re-signature.