CMMC 2.0 et NIST SP 800-171 : ce que la cryptographie signifie réellement pour les fournisseurs de services d’ Software s et de cloud dans la chaîne d’approvisionnement de la défense

Pendant des années, la découverte en interne d’une faille dans votre système de cryptographie relevait d’une simple constatation interne. Dans le cadre de la norme CMMC 2.0, cela peut mettre fin à une candidature avant même qu’elle ne soit examinée. Le statut de certification selon le modèle de maturité en cybersécurité (CMMC) est désormais une condition d’éligibilité à l’attribution d’un marché, et un responsable des marchés publics peut exiger de connaître votre statut actuel avant même d’évaluer une proposition.

Cette évolution a de lourdes conséquences pour les fournisseurs d’ software s et de solutions SaaS. Les informations non classifiées contrôlées (CUI) ne restent pas confinées à l’infrastructure. Elles transitent par les couches applicatives, sont stockées dans vos bases de données et circulent via vos API. Cela étend le champ d’application des contrôles cryptographiques à l’ software elle-même, et non plus uniquement aux serveurs qui la sous-tendent.

Cet article détaille les exigences du CMMC 2.0, explique pourquoi la cryptographie est le domaine qui pose le plus de difficultés aux fournisseurs, et indique comment se préparer à une évaluation afin d'en apporter la preuve.

Situation en août 2026 : les exigences d'auto-évaluation de la phase 1, la clause DFARS 252.204-7012, la notation SPRS et les déclarations annuelles restent en vigueur. La transition vers la certification C3PAO obligatoire prévue pour la phase 2, initialement fixée au 10 novembre 2026, a été suspendue le 13 juillet 2026, de même que les phases ultérieures, dans l’attente d’un examen par le groupe de travail sur la réforme du CMMC. La règle du programme 32 CFR Partie 170 et les clauses DFARS n’ont pas été abrogées.

Qu'est-ce que le CMMC 2.0, et pourquoi a-t-il bouleversé les règles ?

Le CMMC 2.0 est le programme de vérification à plusieurs niveaux du ministère américain de la Défense, fondé sur la norme NIST SP 800-171, révision 2. La révision 3 a été publiée en 2024, mais le règlement du programme intègre la révision 2 par référence ; c'est donc cette dernière qui fait l'objet de l'évaluation. Ce programme transforme les exigences de sécurité, qui relevaient auparavant d'une simple auto-attestation, en une condition vérifiée nécessaire à l'exercice d'une activité. Une mise en œuvre vérifiée est désormais une condition préalable à l’attribution d’un marché, et non plus une simple promesse faite sur papier.

Cette réglementation est contraignante et assortie d’un calendrier. La réglementation finale du DFARS (clause 252.204-7021) est entrée en vigueur le 10 novembre 2025, marquant le début de la phase 1 d’un déploiement en quatre phases sur trois ans qui devait aboutir à une mise en œuvre complète en novembre 2028. Ce calendrier est désormais suspendu au-delà de la phase 1. Cette approche par étapes vise à donner à la base industrielle de défense le temps nécessaire pour obtenir les certifications, mais l’orientation est définitive.

Trois niveaux définissent ce que vous devez prouver :

• Niveau 1 : Protège les informations relatives aux contrats fédéraux (FCI) grâce à une auto-évaluation portant sur 15 pratiques.
• Niveau 2 : protège les informations classifiées (CUI) conformément aux 110 mesures de contrôle de la norme NIST SP 800-171. Deux voies sont possibles : l’auto-évaluation, niveau 2 (Self), et la certification C3PAO, niveau 2 (C3PAO) ; chacune s’inscrit dans un cycle de trois ans avec une confirmation annuelle. La certification devait devenir la norme à la phase 2 ; celle-ci étant suspendue, l’auto-évaluation est pour l’instant la voie à suivre. »
• Niveau 3 : Ajoute 24 exigences renforcées issues de la norme NIST SP 800-172.

