1 Retour d'expérience après 1 an
Un an de PCI DSS 4.0 : le bilan
Le 31 mars 2025 marquait la fin de la période de transition pour les exigences "best practice" de PCI DSS 4.0. Un an après, le bilan est contrasté. Si la plupart des grandes organisations ont réussi leur transition, beaucoup de structures de taille intermédiaire ont rencontré des difficultés significatives, notamment sur les nouvelles exigences de sécurité côté client et l'authentification multi-facteurs généralisée.
La version 4.0.1, publiée en juin 2024, a apporté des clarifications bienvenues sur plusieurs points ambigus de la version initiale. Ces clarifications ont facilité l'interprétation des exigences par les QSA et réduit les écarts d'appréciation entre auditeurs. Néanmoins, certaines exigences restent complexes à implémenter, notamment les contrôles client-side et la gestion des scripts tiers.
Les statistiques des premiers audits 4.0 révèlent des tendances préoccupantes : environ 40% des organisations ont échoué à leur première tentative de certification, principalement en raison de lacunes sur les nouvelles exigences. Les points de non-conformité les plus fréquents concernent le MFA, l'inventaire des scripts et la documentation des analyses de risques.
Fin transition exigences 4.0
Nouvelles exigences dans v4.0
Domaines de contrôle
2 Changements majeurs de PCI DSS 4.0
Évolution de la philosophie
PCI DSS 4.0 marque un changement de philosophie majeur par rapport aux versions précédentes. Le standard évolue d'une approche prescriptive ("faites ceci") vers une approche orientée résultats ("atteignez cet objectif de sécurité"). Cette évolution se traduit par l'introduction de l'approche personnalisée, permettant aux organisations de démontrer qu'elles atteignent les objectifs de sécurité par des moyens alternatifs.
Les 12 domaines de contrôle restent inchangés, mais de nombreuses exigences ont été réorganisées, clarifiées ou renforcées. Le nombre total d'exigences passe d'environ 250 à plus de 300, avec 64 nouvelles exigences dont 13 applicables immédiatement et 51 qui étaient "best practice" jusqu'en mars 2025.
Principales Nouveautés PCI DSS 4.0
Figure 1 : Les 6 domaines de changements majeurs de PCI DSS 4.0
3 MFA généralisé
Extension du périmètre MFA
L'une des évolutions les plus impactantes de PCI DSS 4.0 concerne l'authentification multi-facteurs (MFA). Alors que les versions précédentes exigeaient le MFA uniquement pour les accès distants au CDE, la version 4.0 étend cette exigence à tous les accès au CDE, y compris depuis le réseau interne.
L'exigence 8.4.2 impose désormais le MFA pour tous les accès aux composants du CDE, quelle que soit l'origine de la connexion. L'exigence 8.4.3 ajoute le MFA pour tous les accès distants provenant de l'extérieur du réseau de l'entité. Ces exigences cumulatives ont nécessité un déploiement massif de solutions MFA.
Exigences MFA PCI DSS 4.0
- 8.4.2 : MFA pour tous les accès au CDE (interne et externe)
- 8.4.3 : MFA pour tous les accès distants au réseau de l'entité
- 8.5.1 : MFA correctement implémenté (indépendance des facteurs)
Implémentation conforme
L'exigence 8.5.1 détaille les critères d'une implémentation MFA conforme. Les facteurs d'authentification doivent être indépendants : compromettre un facteur ne doit pas compromettre les autres. L'authentification doit utiliser au moins deux des trois catégories : quelque chose que l'on sait, quelque chose que l'on possède, quelque chose que l'on est.
Les solutions MFA par SMS, bien que toujours acceptées, sont déconseillées en raison des risques de SIM swapping. Les recommandations privilégient les tokens FIDO2, les applications d'authentification (TOTP) ou les certificats sur carte à puce. Le déploiement de solutions passwordless conformes FIDO2 constitue une tendance forte en 2026.
4 Sécurité côté client
Protection contre les attaques Magecart
Les exigences 6.4.3 et 11.6.1 constituent une réponse directe aux attaques de type Magecart qui ont compromis des millions de cartes bancaires ces dernières années. Ces attaques exploitent les scripts JavaScript chargés sur les pages de paiement pour intercepter les données de carte en temps réel.
L'exigence 6.4.3 impose de maintenir un inventaire de tous les scripts exécutés sur les pages de paiement, de documenter leur justification métier, de vérifier leur intégrité et d'autoriser explicitement leur exécution. Cette exigence s'applique aux scripts internes comme aux scripts tiers (analytics, chat, etc.).
Architecture Sécurisée Page Paiement
Figure 2 : Contrôles de sécurité requis pour les pages de paiement
Mécanismes de détection (11.6.1)
L'exigence 11.6.1 impose de déployer un mécanisme de détection des modifications non autorisées sur les pages de paiement. Ce mécanisme peut reposer sur des headers HTTP de sécurité (Content Security Policy, Subresource Integrity), des solutions de surveillance en temps réel ou des comparaisons périodiques de hash. L'objectif est de détecter toute injection de code malveillant avant qu'elle ne compromette des données de carte.
5 Approche personnalisée
Une alternative aux contrôles définis
L'approche personnalisée (Customized Approach) constitue une innovation majeure de PCI DSS 4.0. Elle permet aux organisations de démontrer qu'elles atteignent l'objectif de sécurité d'une exigence par des moyens différents de ceux prescrits. Cette flexibilité reconnaît que différentes technologies et architectures peuvent offrir des niveaux de sécurité équivalents.
Pour utiliser l'approche personnalisée, l'organisation doit documenter les contrôles mis en place, démontrer comment ils atteignent l'objectif de sécurité de l'exigence, et faire valider cette approche par un QSA. La documentation doit inclure une analyse de risques ciblée justifiant que le contrôle personnalisé offre une protection équivalente ou supérieure.
| Approche | Avantages | Inconvénients |
|---|---|---|
| Définie (Standard) | Clarté, prévisibilité, moins de documentation | Rigidité, peut nécessiter des changements |
| Personnalisée | Flexibilité, innovation, adaptation contexte | Documentation lourde, validation QSA |
6 Erreurs courantes
Erreur 1 : MFA partiel
De nombreuses organisations n'ont déployé le MFA que pour les accès distants, omettant les accès internes au CDE. L'exigence 8.4.2 couvre TOUS les accès, y compris depuis le réseau interne.
Erreur 2 : Inventaire scripts incomplet
L'inventaire des scripts (6.4.3) omet souvent les scripts chargés dynamiquement, les tags managers et leurs sous-scripts. Un inventaire complet nécessite une analyse technique approfondie.
Erreur 3 : Analyses de risques manquantes
PCI DSS 4.0 exige des analyses de risques ciblées pour plusieurs exigences. Beaucoup d'organisations n'ont pas documenté ces analyses ou les ont réalisées de manière superficielle.
Erreur 4 : Périmètre CDE non actualisé
La segmentation et la définition du CDE n'ont pas été revues à la lumière des nouvelles exigences. Les flux de données de carte doivent être revalidés régulièrement.
7 Tests d'intrusion
Exigences renforcées
PCI DSS 4.0 renforce les exigences de tests d'intrusion (11.4). Les tests doivent couvrir l'ensemble du périmètre CDE, les contrôles de segmentation et les nouvelles exigences de sécurité côté client. La méthodologie doit être basée sur des standards reconnus (PTES, OWASP, NIST).
Les tests de segmentation (11.4.5) doivent valider que le CDE est effectivement isolé des réseaux hors périmètre. Ces tests doivent être réalisés au moins tous les 6 mois et après tout changement de segmentation. La fréquence annuelle des pentests applicatifs et réseaux est maintenue.
Périmètre Tests d'Intrusion PCI DSS 4.0
Figure 3 : Couverture requise des tests d'intrusion PCI DSS 4.0
8 Maintien de la conformité
Conformité continue
PCI DSS 4.0 renforce l'importance de la conformité continue, par opposition à une conformité ponctuelle lors des audits. Plusieurs exigences imposent désormais des contrôles réguliers : revues d'accès trimestrielles, scans de vulnérabilités mensuels, analyses de logs quotidiennes et tests de segmentation semestriels.
La documentation des preuves de conformité tout au long de l'année devient cruciale. Les organisations doivent mettre en place des processus de collecte automatisée des preuves, des tableaux de bord de suivi de conformité et des alertes en cas de dérive. Cette approche facilite également la préparation des audits annuels.
9 Audit QSA
Préparation à l'audit
La préparation à un audit PCI DSS 4.0 requiert une anticipation de plusieurs mois. Les organisations doivent réaliser un pré-audit interne ou faire appel à un consultant pour identifier les écarts avant l'audit officiel. La documentation doit être complète et à jour : politiques, procédures, preuves de contrôles, analyses de risques.
Le choix du QSA est important. Tous les QSA ne sont pas équivalents : certains ont une expertise particulière sur les nouvelles exigences 4.0 ou sur des secteurs d'activité spécifiques. Une collaboration étroite avec le QSA tout au long de l'année, et pas seulement pendant l'audit, facilite le maintien de la conformité.
10 Best practices
Gouvernance et organisation
- ✓Nommer un responsable PCI DSS avec autorité suffisante
- ✓Intégrer PCI DSS dans les comités sécurité réguliers
- ✓Former les équipes aux nouvelles exigences 4.0
Technique et opérationnel
- ✓Automatiser la collecte des preuves de conformité
- ✓Déployer des solutions de monitoring client-side
- ✓Centraliser la gestion des accès avec MFA natif
Amélioration continue
- ✓Réaliser des audits internes trimestriels
- ✓Suivre l'évolution du standard et des FAQ
- ✓Participer aux groupes d'échange PCI DSS
Besoin d'accompagnement PCI DSS ?
Nos experts QSA vous accompagnent dans l'évaluation de votre conformité PCI DSS 4.0, la remédiation des écarts et la préparation de vos audits de certification.