SaaSFort Une question qui n’apparaissait pas dans les questionnaires de sécurité fournisseur il y a deux ans revient désormais régulièrement, généralement sous l’une de ces formes :
- « Décrivez votre plan de migration vers la cryptographie post-quantique. »
- « Vos points d’entrée publics prennent-ils en charge l’accord de clés hybride ? »
- « Quelle est votre posture d’agilité cryptographique ? »
La plupart des éditeurs y répondent mal, de deux façons. Soit ils disent « nous utilisons TLS 1.3 et AES-256 », ce qui ne répond pas à la question. Soit ils décrivent une feuille de route pluriannuelle sans aucun composant déployé, ce qui se lit comme une esquive.
Ce qui inquiète réellement l’acheteur
La préoccupation est précise et ce n’est pas de la science-fiction. Un adversaire enregistre aujourd’hui du trafic chiffré et le stocke. Les clés de session ont été convenues par Diffie-Hellman sur courbes elliptiques. Le jour où un ordinateur quantique pertinent existera, ces enregistrements seront déchiffrés rétroactivement.
Le risque est donc fonction d’une seule variable que l’acheteur connaît déjà : combien de temps ses données restent sensibles.
Les jetons de session d’un distributeur ne valent plus rien au bout d’une semaine. Les dossiers clients d’une banque, les données d’un hôpital, les pièces d’un cabinet d’avocats et les positions de souscription d’un assureur restent sensibles des décennies. C’est pourquoi la question vient de façon disproportionnée d’acheteurs régulés, et pourquoi elle arrive rattachée à des évaluations DORA et NIS2 plutôt qu’à des achats généralistes.
L’acheteur ne demande pas si vous avez résolu la cryptographie post-quantique. Il demande si les données qu’il s’apprête à vous envoyer sont enregistrées aujourd’hui sous une forme qui sera lisible plus tard.
La réponse qui fonctionne
Il existe un composant déployable, et il tient en une ligne de configuration.
Activez le groupe hybride X25519MLKEM768 sur votre terminaison TLS. Les navigateurs le négocient par défaut depuis Chrome, Firefox et Edge 131. Les clients qui ne le prennent pas en charge retombent sur l’échange de clés classique, sans rupture de compatibilité.
ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;
Une fois actif, votre réponse cesse d’être une feuille de route et devient une observation que l’acheteur peut vérifier lui-même :
openssl s_client -connect votredomaine.fr:443 -groups X25519MLKEM768
Ce basculement compte plus qu’il n’y paraît. Une équipe sécurité qui lit cinquante réponses fournisseur peut vérifier celle-ci en dix secondes, sans vous faire confiance. Les affirmations vérifiables de l’extérieur n’ont pas le même poids que les autres, pour la même raison qu’un rapport de scan externe pèse plus qu’une auto-évaluation.
Structurer la réponse complète
Une réponse complète comporte quatre parties, et seule la première doit être achevée aujourd’hui.
1. Ce qui est déployé. L’accord de clés hybride sur tous les points d’entrée publics, avec le nom du groupe et la date d’activation.
2. Ce qui ne l’est pas, et pourquoi. L’authentification reste classique : votre certificat est signé en RSA ou ECDSA. Dites-le. La justification honnête est qu’une forgerie de signature doit se produire pendant une connexion active, donc il n’existe pas d’équivalent harvest-now pour l’authentification, et les autorités publiques n’émettent pas encore de chaînes post-quantiques. Un cryptographe côté acheteur l’acceptera. Il n’acceptera pas une affirmation de « full post-quantique ».
3. L’agilité cryptographique. Combien de temps vous faudrait-il pour changer d’algorithme ? La preuve concrète ici est l’automatisation des certificats : les équipes en ACME avec des durées de vie courtes renouvellent tout leur parc en quelques semaines. Celles qui renouvellent à la main ne le peuvent pas, et c’est la vraie mesure de l’agilité.
4. L’inventaire. Quels points d’entrée terminent TLS, et qui les contrôle. Un CDN devant votre origine signifie que le groupe hybride doit être activé à deux endroits, et les éditeurs l’activent régulièrement en périphérie pendant que la connexion vers l’origine reste classique.
La nuance régionale
L’ETSI et le cadre EUCC recommandent le déploiement hybride au moins jusqu’en 2028 et considèrent les déploiements purement post-quantiques comme prématurés. Si un acheteur demande pourquoi vous n’utilisez pas ML-KEM seul, c’est la réponse, et c’est la posture recommandée et non un compromis.
Si l’acheteur opère sous contrainte FIPS, notez que ML-KEM est approuvé FIPS mais pas X25519, donc l’hybride strictement conforme est SecP256r1MLKEM768, que les navigateurs ne proposent pas par défaut. C’est une tension réelle, que vous n’avez pas créée, et la nommer démontre que vous maîtrisez le sujet.
Ce qu’il ne faut pas dire
Évitez « quantum-safe » et « à l’épreuve du quantique ». Ce sont des termes marketing, aucun n’est vrai d’un déploiement hybride, et un relecteur technique sanctionnera la réponse.
Évitez de vous engager sur une date de migration des signatures. Cela dépend de l’émission par les autorités de certification, hors de votre contrôle.
Où cela se mappe
- NIS2 article 21(2)(h), cryptographie et chiffrement.
- ISO/IEC 27001:2022 A.8.24, usage de la cryptographie.
- DORA article 9, protection, pour les entités financières et leurs prestataires TIC.
En résumé
La question porte sur la durée de vie des données, pas sur les ordinateurs quantiques.
Une ligne de configuration vous donne aujourd’hui une réponse déployée et vérifiable de l’extérieur. Associez-la à un énoncé honnête de ce qui n’est pas encore couvert, et la réponse sera plus solide qu’une feuille de route deux fois plus longue.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.