L'ampleur du phénomène est considérable. Le ministère américain de la Défense estime que bien plus de 80 000 prestataires et sous-traitants devront obtenir une certification de niveau 2 ou 3. Si vous fournissez des « software » à la chaîne d’approvisionnement de la défense, il y a de fortes chances que cela vous concerne.

Pourquoi la cryptographie est la partie la plus difficile du §3.13

La famille « Protection des systèmes et des communications » (§3.13) est systématiquement l’une des plus difficiles à réussir pour les fournisseurs d’ software . Cela s’explique par une distinction qui peut sembler purement sémantique, mais qui est déterminante pour le résultat final.

Les évaluateurs font la distinction entre un algorithme qui est simplement conforme à la norme FIPS et un module cryptographique ayant fait l'objet d'une validation formelle dans le cadre du programme de validation des modules cryptographiques (CMVP). La conformité signifie que vous avez utilisé un algorithme approuvé. La validation signifie qu'un laboratoire accrédité a testé le module en question et que le CMVP lui a délivré un certificat.

Voici le piège. Un fournisseur qui a développé son propre système de chiffrement à l’aide d’algorithmes approuvés, sans valider le module lui-même, échoue au contrôle. La robustesse de la mise en œuvre ne le sauve pas. « Nous utilisons l’AES-256 » ne constitue pas une preuve de conformité. Le numéro de certificat est le point de départ de la réponse. Quatre conditions doivent être remplies : le certificat doit être actif, et non « historique » (voir plus bas dans l’article) ; la version validée doit correspondre à celle que vous avez déployée ; votre plateforme doit se trouver dans l’environnement opérationnel testé indiqué sur le certificat ; et le module doit effectivement fonctionner en mode certifié FIPS. La compatibilité FIPS fournie par défaut est la raison la plus courante pour laquelle un fournisseur disposant d’un véritable certificat échoue tout de même au contrôle.

Correspondance entre la norme CMMC 2.0 et les contrôles cryptographiques

Il s'agit de la section de référence principale. Les contrôles ci-dessous correspondent aux points sur lesquels les software s et les fournisseurs de services cloud identifient le plus souvent des lacunes ; considérez donc chacun d'entre eux comme un élément pour lequel vous devez fournir des justificatifs.

Cryptographie validée selon la norme FIPS (§3.13.11)

Émettez et gérez des certificats s'appuyant sur des modules cryptographiques validés selon les normes FIPS 140-2 ou 140-3 partout où vous devez garantir la confidentialité des informations classifiées (CUI). La validation porte sur une version spécifique du module fonctionnant en mode approuvé, et non sur l'algorithme lui-même. Ainsi, la simple mention « compatible avec AES-256 » ne prouve rien en soi. En revanche, un numéro de certificat CMVP, lui, en est la preuve.

Établissement et gestion des clés cryptographiques (§3.13.10)

Documentez la manière dont les clés sont générées, distribuées, stockées et détruites au sein de votre périmètre CUI. Cela inclut les clés de la couche applicative hébergées au sein de votre software, et pas seulement les clés gérées par votre équipe chargée de l'infrastructure.

Confidentialité lors de la transmission et au repos (§3.13.8, §3.13.16)

Protégez les informations confidentielles (CUI) en transit grâce à un chiffrement « TLS » (chiffrement de bout en bout) basé sur des certificats. Protégez les informations confidentielles (CUI) au repos à l'aide de clés émises par l'PKI, quel que soit l'endroit où votre « software » les stocke, y compris dans les bases de données, les caches et le stockage d'objets.

Authentification des appareils et des utilisateurs (§ 3.5.1 à § 3.5.4)

Remplacer les mots de passe partagés par une authentification par certificat pour l'accès aux applications et services traitant des informations classifiées (CUI). Utiliser une authentification résistante à la relecture pour l'accès réseau aux comptes privilégiés et non privilégiés.

Confidentialité des sessions d'accès à distance (§3.1.13)

