PCI DSS 4.0.1 : Nouvelles Exigences Mars 2026 en 2026

La migration de PCI DSS 3.2.1 vers PCI DSS 4.0.1 représente le changement le plus structurant dans la conformité des organismes traitant des paiements par carte depuis plus d'une décennie. Depuis le 31 mars 2025, date à laquelle PCI DSS 3.2.1 a été officiellement retraitée par le PCI Security Standards Council (PCI SSC), toute organisation qui accepte, traite ou transmet des données de cartes bancaires — marchands, prestataires de services de paiement (PSP), acquéreurs, FinTech — doit être intégralement conforme à la version 4.0.1. Cette version, publiée initialement en mars 2022 puis révisée en PCI DSS 4.0.1 en juin 2023 pour corriger des ambiguïtés d'interprétation, introduit 64 nouvelles exigences dont 51 "meilleures pratiques" qui sont devenues obligatoires au 1er avril 2025. Ces nouvelles exigences sont une réponse directe à l'évolution du paysage des menaces : les attaques de type Magecart (injection de scripts malveillants sur les pages de paiement pour intercepter les données de cartes à la saisie) ont compromis des millions de données entre 2018 et 2023, dont celles de British Airways (500 000 clients), Ticketmaster (9,5 millions de clients) et des centaines d'e-commerçants utilisant des plugins Magento ou WooCommerce compromis. L'exigence 6.4.3, directement issue de ces incidents, impose désormais un inventaire et un contrôle d'intégrité rigoureux de tous les scripts JavaScript présents sur les pages de paiement. Comprendre précisément ces nouvelles exigences et savoir les démontrer lors d'un audit par un Qualified Security Assessor (QSA) est la clé d'une conformité efficace et économique pour votre organisation en 2026.

Calendrier de migration PCI DSS 3.2.1 → 4.0.1

Pour éviter toute confusion sur les délais, rappelons les dates clés de la transition :

