What’s New in PCI Secure Software Standard v2.0

The PCI Security Standards Council (PCI SSC) released version 2.0 of the PCI Secure Software Standard in January 2026, marking a major revision from the previous v1.2.1. If your organization develops, assesses, or relies on payment software, this update carries significant implications. Here’s a breakdown of what’s changed and what you need to know.

A Major Revision – Not A Minor Update

First and foremost, the PCI SSC has emphasized that this is a major revision. Unlike incremental updates, there is no definitive one-to-one mapping between v1.2.1 and v2.0. Organizations should approach this as a significant rethink of the standard’s structure, language, and scope – not simply an updated checklist.

Key Terminology Changes

One of the most immediately noticeable shifts is the language used throughout the standard. The term “Payment Software” has been removed entirely. In its place, the standard now revolves around the concept of “Sensitive Assets.” This broader framing better captures the range of data, resources, and functionality that software must protect. Several related glossary terms have also been updated:

• “Critical Asset” is now “Sensitive Asset” (and has been rewritten)
• “Sensitive Function” is now “Sensitive Functionality” (and has been rewritten)
• “Sensitive Data” and “Sensitive Resource” definitions have both been revised
• A new term, “Strong Authentication,” has been introduced

The glossary itself has been moved in-house: v2.0 includes a new Appendix A that supersedes the previously external SSF Glossary document, making all defined terms available within the standard itself. Additionally, “Control Objectives” have been renamed “Security Objectives” throughout the document.

New Companion Document: Sensitive Asset Identification

A brand-new external companion document has been introduced alongside v2.0 – the Sensitive Asset Identification document. This is not optional reading: it is a mandatory companion to the standard and forms part of its program.

The document provides additional context and examples for understanding Sensitive Assets, Sensitive Data, Sensitive Functionality, and Sensitive Resources. For vendors working with EMVCo 3DS-related data, the standard also relies on the PCI 3DS Data Matrix document.

Restructured Test Requirements And Methodology

All test requirements have been essentially rewritten in v2.0. The new approach is structured around three core methods:

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

Additional new sections include Software Testing, Provision of Source Code, Technical Constraints, and Technical FAQs – the last of which mirrors language from existing PCI Technical FAQ documents.

Overhauled Core Requirements

The core section has been retitled “Core – All Software” to emphasize that these requirements apply universally to all software assessed under the standard. The eleven Security Objectives now cover:

• Security Objective 1: Software Architecture, Composition, and Versioning – including requirements for Bill of Materials (BOM), versioning practices, and the use of wildcards.
• Security Objective 2: Sensitive Asset Identification – relies on the new companion document covers identifying Sensitive Data, Sensitive Resources, Sensitive Functionality, and Sensitive Modes of Operation.
• Security Objective 3: Sensitive Asset Storage and Retention
• Security Objective 4: Sensitive Modes of Operation – applies only when a Sensitive Mode of Operation is present introduces “Strong Authentication.”
• Security Objective 5: Sensitive Asset Protection – including the software design itself as a sensitive asset, and formalizing the concept of “anomalous behavior.”
• Security Objective 6: Sensitive Asset Output – formalizes secure channel requirements.
• Security Objective 7: Random Numbers – covers both leveraging an external RNG and implementing one within the software.
• Security Objective 8: Key Management
• Security Objective 9: Cryptography (a single encompassing requirement for cases not covered elsewhere)
• Security Objective 10: Threats and Vulnerabilities
• Security Objective 11: Secure Deployment and Management – includes implementation guidance and software versioning.

Changes To Modules : Modules are additional requirements that apply on top of the Core – All Software section, based on defined criteria.

• Module A (Account Data Protection): Requirements have been revised to focus specifically on PAN and SAD in relation to PCI DSS.
• Module B (formerly Terminal Software Requirements, now POI Device Software): The module has been retitled and its requirements refined and reduced. Several requirements previously in Module B have been absorbed into the Core – All Software section. SRED requirements have also been revised.
• Module C (formerly Web Software Requirements, now Publicly-accessible Software): The module has been retitled to better reflect its intent. Several requirements from the old C.1 section have been moved to the Core section. Requirements C.1.5 and C.1.6 have been removed, as they are now covered by the PCI Secure SLC Standard.
• Module D (NEW – Software Development Kits): This is an entirely new module. v2.0 is now better suited to accommodate the assessment of SDKs, including EMVCo 3DS SDKs. Module D introduces a new set of objectives and requirements specifically for this category.

Structural And Administrative Changes

Several structural changes have been made to align v2.0 more closely with the broader PCI Standards framework:

• A new “Sensitive Assets” section has been added to the introduction.
• The “Stakeholder Roles and Responsibilities” section has been removed from the standard and relocated to the PCI Secure Software Program Guide.
• The “Scope of Security Requirements” section has been removed entirely.
• Related Publications have been moved to a new Appendix B.
• A new Appendix C covers Technical References.
• SLC-related requirements have been removed from this standard, as they are now covered under the PCI Secure SLC Standard.
• The standard now relies on “Strong Cryptography” as the baseline for cryptographic requirements, replacing the previous “Effective Key Strength” framework.

What This Means For Your Organization

Whether you are a software vendor seeking or maintaining certification, an assessor reviewing compliance, or a payment brand evaluating software, v2.0 represents a meaningful shift. The expanded focus on Sensitive Assets (rather than Payment Software alone) broadens the standard’s applicability. The introduction of Module D makes it relevant to SDK developers for the first time. And the comprehensive rewrite of test requirements means existing assessment processes will need to be revisited.

Organizations currently certified or in the process of certification under v1.2.1 should review the full v2.0 standard and the new Sensitive Asset Identification companion document to understand how requirements map (or don’t map) to their current implementations.

The PCI SSC has made clear that this version is designed to be more structured, more broadly applicable, and better aligned with the evolving software security landscape – including the growing role of SDKs, third-party components, and complex software supply chains.

For the full standard and companion documents, visit the PCI Security Standards Council website at PCIsecuritystandards.org.

Need Help Navigating PCI Secure Software Standard V2.0?

At QRC Assurance and Solutions, we understand that major standard revisions can be complex to interpret and even more challenging to implement. Whether you are a software vendor preparing for assessment under v2.0, an organization reviewing your current certification status, or a development team working through the new Sensitive Asset framework for the first time – our team of qualified security experts is here to guide you every step of the way.

Our services include:

• Gap assessments against PCI Secure Software Standard v2.0
• Pre-assessment readiness reviews
• Support for Module D (SDK) assessments – new to v2.0
• Guidance on the mandatory Sensitive Asset Identification companion document
• End-to-end PCI SSF assessment and certification support

Don’t let a major revision catch your organization off guard. Get ahead of the changes with expert support from a team that lives and breathes payment security compliance. Contact us today to schedule a consultation or learn more about how QRC Assurance and Solutions can help you achieve and maintain compliance with confidence.

Visit us at: www.qrcsolutionz.com | Email us at: connect@qrcsolutionz.com