Utilisez des mécanismes cryptographiques pour protéger la confidentialité des sessions d'accès à distance. La position du NIST concernant cette exigence fait directement référence à une cryptographie validée par la norme FIPS ou approuvée par la NSA, ce qui signifie que la section 3.13.11 s'y rapporte également. En pratique, il s'agit d'un VPN à authentification mutuelle et basé sur des certificats, ou d'une solution équivalente, pour l'accès administratif à votre site software hébergé dans le cloud. Inventaire des actifs cryptographiques à des fins de justification de l'évaluation

Tenez à jour un inventaire des algorithmes et bibliothèques cryptographiques intégrés à votre système d'software. Cet inventaire alimente les éléments justificatifs de votre Plan de sécurité du système (SSP) et de votre Plan d'action et de jalons (POA&M) en vue de l'examen par le C3PAO.

Se préparer à l'évaluation : ce sur quoi un C3PAO va réellement s'attarder

Une évaluation de niveau 2 est un exercice basé sur des éléments probants. Les questions ci-dessous reflètent le processus suivi par un évaluateur ; les réponses sont présentées en premier afin que vous puissiez vous noter rapidement.

• Preuves de validation FIPS : Pouvez-vous démontrer que les modules assurant la protection des informations classifiées (CUI), y compris ceux hébergés sur votre propre site software, ont fait l'objet d'une validation formelle ?
• Documentation relative à la gestion des clés : les procédures de génération, de distribution, de stockage et de destruction sont-elles documentées et respectées conformément au § 3.13.10 ?
• Chiffrement des données CUI aux points de passage : les données CUI sont-elles chiffrées au repos et en transit à chaque point de passage, y compris dans les bases de données et les environnements cloud de votre software?
• Preuves d'authentification des appareils et des utilisateurs : existe-t-il des identifiants uniques, basés sur des certificats, en remplacement des mots de passe partagés pour les systèmes traitant des informations classifiées (CUI) ?
• Précision du SSP et du POA&M : le SSP reflète-t-il les contrôles mis en œuvre, les lacunes faisant l'objet d'un suivi dans un plan d'action et un calendrier actualisés ?
• Dossier de preuves prêt pour l'évaluation : vos preuves sont-elles suffisamment à jour pour résister à une évaluation complète de niveau 2 portant sur l'ensemble des 110 critères de contrôle ?

Si l'une de vos réponses est « pas encore », cette lacune doit figurer dès aujourd'hui dans votre POA&M, et non pas être abordée lors de l'évaluation.

La fin de validité de la norme FIPS 140-2 : un sujet que tous les fournisseurs devraient suivre de près

Une échéance mérite particulièrement votre attention dès à présent. Le 21 septembre 2026, les certificats FIPS 140-2 encore en vigueur seront transférés vers la « liste historique » du CMVP, un statut que les agences fédérales ne doivent pas prendre en compte dans leurs nouveaux marchés publics. Le CMVP ayant cessé d’accepter de nouvelles demandes de certification FIPS 140-2 en 2022, cette transition se prépare depuis plusieurs années.

Concrètement, cela se traduit par une question de calendrier. La validation d’un module FIPS 140-3 de remplacement prend entre 18 et 30 mois. Un fournisseur ne disposant pas d’un certificat à jour risque de se voir exclu des nouveaux marchés fédéraux pendant la durée de la validation. Il n’est pas possible d’entamer cette procédure au cours du trimestre précédant une évaluation.

Faites le lien direct avec l'état de préparation au CMMC. Identifiez les modules déployés qui relèvent de la version 140-2 par opposition à la version 140-3, puis élaborez dès maintenant un plan de migration.

Comment Keyfactor vous aider

Keyfactor correspond directement aux contrôles cryptographiques du CMMC mentionnés ci-dessus, ce qui vous permet de produire des preuves plutôt que de devoir les rechercher à la hâte.