• Mars 2022 : publication de PCI DSS v4.0 par le PCI SSC — entrée en période de transition parallèle avec la v3.2.1
• Juin 2023 : publication de PCI DSS v4.0.1 (corrections mineures de formulation, clarifications d'interprétation — aucun changement structurel par rapport à la v4.0 initiale)
• 31 mars 2024 : PCI DSS 3.2.1 officiellement retraitée ; la v4.0.1 devient l'unique standard. 13 exigences de v4.0.1 deviennent immédiatement obligatoires à cette date
• 31 mars – 1er avril 2025 : les 51 exigences "meilleures pratiques" deviennent obligatoires. Toutes les organisations doivent être intégralement conformes à PCI DSS 4.0.1

En pratique, nombre d'organisations françaises ont découvert en 2025 lors de leurs cycles d'audit annuels l'ampleur réelle des changements, particulièrement sur l'exigence 6.4.3 qui nécessite un inventaire complet de scripts souvent accumulés sans suivi formel. Les acquéreurs bancaires (BNP Paribas Mercanet, Crédit Agricole, Société Générale, Worldline, Lyra Network) exigent désormais systématiquement les preuves de conformité v4.0.1 pour le renouvellement des contrats d'acceptation. Les réseaux Visa et Mastercard ont également renforcé leurs programmes de surveillance avec des contrôles trimestriels sur la conformité déclarée.

Exigence 6.4.3 : la protection anti-e-skimming en détail

L'exigence 6.4.3 est la plus emblématique et la plus opérationnellement complexe de PCI DSS 4.0.1. Elle répond directement à la menace Magecart, qui consiste à injecter du code JavaScript malveillant dans les pages de paiement pour intercepter les données de carte à la saisie — soit en compromettant directement le serveur web du marchand, soit en compromettant un service tiers (analytics, CDN, chatbot) dont le script est intégré sur la page de paiement.

L'exigence 6.4.3 impose quatre obligations cumulatives :

• Inventaire complet de tous les scripts JavaScript présents sur les pages de paiement : scripts internes et tiers (analytics, chatbots, widgets sociaux, publicité, A/B testing, CDN de bibliothèques, pixels de conversion, outils de session recording)
• Justification documentée de chaque script : son rôle fonctionnel précis, son éditeur, la raison de sa présence sur la page de paiement, et l'approbation formelle de la direction. Tout script non justifié doit être retiré
• Contrôle d'intégrité des scripts tiers : Subresource Integrity (SRI) avec hash cryptographique (SHA-384 recommandé), vérification côté serveur, ou monitoring continu par des outils spécialisés (Jscrambler, Reflectiz, c/side, PerimeterX)
• Liste blanche des scripts autorisés et Content Security Policy (CSP) bloquant tout script non listé — en mode enforcement, pas seulement Report-Only

Exigence 8.4.2 : MFA pour tous les accès au CDE

PCI DSS 3.2.1 exigeait la MFA uniquement pour les accès distants à l'environnement des données de cartes (CDE). La v4.0.1 étend cette obligation à tous les accès non-console au CDE, y compris depuis le réseau interne — un changement significatif pour les équipes système qui accédaient aux serveurs de paiement depuis le LAN en croyant être exemptées de MFA.

Impacts opérationnels de l'exigence 8.4.2 :

• Administrateurs accédant aux serveurs du CDE via RDP, SSH, console web, ou outils de management à distance (Ansible, Puppet, Chef) depuis le réseau local : MFA obligatoire
• Applications interconnectées accédant programmatiquement au CDE : comptes de service à auditer, certificats clients ou secrets d'API rotatifs requis avec mécanisme de validation forte
• Accès via jump server ou bastion host : MFA requise sur le bastion, même si la connexion finale au serveur de paiement utilise des certificats
• Comptes partagés interdits : chaque compte accédant au CDE doit être nominatif avec sa propre MFA

Les solutions MFA acceptées incluent TOTP (Google Authenticator, Microsoft Authenticator, Duo Security), FIDO2/WebAuthn (YubiKey, Windows Hello), applications d'authentification push, et certificates clients. La MFA via Microsoft Entra ID Conditional Access est conforme si configurée pour couvrir tous les accès CDE sans exception. Les SMS OTP sont tolérés mais déconseillés (vulnérables au SIM swapping).

La Customized Approach : flexibilité pour les organisations matures

La Customized Approach est l'innovation conceptuelle la plus importante de PCI DSS 4.0.1. Elle permet aux organisations dont l'architecture de sécurité est avancée d'implémenter des contrôles alternatifs documentés pour atteindre l'objectif de sécurité d'une exigence, sans appliquer nécessairement les contrôles prescriptifs par défaut. Cette approche est particulièrement pertinente pour les organisations Zero Trust, les environnements cloud natifs, ou les architectures de tokenisation avancées où les contrôles prescriptifs conçus pour des architectures réseau physiques des années 2000 sont inadaptés.

Conditions d'utilisation de la Customized Approach :

• Documentation précise du contrôle alternatif dans une Customized Controls Matrix
• Démonstration formelle que le contrôle alternatif atteint ou dépasse l'objectif de sécurité
• Validation indépendante par le QSA avec des tests de sécurité spécifiques
• Inclusion dans l'AOC (Attestation of Compliance) et le rapport final (ROC)

Réduction du périmètre CDE : la stratégie d'optimisation

La stratégie la plus efficace pour réduire la charge de conformité PCI DSS reste la réduction du périmètre — limiter au strict minimum le nombre de systèmes et de personnes ayant accès aux données de carte (Cardholder Data Environment, CDE). PCI DSS 4.0.1 maintient les mécanismes de réduction de scope éprouvés :

• Tokenisation certifiée PCI SSC : remplacement du PAN par un token opaque — les systèmes downstream ne voient plus jamais de données de carte réelles, les sortant du scope PCI
• P2PE certifié (Point-to-Point Encryption) : solutions certifiées P2PE (Worldline, Ingenico/Nexi, PAX) qui chiffrent les données dès le terminal — seule la liste P2PE reste in-scope, pas tous les systèmes de caisse
• Passerelles de paiement hébergées : formulaires iFrame ou redirections vers Stripe, Adyen, Lyra Network, HiPay, Worldline Sips — qualification possible en SAQ A (22 exigences seulement au lieu de 200+)
• Segmentation réseau rigoureuse : isolation du CDE via firewalls dédiés et VLAN séparés, documentée et testée annuellement par pentests de segmentation (exigence 11.4.5)

L'objectif est de réduire le CDE au minimum viable fonctionnel. En e-commerce, passer d'un formulaire de paiement hébergé en interne à une solution iFrame certifiée peut faire passer votre qualification de SAQ D (329 exigences) à SAQ A (22 exigences) — une réduction de 93 % de la charge de conformité. Pour les PME commerçantes, c'est souvent l'investissement le plus rentable en matière de conformité PCI DSS.

PCI DSS 4.0.1 et environnements cloud AWS, Azure, GCP

PCI DSS 4.0.1 apporte des clarifications utiles pour les organisations dont l'environnement de paiement est hébergé sur des infrastructures cloud. Le modèle de responsabilité partagée s'applique explicitement : le fournisseur cloud (AWS, Azure, GCP) est responsable de la sécurité de l'infrastructure physique et des services managés sous-jacents ; le client reste entièrement responsable de la configuration sécurisée de ses ressources cloud et de la protection des données qu'il y dépose.

Points d'attention spécifiques pour les environnements cloud PCI DSS 4.0.1 :

• IAM cloud in-scope : tous les comptes AWS/Azure/GCP disposant d'accès aux ressources du CDE (bases de données, services de traitement, logs) sont soumis à la MFA 8.4.2 et à la gestion des accès à moindre privilège
• Journalisation cloud : CloudTrail, Azure Monitor et GCP Cloud Audit Logs satisfont aux exigences 10.2-10.7 si configurés pour retenir les logs 12 mois minimum (3 mois accessibles immédiatement) et protégés contre la modification
• Security Groups / NSG : documentés, soumis à revue formelle trimestrielle, et testés pour confirmer l'isolation du CDE (exigence 1.3)
• Containers dans le CDE : images scannées pour vulnérabilités avant déploiement (exigence 6.3.3), maintenues à jour selon le processus de patch management

Les grands fournisseurs cloud publient des guides de conformité PCI DSS pour leurs services (AWS PCI DSS Compliance Guide, Azure PCI Blueprint, GCP PCI Reference Architecture) qui indiquent précisément quelles exigences sont couvertes par l'infrastructure cloud (héritage provider) et lesquelles restent à la charge du client. La conformité cloud PCI DSS est souvent facilitée par la certification ISO 27001:2022 qui couvre des exigences convergentes (gestion des risques, journalisation, contrôle des accès).

Tests d'intrusion et scans de vulnérabilité : exigences 11.3 et 11.4

PCI DSS 4.0.1 renforce les obligations de tests de sécurité récurrents. L'exigence 11.3 impose des scans de vulnérabilités trimestriels par un Approved Scanning Vendor (ASV) pour tous les composants in-scope accessibles depuis internet, ainsi que des scans internes trimestriels de l'ensemble du CDE. Ces scans doivent aboutir à un résultat "clean" (aucune vulnérabilité critique ou haute) avant de pouvoir être présentés au QSA. Trois nouveaux essais consécutifs "passing" sont requis si les premiers résultats présentent des vulnérabilités.

L'exigence 11.4 impose un test d'intrusion annuel (méthodologie PTES, OWASP ou équivalent) couvrant les composants in-scope internes et exposés sur internet. Depuis PCI DSS 4.0.1, les tests de segmentation (exigence 11.4.5) doivent être réalisés au moins tous les 6 mois pour les PSP et entités Level 1, et lors de tout changement d'infrastructure. Ces tests de segmentation doivent démontrer qu'un attaquant ayant compromis la zone non-CDE ne peut pas pivoter vers le CDE. Ils constituent un élément de preuve essentiel pour le QSA.

Pour les marchands de Level 2 à 4 utilisant un prestataire de pentest externe, vérifiez que le rapport couvre explicitement les exigences PCI DSS 11.4.3 (tests d'intrusion externes) et 11.4.4 (tests d'intrusion internes), et qu'il mentionne la méthodologie et la liste des systèmes testés. Un rapport générique sans référence PCI DSS ne sera pas accepté par le QSA.

Ressources PCI DSS et acteurs en France

Pour réussir votre mise en conformité PCI DSS 4.0.1, voici les ressources et acteurs clés :

• PCI SSC (PCI Security Standards Council) : publie le standard PCI DSS, la liste officielle des QSA certifiés, des ASV, et des solutions P2PE validées. La liste des QSA est disponible sur pcisecuritystandards.org. Vérifiez impérativement que votre auditeur figure bien dans cette liste officielle
• QSA francophones en France : Wavestone, Synetis, Almond (ex-Solucom), NXO, Orange Cyberdefense, Advens figurent parmi les QSA actifs sur le marché français
• ASV pour les scans externes : Trustwave, Coalfire, SecurityMetrics, Rapid7 (NeXpose), Qualys — solutions certifiées ASV pour les scans trimestriels obligatoires
• Guides ENISA : l'Agence européenne pour la cybersécurité publie des ressources sur la sécurité des paiements en ligne consultables sur enisa.europa.eu
• Banque de France / ACPR : régulateur des PSP en France, suit la conformité PCI DSS en articulation avec la DSP2 et les exigences DORA pour les établissements de paiement agréés

La mise en conformité PCI DSS 4.0.1 représente un investissement, mais il faut la voir comme un prérequis minimal à toute stratégie de certification ISO 27001 ou de conformité NIS2. Les exigences techniques sont largement convergentes et les organisations qui ont investi dans PCI DSS disposent déjà d'une base solide pour les autres référentiels de conformité. Pour un accompagnement complet depuis l'analyse de périmètre jusqu'à l'audit QSA, notre mission RSSI externalisé intègre systématiquement la conformité PCI DSS 4.0.1 dans sa feuille de route.

Préparer l'audit QSA PCI DSS 4.0.1 : points d'attention 2026

Pour les organisations en cycle d'audit QSA 2026, voici les exigences les plus scrutées par les auditeurs depuis l'entrée en vigueur de la v4.0.1 :

• Inventaire scripts 6.4.3 : point le plus fréquemment défaillant en 2025-2026. Présentez un document daté listant exhaustivement chaque script sur vos pages de paiement avec justification, et démontrez le mécanisme de contrôle d'intégrité en production
• MFA pour tous accès CDE 8.4.2 : cartographiez tous les chemins d'accès au CDE (local, distant, applicatif, scripts automatisés) et vérifiez que chacun requiert une MFA sans exception — le QSA testera un accès sans MFA pour vérifier qu'il est bloqué
• Targeted Risk Analysis 12.3.2 : pour chaque exigence à fréquence flexible (scan de vulnérabilités, formation sécurité...), une analyse de risque documentée et signée doit justifier la fréquence retenue. Les QSA demandent systématiquement ce document
• Tests d'intrusion et segmentation 11.4.3-11.4.5 : rapport de pentest interne et externe de moins de 12 mois, incluant explicitement les tests de segmentation réseau CDE/non-CDE. Notre équipe réalise ces tests dans le cadre d'une mission RSSI externalisé
• Protection de l'intégrité des systèmes de log 10.7.2 : alertes configurées et testées si un système de journalisation cesse de remonter des événements — le QSA peut demander une démonstration de la détection en simulation

Questions fréquentes

PCI DSS 4.0.1 est-il obligatoire pour les marchands utilisant exclusivement une solution de paiement hébergée ?

Oui, PCI DSS s'applique à tout marchand acceptant des paiements par carte même via une solution hébergée. Avec un formulaire de paiement intégralement hébergé chez un prestataire certifié (iFrame Stripe, redirection Adyen, Lyra), vous vous qualifiez en SAQ A (seulement 22 exigences). Mais l'exigence 6.4.3 s'applique quand même sur la page contenant l'iFrame : votre CSP doit bloquer les scripts non autorisés sur cette page, même si vous ne traitez aucune donnée de carte directement.

Quelle est la différence entre SAQ A, SAQ A-EP et ROC en PCI DSS 4.0.1 ?

Le SAQ A (22 exigences) concerne les marchands dont le formulaire de paiement est entièrement hébergé sans code JavaScript côté marchand interagissant avec les données de carte. Le SAQ A-EP (189 exigences) s'applique quand du JavaScript côté marchand interagit avec le formulaire hébergé — l'exigence 6.4.3 s'applique pleinement. Le ROC (audit complet par QSA) est obligatoire pour Level 1 et certains Level 2. Validez impérativement le choix du SAQ avec votre acquéreur bancaire.

Comment démontrer la conformité à l'exigence anti-skimming 6.4.3 lors d'un audit QSA ?

Votre QSA attendra : (1) un inventaire documenté et daté de tous les scripts JavaScript sur vos pages de paiement avec justification pour chacun, (2) la configuration CSP en mode liste blanche enforcement (pas seulement report-only), (3) des preuves du mécanisme de contrôle d'intégrité (SRI hashes, rapports d'outil de monitoring). Des solutions comme Jscrambler ou Reflectiz automatisent la génération de ces preuves. Prévoyez 3 à 6 mois de préparation si vous n'avez pas encore d'inventaire formel de vos scripts.

PCI DSS 4.0.1 s'articule-t-il avec NIS2 pour les prestataires de paiement ?

Un PSP de taille significative est probablement soumis aux deux régimes : NIS2 comme fournisseur de services numériques financiers (obligations de résilience opérationnelle, notification incidents en 72h à l'ANSSI), et PCI DSS pour la sécurité des données de carte (notification immédiate à l'acquéreur en cas de compromission). Les exigences techniques sont largement convergentes mais les procédures de notification sont distinctes. Voir notre analyse de NIS2 en phase opérationnelle.

Quelles sanctions en cas de non-conformité PCI DSS découverte lors d'un audit ?

Les sanctions PCI DSS sont contractuelles (pas légales) et imposées par les réseaux de carte via l'acquéreur : amendes mensuelles de 5 000 à 100 000 $ selon l'acquéreur, augmentation des frais de traitement, audit forensics obligatoire à vos frais en cas de compromission. Si des données sont effectivement compromises : indemnisation des banques émettrices à 10-90 $ par carte compromise, coûts forensics (50 000-200 000 $), résiliation possible du contrat d'acceptation de cartes.