PCI DSS v4 introduit 64 nouvelles exigences par rapport à la version v3.2.1. Pour les marchands et prestataires de paiement européens, comprendre ces changements en détail est indispensable pour planifier la mise en conformité et allouer les ressources nécessaires.
La structure des 12 exigences PCI DSS et les changements v4
PCI DSS est organisé autour de 12 exigences principales regroupées en 6 objectifs de contrôle. La v4 maintient cette structure mais enrichit considérablement le contenu de chaque exigence. Les changements les plus significatifs concernent les exigences 3 (protection des données de carte stockées), 6 (développement de systèmes sécurisés), 8 (identification et authentification), et 11 (tests de sécurité).
L'exigence 3 introduit de nouvelles obligations sur le chiffrement des données de carte stockées, avec des algorithmes de chiffrement acceptables mis à jour et des exigences de gestion des clés cryptographiques renforcées. Pour les marchands qui stockent des PAN (numéros de compte principal) pour des raisons légitimes, ces nouvelles obligations impliquent une révision de l'architecture de stockage et des processus de rotation de clés.
Exigence 6 : sécurité des applications et protection des pages de paiement
L'exigence 6 subit les modifications les plus profondes. La sous-exigence 6.4.3 introduit une obligation entièrement nouvelle : la gestion de tous les scripts présents sur les pages de paiement en ligne. Chaque script doit être inventorié, sa présence justifiée, son intégrité vérifiée via un hash ou une signature cryptographique, et toute modification non autorisée doit être détectée.
Cette exigence est une réponse directe aux attaques de type skimming web (Magecart) qui ont compromis des dizaines de milliers de sites e-commerce en Europe entre 2018 et 2023. La mise en conformité implique l'adoption d'une Content Security Policy (CSP) stricte, d'un mécanisme de surveillance de l'intégrité des ressources (SRI), et d'un processus documenté de revue périodique des scripts tiers.
La sous-exigence 6.3.2 impose un inventaire complet des bibliothèques logicielles utilisées dans les applications de paiement, avec une surveillance des vulnérabilités pour chaque composant. La Software Composition Analysis (SCA) devient ainsi une pratique obligatoire pour tous les marchands qui développent ou maintiennent des applications traitant des données de carte.
Exigence 8 : authentification multi-facteur généralisée
L'exigence 8.4.2 étend l'obligation d'authentification multi-facteur (MFA) à tous les accès au CDE, et non plus seulement aux accès à distance. Concrètement, tout utilisateur — qu'il soit sur le réseau interne ou en accès distant — qui accède à des systèmes dans le périmètre PCI DSS doit s'authentifier avec au moins deux facteurs distincts.
Cette exigence est l'une des plus impactantes opérationnellement pour les marchands européens. Elle nécessite de déployer une solution MFA pour tous les accès aux systèmes du périmètre, ce qui peut impliquer une refonte des processus d'authentification des équipes IT, des équipes finance et des développeurs. Les solutions d'authentification basées uniquement sur un mot de passe ne sont plus acceptables pour aucun accès au CDE.
Exigences 10 et 11 : surveillance et tests renforcés
L'exigence 10.7 introduit une obligation de détection et de réponse aux anomalies dans les systèmes de contrôle d'accès critiques. Si un mécanisme de contrôle d'accès tombe en panne, le système doit générer une alerte. Cette exigence s'applique aux systèmes d'authentification, aux firewalls, aux solutions de chiffrement et aux mécanismes de contrôle d'intégrité des fichiers.
L'exigence 11.6.1 introduit la surveillance de l'intégrité des en-têtes HTTP et du contenu des pages de paiement. Tout changement non autorisé dans les en-têtes de sécurité (Content-Security-Policy, X-Frame-Options, etc.) ou dans le DOM des pages de paiement doit être détecté et notifié. Les outils de surveillance dédiés à la sécurité des pages web deviennent ainsi une exigence explicite pour tous les marchands e-commerce.
Approche personnalisée vs approche définie : flexibilité accrue en v4
L'une des innovations majeures de PCI DSS v4 est l'introduction de l'approche "customized" comme alternative à l'approche "defined" traditionnelle. Dans l'approche définie, les organisations implémentent exactement les contrôles spécifiés par PCI DSS. Dans l'approche personnalisée, elles peuvent proposer des contrôles alternatifs pour atteindre l'objectif de sécurité sous-jacent, à condition de pouvoir démontrer leur efficacité équivalente.
Pour les marchands européens qui ont des architectures particulières — systèmes legacy, environnements cloud hybrides, architectures micro-services — l'approche personnalisée offre une flexibilité bienvenue. Elle permet d'éviter des migrations coûteuses vers des architectures conformes à la lettre, à condition d'investir dans une documentation rigoureuse et dans les tests de validation de l'efficacité des contrôles alternatifs. Cette approche nécessite toutefois l'accompagnement d'un QSA qualifié.
Priorités pratiques pour les marchands européens en 2025
Pour les marchands européens qui doivent encore finaliser leur mise en conformité v4, les priorités pratiques sont les suivantes : réaliser un gap analysis par rapport aux 64 nouvelles exigences, déployer la MFA sur tous les accès au CDE, mettre en place la gestion des scripts de paiement sur les pages web, et documenter l'inventaire des composants logiciels utilisés dans les applications de paiement.
Les marchands qui utilisent des solutions de tokenisation et de pages de paiement hébergées ont un avantage significatif : leur périmètre réduit implique moins de nouvelles exigences à implémenter. Concentrer la conformité sur un périmètre minimal reste la stratégie la plus efficiente pour tout marchand cherchant à optimiser ses ressources de conformité.
Vous souhaitez évaluer votre conformité PCI DSS v4 et réduire votre périmètre ? Découvrir PCI Proxy EU.