• Inventaire des actifs cryptographiques (AgileSec) : identifiez et répertoriez les algorithmes et les bibliothèques intégrés à votre software afin de disposer de preuves conformes aux normes SSP et POA&M.
• PKI validées selon la norme FIPS (EJBCA) : émettre des certificats et gérer les clés via des autorités de certification et des modules HSM s’appuyant sur des modules certifiés FIPS 140-3, conformément au §3.13.11.
• Artéfacts de compilation et de publication signés (SignServer et Signum) : signer les images de conteneurs, les artefacts de compilation et les correctifs déployés dans la zone d’autorisation.
• Bouncy Castle: Un module cryptographique certifié FIPS 140-3 destiné au chiffrement au niveau de la couche application.
• Gestion du cycle de vie des clés (Keyfactor Command) : centraliser la génération, la distribution et la destruction documentées des clés liées à un module validé, conformément au §3.13.10.

La conclusion pour les dirigeants est simple. Le regroupement des certificats, des clés et des opérations de signature au sein d’un système de référence unique permet de produire plus rapidement les éléments de preuve CMMC et d’assurer leur cohérence face à un évaluateur.

Par où commencer ?

Commencez par la visibilité, puis passez au contrôle. Les premières étapes concrètes sont celles-là mêmes qui facilitent toutes les évaluations ultérieures :

1. Bénéficiez d'une visibilité sur les éléments cryptographiques présents dans l'ensemble de votre base de code et de vos produits commercialisés.
2. Évaluer ces actifs au regard des exigences de la norme NIST SP 800-171, révision 2, et de la norme FIPS.
3. Automatisez le cycle de vie des certificats et des clés afin que les justificatifs restent à jour automatiquement.
4. Préparez-vous à l'ère post-quantique dès maintenant, alors que vous êtes déjà en train de moderniser votre cryptographie.

Le CMMC n'est pas un simple obstacle ponctuel. Il récompense les fournisseurs qui considèrent la cryptographie comme une infrastructure gérée, et sanctionne ceux qui la traitent comme un élément secondaire. Demander une démo

Vous avez des questions sur le CMMC 2.0 ? Nous avons les réponses.

Is CMMC 2.0 certification really required to win DoD contracts?
Under the DFARS final rule that took effect on November 10, 2025, CMMC status is a condition of eligibility for award. A contracting officer can require your current status before considering a bid. However, since Phase 2 is currently suspended, third party certification is currently paused pending review.

What is the difference between FIPS compliant and FIPS validated?
FIPS compliant means you used an approved algorithm. FIPS validated means an accredited lab tested a specific cryptographic module and CMVP issued a certificate. CMMC assessors require validation, not just compliance.

Which CMMC level applies to software and cloud vendors handling CUI?
Vendors that handle CUI typically need Level 2, which requires all 110 NIST SP 800-171 controls and is usually verified by a C3PAO every three years. Level 1 covers Federal Contract Information only.

Why is cryptography (§3.13) so hard to pass?
The System and Communications Protection family requires formally validated modules, not homegrown encryption built on approved algorithms. A vendor that validated the algorithm but not the module fails the control regardless of implementation strength.

What happens on September 21, 2026?
Remaining active FIPS 140-2 certificates move to the CMVP Historical List. Because validating a replacement FIPS 140-3 module takes between 18 and 30 months, vendors should identify affected modules and plan migration now.

Does CMMC apply to keys inside my application, not just my infrastructure?
Yes. CUI moves through application layers, so §3.13.10 covers key generation, distribution, storage, and destruction for application-layer keys inside the software itself, not only infrastructure keys.

What evidence will a C3PAO ask for?
Expect requests for FIPS validation certificates, documented key management procedures, proof of encryption at rest and in transit, certificate-based authentication records, and a current SSP with a matching POA&M.

How can Keyfactor help with CMMC readiness?
Keyfactor provides FIPS 140-3 validated PKI, centralized key lifecycle management, cryptographic asset inventory, and signing for build artifacts. Together they let you produce assessment evidence from a single system of record.