Throughout part of 2024 and all of 2025, a major update to the PCI Secure Software Standard was developed, culminating in its publication on January 15, 2026, under version 2.0.
This new version eliminates the term “Payment Application” and introduces a new context called “Sensitive Assets,” which must be documented thoroughly and accurately. To facilitate this process, a new document titled “PCI Sensitive Assets Identification – For use with the PCI Secure Software Standard v2.x” has been introduced. It provides definitions and categorizations of sensitive assets referenced by the secure applications standard, including examples and an optional appendix (Appendix A) that software development providers can use to supply all the required information for audit processes.
The second document is the standard itself: PCI Secure Software Standard v2.0, which includes new and updated requirements. The most significant changes in this version are:
Major Changes
◾The “Payment Application” context has been removed.
◾The sensitive assets context has been redesigned.
◾Testing requirements have been rewritten and now heavily rely on documentation review, static and dynamic testing.
◾Key definitions have been updated.
◾The term “Control Objectives” has been replaced with “Security Objectives,” reflecting a philosophical shift in the standard.
◾A new module for SDK-type applications has been added, offering an alternative certification path for 3DS SDKs, and the PCI 3DS Data Matrix document has been updated to version 1.2.
New Elements Introduced
◾A new list is required for identifying sensitive operations.
◾A Software Bill of Materials (SBOM) and its dependencies must be provided.
◾Multi-factor authentication (MFA) is now mandatory for sensitive operations.
◾Greater granularity is required in generated logs.
◾Exported logs must be encrypted.
◾Suspicious event logs must be generated and encrypted.
◾Changes have been made to the expected content of the implementation guide.
Other Changes to the Standard
◾Redundancies have been removed within the standard itself, across modules, and between the secure applications standard and the lifecycle standard.
◾All security requirement expressions have been removed from the section referencing necessary compliance testing.
◾Requirement wording has been revised to improve objectivity.
◾The organization and flow of the standard, especially the main body, have been restructured.
◾The association between PAN/SAD and PCI DSS has been strengthened.
◾The glossary is now included as part of the standard.
Program Changes
◾The rollback of wildcard version handling has been reversed; wildcards are now accepted again for changes that do not impact security.
◾Delta evaluations for significant changes are once again allowed, and the change impact template has been updated.
◾Certified SLC entities receive additional benefits regarding annual validations for certain types of changes.
Regarding other elements that require updates and define the transition process, it has been announced that supporting documentation (ROV, AOV) will be published in February 2026. Computer-Based Training (CBT) will be updated during the first quarter of the year, and instructor-led training will be updated during the second quarter. Once training is published, a 12-month transition window will begin between version 1.2.1 and version 2.0.
A quick overview of the standard reveals a redistribution of requirements into 11 security objectives and 4 modules, each with its own security objectives.
Security Objectives Distribution:
| Core | All Software |
| Security Objective 1 | Software Architecture, Composition, and Versioning |
| Security Objective 2 | Sensitive Asset Identification |
| Security Objective 3 | Sensitive Asset Storage and Retention |
| Security Objective 4 | Sensitive Modes of Operation |
| Security Objective 5 | Sensitive Asset Protection Mechanisms |
| Security Objective 6 | Sensitive Asset Output |
| Security Objective 7 | Random Numbers |
| Security Objective 8 | Key Management |
| Security Objective 9 | Cryptography |
| Security Objective 10 | Threats and Vulnerabilities |
| Security Objective 11 | Secure Deployment and Management |
| Module A | Account Data Protection |
| Security Objective 1A | Securing Account Data |
| Module B | POI Device Software |
| Security Objective 1B | PTS Approval |
| Security Objective 2B | Approved POI Device Functionality |
| Security Objective 3B | Authentication |
| Module C | Publicly-accessible Software |
| Security Objective 1C | HTTP Headers |
| Security Objective 2C | Input Protection Mechanisms |
| Security Objective 3C | Session Management |
| Security Objective 4C | User Authentication |
| Module D | Software Development Kits |
| Security Objective 1D | SDK Integrity |
Conclusion
This new standard is an evolution that brings clarity and removes redundancies across requirements, while incorporating elements needed by applications in today’s environments. Although no specific dates have been set for mandatory adoption, the projected timeline suggests that the transition will be completed in approximately 18 months. Therefore, it is essential to analyze the changes now, as applications will need to be updated to align with the new requirements and implementation guide. This means conducting a gap analysis as soon as possible, since these changes may require significant time and resources to implement.
