Beyond Compliance: What PCI Secure Software Standard v2.0 Means for Payment Software Vendors

The PCI Security Standards Council (PCI SSC) has released version 2.0 of the Secure Software Standard (S3) and its accompanying Program Guide marking the most significant revision since the framework’s inception in 2019. The update introduces fundamental structural, conceptual, and assessment methodology changes while signaling a shift in compliance from periodic validation of software to continuous governance throughout its lifecycle.

What has Changed in PCI Secure Software Standard v2.0

Unlike incremental revisions, v2.0 introduces structural changes in how software security is assessed and governed, with notable highlights stated below.

1. Introduction of the Sensitive Assets Model Improves Architectural Visibility

The most important shift is the move from “Payment Software” and “Critical Assets” to a formal “Sensitive Asset–driven model” that underpins scoping, documentation, testing, and assessment evidence. Eligibility is no longer tied to “payment software type” or predefined categories, but to what the software does and what it handles, , placing greater emphasis on architecture visibility and documentation. Some of the payment software types eligible under v2.0 include ATM application, POS application, fraud monitoring software, in-app payment SDK, tokenization service and key management software. For vendors, the 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.

2. SDKs, Including 3DS SDKs, Become Eligible for Assessment

PCI S3 v2.0 expands scope eligibility to include software development kits, including EMVCo 3DS SDKs. This is significant because SDKs often operate deep inside merchant and issuer applications and historically fell into assessment grey areas. This also indicates PCI SSC’s direction toward consolidating standards, with v2.0 expected to eventually replace the standalone PCI 3DS SDK standard, offering vendors greater flexibility through the more objective nature of the Secure Software Standard.

3. Change and Impact Management Requirements Improve Clarity

The latest revision refines how software changes are evaluated post-certification with key updates that include simplified Two-Tier delta for change impact assessment processes, standardized templates to evaluate change impact, and updated portal and process improvements for listings and attestations. A notable update is the introduction of controlled use of wildcard and version-range listings. Wildcard versioning is now permitted, that allows vendors to manage minor releases without submitting changes to PCI SSC but only within a disciplined, evidence-driven framework that preserves assessment integrity. For vendors, this reduces ambiguity but increases expectations around disciplined change management.

4. Structural Reorganisation of Requirements Streamline Assessments

The v2.0 standard has been entirely restructured around eleven security objectives in the Core section, introducing clearer separation between core requirements and modular components. This, along with the streamlining of modules aims to make assessments more consistent and scalable across different software architectures and deployment models. For vendors, this improves clarity but also means that certification preparation must now map product architecture more precisely to requirement modules. Products with modular architectures or distributed components will need stronger requirement-to-component mapping during assessments.

5. Provision of Source Code Becomes Mandatory for Assessment

Another practical change for vendors is that the provision of source code to assessors as part of certification that was previously implicit, is now mandatory. For vendors, this introduces new operational considerations such as secure handling and sharing of proprietary source code during assessments and building internal readiness for deeper assessor review. Additionally, test requirements have been completely rewritten around three methods viz, Documentation review, Static analysis and Dynamic analysis, adding more clarity.

6. Alignment with Strong Cryptography as the Baseline Enhances Asset Protection

Cryptographic controls now align more closely with PCI DSS expectations around strong cryptography. Vendors must ensure encryption mechanisms meet modern cryptographic standards across software components and data handling processes. Legacy implementations or outdated algorithms will increasingly come under scrutiny during assessments.

The Road to Transition: How Vendors Should Prepare Now

PCI SSC has announced a transition path where v2.0 will replace v1.2.1 after a defined transition period once assessor training becomes available. Vendors will need to plan migration timelines carefully to avoid certification disruption. Vendor organizations can engage with such as SISA, who can provide expert security recommendations and guidance on implementation and ensure the transition is smooth and seamless. To kickstart the transition journey, SISA recommends an eight-point checklist for software vendors before initiating a v2.0 assessment.

• Perform a full Sensitive Asset Identification exercise
• Create and maintain sensitive asset flow diagrams
• Document cryptographic key inventories and lifecycle controls
• Review and formalize retention and deletion logic
• Identify and secure any sensitive modes of operation
• Review versioning practices, especially if using wildcards
• Update implementation and deployment guidance.
• Maintain a software Bill of Materials (BOM) aligned with Sensitive Asset identification.

The existing PCI Secure Software Standard v1.2.1 listings will however remain valid and continue to be accepted by PCI SSC until further notice.

Conclusion: PCI S3 v2.0 Signals a Shift in Product Security Governance

PCI Secure Software Standard v2.0 affects engineering, product management, compliance, and data governance. It is not just a certification update. Executives should treat this transition as investment in product resilience and market confidence, not compliance overhead. For payment software vendors, this is not just a technical revision. It shifts the assessment focus from primarily functional validation to design assurance, asset awareness, and lifecycle governance, while signalling a transition in how product security must be engineered, governed, and maintained.

References:

https://docs-prv.pcisecuritystandards.org/Software%20Security/Standard/PCI-Secure-Software-Standard-v2.0.pdf

https://docs-prv.pcisecuritystandards.org/Software%20Security/Standard/PCI-Secure-Software-Standard-v2.0-Summary-Of-Changes.pdf

https://docs-prv.pcisecuritystandards.org/Software%20Security/Program%20Documents/PCI-Secure-Software-Program-Guide-v2.0.pdf

https://docs-prv.pcisecuritystandards.org/Software%20Security/Standard/PCI-Secure-Software-Standard-Sensitive-Asset-Identification_v1.0.pdf