Le Conseil des normes de sécurité PCI a publié la version 2.0 de la norme sur les logiciels sécurisés et le guide du programme qui l'accompagne, marquant ainsi la révision la plus importante depuis la création du cadre en 2019. Cette mise à jour remodèle fondamentalement la façon dont les logiciels de paiement sont évalués et validés, en introduisant une nouvelle terminologie, un champ d'application élargi et des processus rationalisés qui auront un impact sur les fournisseurs, les évaluateurs et les clients dans l'ensemble de l'écosystème de paiement.
Le changement le plus fondamental de la v2.0 est sans doute la suppression complète du terme "logiciel de paiement" de la norme. Les critères d'éligibilité sont désormais entièrement axés sur le concept de SensitiveAssets, définicomme tout élément du produit logiciel dont l'accès, l'utilisation, la modification ou la divulgation non autorisés peuvent compromettre les fonctionnalités ou les données liées aux paiements du logiciel.
Ce recadrage conceptuel s'accompagne d'un nouveau document d'accompagnement obligatoire, SensitiveAsset Identification (SAID), qui fournit un contexte et des exemples détaillés pour l'identification des données, des fonctionnalités, des ressources et des modes de fonctionnement sensibles. Pour les données liées à l'EMVCo 3DS, la norme fait désormais référence au document PCI 3DS Data Matrix.
L'implication pratique est claire : si votre logiciel traite des actifs sensibles tels que définis par la norme, il entre dans le champ d'application, qu'il corresponde ou non aux catégories traditionnelles de logiciels de paiement.
La version 2.0 introduit des mises à jour terminologiques importantes que les évaluateurs et les vendeurs doivent assimiler :
En outre, le glossaire a été déplacé d'un document SSF externe à l'annexe A de la norme elle-même, et les termes définis sont désormais indiqués dans les exigences de sécurité pour faciliter leur reconnaissance. Un nouveau terme, "Strong Authentication" (authentification forte), a été introduit, et la norme s'appuie désormais sur la base de "Strong Cryptography" (cryptographie forte) plutôt que sur des paramètres spécifiques de puissance de clé effective.
La norme v2.0 a été entièrement restructurée autour de onze objectifs de sécurité dans la section "Core", qui s'applique à tous les logiciels évalués dans le cadre :
Les exigences ont été révisées pour se concentrer uniquement sur le PAN et le SAD en relation avec PCI DSS, avec un contexte supplémentaire fourni dans le document SAID.
Rebaptisé "Exigences relatives au logiciel du terminal", ce module a été considérablement simplifié. De nombreuses exigences (B1.1, B1.2, B1.3, B3.x, B5.x) ont été absorbées dans les exigences principales, et les exigences SRED ont été révisées.
Le module a été renommé "Exigences relatives aux logiciels Web" afin de mieux rendre compte de son intention. La clarification du champ d'application est importante : ce module concerne les logiciels accessibles sur les réseaux publics, où toute personne ayant accès au réseau peut interagir avec le logiciel. Il est important de noter que les logiciels quine sont pas accessibles au public( et non ) peuvent toujours être évalués en fonction de ce module, à la discrétion du fournisseur, car les exigences contribuent à réduire les risques liés à toute mise en œuvre.
Ce module entièrement nouveau permet d'évaluer les kits de développement logiciel (SDK), y compris lesSDK EMVCo 3DS de . La norme indique explicitement que la version 2.0 remplacera à terme la norme PCI 3DS SDK, offrant ainsi aux vendeurs une plus grande flexibilité grâce à la nature plus objective de la norme Secure Software.
Les anciennes catégories de changement "Low Impact" et "High Impact" ont été remplacées par une structure Tier1 et Tier 2 Delta Change :
La version des jokers a été formellement réintroduite avec des règles claires :
Cette formalisation permet aux fournisseurs de gérer des versions mineures sans soumettre de changements à PCI SSC, à condition que l'utilisation des caractères génériques soit validée lors de l'évaluation complète.
La version 2.0 rend explicite ce qui était auparavant implicite : la fourniture du code source est obligatoire. Le guide du programme indique sans équivoque :
"L'éditeur du logiciel est tenu de fournir le code source de son produit évalué, si l'évaluateur le juge nécessaire. Il n'est pas possible de faire évaluer un produit logiciel selon cette norme sans fournir le code source correspondant".
Les exigences de test ont été entièrement réécrites autour de trois méthodes :
Le cycle de validation de 3 ans reste intact :
Principales clarifications dans la version 2.0 :
La version 2.0 introduit unesection 8 dédiée à la notification des problèmes de sécurité, qui formalise les exigences en matière de délais de notification conformément à l'ARV :
La norme PCI Secure Software Standard v2.0 représente une maturation du cadre, passant de catégories prescriptives de logiciels de paiement à une approche basée sur des principes centrés sur la protection des actifs sensibles. L'inclusion des capacités d'évaluation des SDK, la formalisation des versions wildcard et le système de changement delta à plusieurs niveaux sont autant d'éléments qui vont dans le sens d'un programme de validation plus souple et plus durable.
Pour les organisations qui détiennent actuellement des validations v1.x ou qui prévoient de nouvelles évaluations, le moment est venu de s'engager avec des sociétés d'évaluation SSF qualifiées pour comprendre le chemin de transition et tirer parti de la flexibilité accrue qu'offre cette révision majeure.
La norme PCI Secure Software Standard v2.0 et le guide du programme v2.0 entrent en vigueur en janvier 2026. Les organisations doivent consulter la documentation officielle du PCI SSC et les évaluateurs qualifiés pour obtenir des conseils spécifiques en matière de conformité.