The PCI Security Standards Council has released version 2.0 of the Secure Software Standard and its accompanying Program Guide, marking the most significant revision since the framework's inception in 2019. This update fundamentally reshapes how payment software is assessed and validated, introducing new terminology, expanded scope, and streamlined processes that will impact vendors, assessors, and customers across the payment ecosystem.
Perhaps the most fundamental shift in v2.0 is the complete removal of the term "Payment Software" from the standard. The eligibility criteria now centers entirely on the concept of Sensitive Assets—defined as any element of the software product whose unauthorized access, use, modification, or disclosure may compromise the software's payment-related functionality or data.
This conceptual reframing is accompanied by a new mandatory companion document, the Sensitive Asset Identification (SAID), which provides detailed context and examples for identifying sensitive data, functionality, resources, and modes of operation. For EMVCo 3DS-related data, the standard now references the PCI 3DS Data Matrix document.
The practical implication is clear: if your software handles sensitive assets as defined by the standard, it falls within scope—regardless of whether it fits traditional payment software categories.
Version 2.0 introduces significant terminology updates that assessors and vendors must internalize:
Additionally, the glossary has been relocated from an external SSF document into Appendix A of the standard itself, with defined terms now marked throughout security requirements for easy recognition. A new term, "Strong Authentication," has been introduced, and the standard now relies on the baseline of "Strong Cryptography" rather than specific effective key strength parameters.
The v2.0 standard has been entirely restructured around eleven Security Objectives in the Core section, which applies to all software assessed under the framework:
Requirements have been revised to focus solely on PAN and SAD in relation to PCI DSS, with additional context provided in the SAID document.
Renamed from "Terminal Software Requirements," this module has been significantly streamlined. Many requirements (B1.1, B1.2, B1.3, B3.x, B5.x) have been absorbed into Core requirements, and SRED requirements have been revised.
Renamed from "Web Software Requirements" to better capture its intent. The scope clarification is significant: this module addresses software accessible over public networks where essentially anyone with network access can interact with the software. Importantly, software that is not publicly accessible can still be assessed to this module at the vendor's discretion, as the requirements help reduce risk for any implementation.
This entirely new module enables assessment of SDKs, including EMVCo 3DS SDKs. The standard explicitly states that v2.0 will eventually replace the separate PCI 3DS SDK Standard, offering vendors greater flexibility through the more objective nature of the Secure Software Standard.
The previous "Low Impact" and "High Impact" change categories have been replaced with a Tier 1 and Tier 2 Delta Change structure:
Wildcard versioning has been formally reintroduced with clear rules:
This formalization allows vendors to manage minor releases without submitting changes to PCI SSC, provided wildcard usage is validated during the Full Assessment.
Version 2.0 makes explicit what was previously implicit: source code provision is mandatory. The Program Guide states unequivocally:
"The software vendor is expected to provide the source code for their software product being assessed, as deemed necessary by the assessor performing the assessment. It is not possible to have a software product assessed to this standard without the provision of relevant source code."
Test requirements have been completely rewritten around three methods:
The 3-year validation lifecycle remains intact:
Key clarifications in v2.0:
Version 2.0 introduces a dedicated Section 8 for Security Issue Notification, formalizing:
PCI Secure Software Standard v2.0 represents a maturation of the framework, moving from prescriptive payment software categories to a principles-based approach centered on sensitive asset protection. The inclusion of SDK assessment capabilities, formalized wildcard versioning, and the tiered delta change system all point toward a more flexible, sustainable validation program.
For organizations currently holding v1.x validations or planning new assessments, now is the time to engage with qualified SSF Assessor Companies to understand the transition path and leverage the enhanced flexibility this major revision provides.
The PCI Secure Software Standard v2.0 and Program Guide v2.0 are effective January 2026. Organisations should consult the official PCI SSC documentation and qualified assessors for specific compliance guidance.