Le compte à rebours est terminé, tout comme la période de grâce. La norme PCI DSS v4.0.1 a été publiée en juin 2024 en tant que version de maintenance de la v4.0 (mars 2022), qui comportait 64 exigences nouvelles ou mises à jour, dont 51 étaient assorties d’une date d’entrée en vigueur différée. Ces 51 exigences sont devenues obligatoires le 31 mars 2025.
Cette échéance a fait passer la cryptographie PCI DSS du stade de simple objectif à celui d’exigence opérationnelle concrète. Pour les commerçants, les prestataires de services et les évaluateurs de sécurité qualifiés (QSA) chargés de les évaluer, le chiffrement et la gestion des clés sont désormais au cœur de toutes les discussions relatives aux données des titulaires de cartes. Si vos contrôles ont été mis en place selon l’ancienne norme de référence, cet écart constitue déjà un risque de constat d’audit imminent.
Ce guide présente les mesures de sécurité cryptographiques qui régissent les données des titulaires de carte dans la version 4.0.1, les éléments vérifiés par les auditeurs, ainsi que la manière de mettre en place un programme permettant de répondre à cette exigence ainsi qu’à la suivante.
Pourquoi la cryptographie est devenue un élément central de la norme PCI DSS
La norme PCI DSS est une norme contractuelle, et non une loi. Vous vous y engagez par l'intermédiaire de votre banque acquéreuse et des réseaux de cartes bancaires ; son application relève donc du domaine commercial plutôt que légal. Tout manquement à cette norme peut entraîner des amendes de la part des acquéreurs, une augmentation des frais par transaction et, dans le pire des cas, la perte de votre droit d'accepter les cartes bancaires.
La cryptographie joue un rôle prépondérant dans ce domaine, car c’est elle qui permet de protéger les données des titulaires de cartes, quel que soit l’endroit où elles sont stockées ou leur parcours. La mise à jour v4.0 a relevé la barre, tandis que la version v4.0.1 a clarifié la formulation concernant le chiffrement, la gestion des clés, l’authentification et la visibilité cryptographique. C’est pourquoi tant d’exigences désormais obligatoires portent sur ces domaines.
La définition du périmètre est souvent le premier écueil pour les organisations. Si vous vous trompez en identifiant les systèmes qui stockent, traitent ou transmettent des données de compte, toutes les mesures de sécurité cryptographiques en aval hériteront de cette erreur. Une définition correcte du périmètre constitue le fondement sur lequel repose tout le reste.
Les exigences relatives à la cryptographie dans le cadre de la norme PCI DSS
Six domaines de contrôle interdépendants définissent les modalités de protection des données des titulaires de cartes prévues par les versions 4.0 et 4.0.1. Chacun d’entre eux est autonome, et ensemble, ils constituent la colonne vertébrale d’un programme défendable. Voici ce qu’exige chacun d’entre eux et pourquoi cela est important.
Protection des données de compte stockées (Exigences 3.5 à 3.6)
Les données des titulaires de cartes stockées doivent être rendues illisibles à l'aide d'une cryptographie forte, d'une tokenisation ou d'une troncature. Le stockage d'un numéro de compte principal (PAN) en clair n'est pas envisageable.
Le chiffrement intégral du disque ne suffit pas à lui seul dans de nombreux environnements. La meilleure approche consiste à superposer au chiffrement du disque un chiffrement au niveau des fichiers, des colonnes ou des champs, la gestion des clés étant maintenue indépendante des contrôles d’accès propres au système d’exploitation. Cette séparation garantit qu’un hôte compromis n’expose pas automatiquement les données qu’il contient.
Gestion des clés cryptographiques tout au long de leur cycle de vie (exigences 3.6 à 3.7)
La sécurité du chiffrement dépend entièrement de la robustesse des clés qui le sous-tendent ; c'est pourquoi la norme PCI DSS exige la mise en place de procédures documentées couvrant l'ensemble du cycle de vie des clés : génération, distribution, stockage, rotation et retrait. Chaque étape doit faire l'objet d'un processus défini et reproductible.
Pour les opérations manuelles liées aux clés, la norme exige un double contrôle et une répartition des connaissances. Aucune personne ne doit être en mesure, à elle seule, de reconstituer une clé ou d'en faire un usage abusif. Il s'agit là d'un des aspects que les évaluateurs examinent avec le plus d'attention ; la documentation doit donc correspondre à ce qui se passe réellement dans la pratique.
Chiffrement des données des titulaires de carte en cours de transmission (exigences 4.1 à 4.2)
Les données de cartes bancaires transitant par des réseaux publics ou ouverts doivent être protégées par un système de cryptographie robuste, ce qui signifie que les algorithmes et la force des clés doivent répondre à certaines exigences minimales (la taille minimale des clés étant fixée à 112 bits). Par exemple, la norme « TLS 1.2 » constitue désormais le seuil minimal attendu par les auditeurs. Cette mise à jour vise précisément à éliminer les anciens protocoles et les configurations peu sécurisées.
Il existe une règle connexe qu'on a tendance à négliger : le PAN ne doit jamais être transmis sans protection via des canaux de messagerie destinés aux utilisateurs finaux, tels que les e-mails ou les messageries instantanées. Tenir un inventaire des clés et certificats de confiance utilisés pour protéger le PAN pendant son transfert permet de vérifier effectivement le respect de cette mesure, plutôt que de se contenter de le supposer.
Authentification de l'accès à l'environnement de données des titulaires de cartes (Exigences 8.4 à 8.5)
Tout accès à l'environnement de données des titulaires de carte (CDE) nécessite désormais une authentification multifactorielle, la méthode la plus sûre étant l'authentification multifactorielle (MFA) basée sur des certificats et résistante au phishing. Cette mesure s'applique à l'accès à distance et à l'accès des prestataires tiers, et pas uniquement au personnel interne.
L'élargissement du champ d'application de la norme MFA prévu par l'exigence n° 8 constitue l'une des lacunes les plus courantes à l'approche de 2026. De nombreuses organisations ont pris en compte les identifiants administratifs, mais ont négligé les comptes de service, les connexions des fournisseurs ou certains systèmes CDE spécifiques. Il est désormais impératif de combler ces lacunes.
Établissement d'un inventaire des suites de chiffrement cryptographiques (exigences 4.2.1.1 et 12.3.3)
On ne peut pas sécuriser ce que l'on ne voit pas ; c'est pourquoi la version 4.0.1 exige un inventaire des suites de chiffrement et des protocoles utilisés, qui doit être révisé à une fréquence définie d'au moins une fois tous les 12 mois. C'est grâce à cette révision que l'on peut détecter les algorithmes obsolètes ou présentant des failles avant qu'un attaquant ou un évaluateur ne le fasse.
Il s'agit là d'une autre lacune parmi les plus souvent citées pour 2026. Un inventaire cryptographique est simple à définir, mais véritablement difficile à tenir à jour manuellement, en particulier dans les environnements hybrides et multicloud.
Sécurisation des pages de paiement et des scripts (exigences 6.4.3 et 11.6.1)
Les scripts exécutés sur les pages de paiement doivent être autorisés, répertoriés et surveillés afin de détecter toute tentative de falsification. Cela étend le concept d'intégrité du code au navigateur, où les attaques par « skimming » ciblent de plus en plus le processus de paiement.
La solution concrète consiste à associer des scripts signés et autorisés à un système de détection des altérations. Elle applique les règles de signature de code aux flux situés à proximité immédiate des données des titulaires de carte.
Ce que les auditeurs et les évaluateurs demandent réellement
Les questions de préparation à l'audit qui sous-tendent les versions 4.0 et 4.0.1 constituent une liste de contrôle que vous pouvez utiliser dès aujourd'hui pour effectuer une auto-évaluation. Passez-les en revue avant qu'un auditeur ne le fasse :
- Les 51 exigences à échéance future ont-elles toutes été clôturées et justifiées, et pas seulement planifiées ?
- La gestion des clés est-elle documentée de bout en bout, avec un double contrôle et une répartition des connaissances ?
- Le MFA couvre-t-il tous les moyens d'accès au CDE, y compris l'accès à distance et l'accès des fournisseurs ?
- Existe-t-il actuellement un inventaire cryptographique répertoriant les suites de chiffrement, les protocoles, les clés et les certificats ?
- Pouvez-vous fournir la chaîne d'attestations des prestataires de services pour chaque fournisseur concerné ?
- La segmentation et le périmètre ont-ils été validés afin de garantir la validité des limites du CDE ?
- Chaque fréquence définie par l'entité et chaque mesure de contrôle sur mesure s'appuient-elles sur une analyse des risques ciblés documentée et à jour ?
Si une réponse vous semble incertaine, c’est sur celle-là qu’il faut se concentrer en priorité. Les auditeurs se basent sur des éléments concrets pour évaluer les systèmes ; ainsi, les documents qui témoignent de contrôles réels et effectifs ont bien plus de poids que les simples intentions.
Assurer la pérennité des données des cartes bancaires : l'horizon post-quantique
L'inventaire cryptographique que vous établissez dans le cadre de la norme PCI DSS remplit une double fonction. La visibilité exigée par les exigences 4.2.1.1 et 12.3.3 constitue la base permettant d'identifier les algorithmes vulnérables aux attaques quantiques au sein de votre environnement.
Le délai est plus court qu’il n’y paraît. En 2024, le NIST a finalisé les premières normes cryptographiques post-quantiques (FIPS 203, 204, 205, août 2024) et publié un calendrier de transition prévoyant la dépréciation, d’ici 2030, des algorithmes à clé publique largement utilisés tels que RSA et la cryptographie à courbe elliptique, leur interdiction totale étant prévue pour 2035. Les données de paiement conservées pendant une longue durée sont exposées à des attaques de type « collecter maintenant, décrypter plus tard », dans lesquelles un attaquant capture aujourd’hui du trafic chiffré pour le décrypter dès qu’un ordinateur quantique sera disponible.
Les données de transaction à longue durée de vie constituent donc un enjeu actuel, et non plus un enjeu futur. Un inventaire cryptographique bien entretenu devient la nomenclature cryptographique (CBOM) qui sert de base à une migration ordonnée vers la cryptographie post-quantique.
Comment « Keyfactor » prend en charge la cryptographie et la gestion des clés conformes à la norme PCI DSS
Keyfactor correspond directement à chaque domaine de contrôle de la norme PCI DSS, ce qui vous permet de passer d'une exigence à une fonctionnalité sans avoir à combiner plusieurs outils ponctuels.
- Keyfactor AgileSec: identifie et répertorie les suites de chiffrement, les protocoles, les clés et les algorithmes afin de répondre à l'exigence 12.3.3 relative à l'inventaire et à l'évaluation des risques cryptographiques.
- EJBCA: délivre les certificats utilisés pour le chiffrement des données stockées et des transmissions, ainsi que pour l'authentification multifactorielle (MFA) basée sur des certificats pour le CDE.
- SignServer: signe et protège les scripts des pages de paiement, en assurant des contrôles d'intégrité pour les flux liés aux données des titulaires de carte.
- Keyfactor Command: assure une gestion documentée et automatisée du cycle de vie des clés et des certificats, de leur création jusqu'à leur retrait, avec la piste d'audit attendue par les auditeurs.
Derrière ces produits, la « Trust Control Plane » d’ Keyfactor fait office de système de référence unique pour chaque actif cryptographique et chaque identité de machine. Elle fonctionne en boucle continue pour surveiller, analyser, provisionner, orchestrer et gérer les clés et les certificats au sein des infrastructures bancaires centrales, de paiement et d’open banking, de sorte que les justificatifs requis par n’importe quel cadre réglementaire proviennent d’une seule et même source.
Conclusion : un programme, pas un projet
La cryptographie PCI DSS est désormais une capacité opérationnelle, et non plus une simple campagne ponctuelle de mise en conformité. Les 51 exigences à venir sont obligatoires, et les contrôles qui les sous-tendent (chiffrement, gestion des clés, authentification multifactorielle et inventaire cryptographique) ne conservent leur valeur que s’ils sont mis en œuvre de manière continue.
La bonne nouvelle, c’est que cette même base répond également à l’exigence suivante. Un inventaire cryptographique à jour conforme à la version 4.0.1 constitue également le point de départ de votre migration post-quantique. Créez-le une seule fois, gérez-le en continu, et chaque nouvelle exigence deviendra une simple mise à jour plutôt qu’une urgence.
Prêt à faire le point sur votre environnement de données des titulaires de cartes ? Demander une démo Découvrez comment Keyfactor vous aide à recenser, automatiser et gérer la cryptographie nécessaire à la conformité PCI DSS.
Vous avez des questions sur la cryptographie dans le cadre de la norme PCI DSS ? Nous avons les réponses.
Quelles sont les exigences de la norme PCI DSS en matière de protection des données stockées relatives aux titulaires de cartes ?
Les données stockées relatives aux titulaires de cartesdoivent être rendues illisibles à l'aide d'une cryptographie robuste, de la tokenisation ou de la troncature. La norme PCI DSSexige un chiffrement au niveau des fichiers, des colonnes ou des champs, avec une gestion indépendante des clés s'ajoutant au chiffrement complet du disque, et non pas uniquement un chiffrement complet du disque. Cette séparation empêche un hôte compromis d'exposer automatiquement les données qu'il contient.
À quelle date les exigences de la version 4.0.1 de la norme PCI DSS, dont l’entrée en vigueur était prévue ultérieurement, sont-elles devenues obligatoires ?
Elles sont devenues obligatoiresle 31 mars 2025. Les 51 exigences qui étaient considérées comme des bonnes pratiques dans la version 4.0 font désormais l’objet d’une notation lors de chaque évaluation ; la période de transition est donc terminée.
Que couvre l'exigence 12.3.3 de la norme PCI DSS ?
L'exigence 12.3.3 impose la mise en place d'un inventaire documenté des suites de chiffrement et des protocoles cryptographiques utilisés. Cet inventaire doit être révisé à une fréquence définie, au moins une fois tous les 12 mois, afin d'identifier les algorithmes obsolètes ou présentant des failles de sécurité avant qu'ils ne deviennent une vulnérabilité.
La norme PCI DSS exige-t-elle une authentification multifactorielle pour les données des titulaires de carte ?
Oui. La norme PCI DSS v4.0.1 impose une authentification multifactorielle pour tout accès à l'environnement des données des titulaires de carte, y compris les accès à distance et ceux des fournisseurs tiers. Les méthodes basées sur des certificats et résistantes au phishing offrent la garantie la plus solide.
Quel niveau de chiffrement est requis pour les données des titulaires de carte en transit ?
Les données des titulaires de carte transmises sur des réseaux publics ou ouverts doivent être chiffrées à l'aide d'un algorithme puissant, c'est-à-dire selon la norme « TLS » version 1.2 ou supérieure. Les numéros de compte principaux ne doivent en aucun cas être transmis sans protection via des technologies de messagerie destinées aux utilisateurs finaux, telles que les e-mails ou les messageries instantanées.
Quels sont les contrôles clés de gestion exigés par la norme PCI DSS ?
La norme PCI DSSexige des procédures documentées couvrant la génération, la distribution, le stockage, la rotation et la mise hors service des clés. Les opérations manuelles liées aux clés doivent obéir au principe du double contrôle et de la séparation des connaissances, afin qu'aucune personne ne puisse à elle seule compromettre une clé.
La norme PCI DSS est-elle une loi ?
Non. La norme PCI DSS est une norme contractuelle et non une loi, mais son non-respect entraîne des conséquences commerciales réelles, notamment des amendes infligées par les banques acquéreuses, des frais par transaction plus élevés et la perte potentielle de la possibilité d'accepter les paiements par carte.
Comment les équipes PCI DSS doivent-elles se préparer à la cryptographie post-quantique ?
Commencez par dresser l’inventaire cryptographique déjà exigé par les exigences 4.2.1.1 et 12.3.3, puis évaluez ces algorithmes à la lumière des calendriers de dépréciation publiés par le NIST. Étant donné que les données de transaction à longue durée de vie peuvent être collectées aujourd’hui et déchiffrées plus tard, planifier la migration suffisamment tôt permet de protéger les données dont le caractère sensible perdure au-delà de la durée de vie des algorithmes actuels.
