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.

The Foundation: A New Approach to Eligibility and Scope

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.

Terminology Overhaul: Understanding the New Language

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.

Structural Reorganisation: Core Requirements and Modules

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:

1. Software Architecture, Composition, and Versioning — Including new requirements for Bill of Materials (BOM) and wildcard versioning
2. Sensitive Asset Identification — Establishing the foundation for subsequent requirements
3. Sensitive Asset Storage and Retention
4. Sensitive Modes of Operation — Formalized context for access control and strong authentication
5. Sensitive Asset Protection — Including formalized anomalous behavior detection
6. Sensitive Asset Output — With formalized secure channel requirements
7. Random Numbers — Refined requirements for external RNG usage or internal implementation
8. Key Management
9. Cryptography — A single encompassing requirement for areas not covered elsewhere
10. Threats and Vulnerabilities
11. Secure Deployment and Management — Including implementation guidance requirements

Module Evolution: What's Changed

Module A – Account Data Protection

Requirements have been revised to focus solely on PAN and SAD in relation to PCI DSS, with additional context provided in the SAID document.

Module B – POI Device Software

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.

Module C – Publicly-Accessible Software

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.

Module D – Software Development Kits (NEW)

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.

Delta Changes: The New Tier System

The previous "Low Impact" and "High Impact" change categories have been replaced with a Tier 1 and Tier 2 Delta Change structure:

Tier 1 Delta Changes

• Non-security impacting changes where version numbers must change but wildcards aren't being used
• SSLC-Qualified Vendors benefit: Security-impacting bug fixes/patches, even involving sensitive assets, qualify as Tier 1 and can be self-submitted without assessor involvement

Tier 2 Delta Changes

• Introduction of new sensitive asset types
• Changes requiring assessment of previously unassessed requirements
• Changes involving or impacting sensitive assets (except Tier 1 eligible changes for SSLC vendors)
• PTS POI device changes
• Modification of Required Dependencies
• Removal of specific versions from listings

Wildcards: Formalised and Reintroduced

Wildcard versioning has been formally reintroduced with clear rules:

• Definition: A character that may be substituted for a defined subset of possible characters in a versioning scheme to account for non-security impacting changes
• Wildcards must appear only in the rightmost (least significant) portion of version numbers
• Allowable wildcard characters: lowercase {x, y, z}, uppercase {X, Y, Z}, or asterisk (*)
• A single wildcard represents a single digit replacement {0-9}
• Wildcards cannot represent security-impacting changes

This formalization allows vendors to manage minor releases without submitting changes to PCI SSC, provided wildcard usage is validated during the Full Assessment.

Assessment Requirements: Source Code is Mandatory

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:

1. Documentation Review
2. Static Analysis
3. Dynamic Analysis

Lifecycle and Administrative Processes

The 3-year validation lifecycle remains intact:

• Year 1 & 2: Annual Vendor Attestation required
• Year 3: Reassessment required to maintain listing

Key clarifications in v2.0:

• Administrative Expiry Period: 45 calendar days after missed attestation deadline, shown in orange on listings
• Listing Expiry: After the 45-day grace period, products become Expired Secure Software Products
• Expired products require New Assessment, not Reassessment, to reinstate listing

Security Issue Notification: New Dedicated Section

Version 2.0 introduces a dedicated Section 8 for Security Issue Notification, formalizing:

• Notification timing requirements per the VRA
• Required notification format (written, preceded by email)
• Minimum notification details including CVSS scoring
• PCI SSC response actions including potential Acceptance withdrawal

Practical Implications for Stakeholders

For Software Vendors

• Review your products against the new Sensitive Asset definition
• Update versioning methodologies to leverage wildcard benefits
• Prepare comprehensive BOMs for assessment
• Consider SSLC qualification for Tier 1 Delta Change benefits
• Ensure source code availability for assessments

For SSF Assessor Companies

• Complete required v2.x training before performing assessments
• Familiarize yourself with the new SAID document
• Update assessment methodologies for the new test requirement structure
• Prepare for SDK assessments under Module D

For Customers

• Verify vendors are providing implementation guidance consistent with listed version numbers
• Understand that Required Dependencies are part of the validation—using non-listed dependencies invalidates the listing
• Monitor vendor attestation dates and reassessment timelines

Conclusion

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.