Comment les versions 4.0 et 4.0.1 de la norme PCI DSS redéfinissent les règles relatives au chiffrement des données des titulaires de carte et à la gestion des clés

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.

What does PCI DSS require for protecting stored cardholder data?
Stored cardholder data must be rendered unreadable using strong cryptography, tokenization, or truncation. PCI DSS expects file, column, or field level encryption with independent key management layered on top of full disk encryption, not full disk encryption alone. That separation keeps a compromised host from automatically exposing the data it holds.

When did the future-dated PCI DSS v4.0.1 requirements become mandatory?
They became mandatory on March 31, 2025. The 51 requirements that were treated as best practice under v4.0 are now scored in every assessment, so the transition window has closed.

What does PCI DSS Requirement 12.3.3 cover?
Requirement 12.3.3 calls for a documented inventory of the cryptographic cipher suites and protocols in use. That inventory must be reviewed on a defined cadence of at least once every 12 months to identify deprecated or weakening algorithms before they become a vulnerability.

Does PCI DSS require multi-factor authentication for cardholder data?
Yes. PCI DSS v4.0.1 mandates multi-factor authentication for all access to the cardholder data environment, including remote and third-party vendor access. Certificate-based, phishing-resistant methods provide the strongest assurance.

What encryption is required for cardholder data in transit?
Cardholder data sent across open, public networks must use strong cryptography, meaning TLS 1.2 or higher. Primary account numbers must never be sent unprotected through end-user messaging technologies such as email or chat.

What key management controls does PCI DSS expect?
PCI DSS requires documented procedures covering key generation, distribution, storage, rotation, and retirement. Manual key operations must use dual control and split knowledge so no single person can compromise a key.

Is PCI DSS a law?
No. PCI DSS is a contractual standard rather than a statute, but non-compliance carries real commercial consequences, including fines from acquiring banks, higher per-transaction fees, and potential loss of the ability to accept card payments.

How should PCI DSS teams prepare for post-quantum cryptography?
Start with the cryptographic inventory that Requirements 4.2.1.1 and 12.3.3 already demand, then assess those algorithms against NIST’s published deprecation timelines. Because long-lived transaction data can be harvested now and decrypted later, planning the migration early protects data whose sensitivity outlasts today’s algorithms.