How does PCI SSF v2.0 differ from v1.2.1? PCI Secure Software Standard v2.0, published on 15 Jan 2026, is the standard’s first full revision: it shifts the focus from the payment application to identifying and protecting sensitive assets, introduces the new companion document SAID, simplifies the structure and changes the delta change process. Version 1.2.1 remains valid until the end of the 12-month transition window counted from when training becomes available.
Canonical definition: The PCI Secure Software Standard is one of the two standards in the PCI Software Security Framework (SSF), setting out requirements for securely designing, developing and maintaining payment software, validated by Secure Software assessors.
For a payment software vendor, this is a change to plan now – it determines the scope of the next validation and the deadline for moving to the new standard.
PCI SSF v2.0 vs v1.2.1 – key takeaways:
- PCI Secure Software Standard v2.0 was published on 15 Jan 2026; it is the first full revision since the standard was introduced (PCI SSC blog).
- A new focus: the standard no longer centres primarily on the payment application but on identifying and protecting sensitive assets, supported by the new SAID (Sensitive Asset Identification) document.
- The standard’s structure and terminology were revised, and overlap with the framework’s other standard – PCI Secure Software Lifecycle (SLC) – was reduced.
- The delta change process was updated with a new Change Impact template, and wildcards were introduced for non-security-impacting software changes (PCI SSC blog).
- The v2.x templates (ROV, AOV, Change Impact) were expected in early February 2026 and the CBT training in Q1 2026; once training is available, a 12-month transition window from v1.2.1 to v2.0 begins.
- Patronusec, an accredited QSA, supports payment software vendors in preparing for SSF validation – from sensitive asset identification to the move to v2.0.
Table of Contents
What is the PCI Software Security Framework and the Secure Software Standard?
The PCI Software Security Framework (SSF) is the framework that replaced the former PA-DSS standard, made up of two standards: the Secure Software Standard (validating a specific piece of software) and the Secure Software Lifecycle Standard (validating a vendor’s development process). It applies to third-party vendors of payment software sold to merchants and service providers.
PCI SSF was created to replace PA-DSS with a more flexible approach supporting different types of payment software, technologies and development methodologies. The PA-DSS programme was retired: new submissions were not accepted after 30 Jun 2021, and programme support ended on 30 Oct 2022. Since then, payment software validation happens within the SSF.
The distinction between the framework’s two standards is key for a vendor:
- Secure Software Standard (SSS) – validates a specific product: whether the software is designed, developed and maintained to protect transactions and data, minimise vulnerabilities and defend against attacks. The result is the product’s entry on the Validated Payment Software list.
- Secure Software Lifecycle Standard (SLC) – validates the vendor’s process: the secure development lifecycle practices that keep the software secure over time and manage changes.
PCI SSF replaced the PA-DSS model of a fixed control checklist with an objective-based approach – the vendor demonstrates how it meets an objective instead of ticking off a predefined list of requirements.
What exactly does version 2.0 change relative to 1.2.1?
Version 2.0 is the first full revision of the Secure Software Standard: it rebuilds the structure, shifts the focus to sensitive assets, reduces overlap with the SLC and modernises the change process. Version 1.2.1 was the last of the 1.x line, to which the Web Software Module had earlier been added (in 1.2).
The most important changes, per the PCI SSC blog and the Council’s announcements:
- A new focus on sensitive assets. The standard no longer centres primarily on the payment application but on identifying and protecting sensitive assets – any element of a product whose unauthorised access, use or modification could compromise security. This is supported by the new companion document SAID (Sensitive Asset Identification).
- A rebuilt structure and terminology. The requirements were reorganised for easier navigation and the terminology aligned; overlap with the framework’s other standard (SLC) was also reduced.
- A modernised delta change process. A new Change Impact template and the introduction of wildcards to account for non-security-impacting software changes – which directly affects day-to-day listing maintenance.
- Portal and listing improvements. Portal access for vendors to submit annual attestations and administrative changes, plus improved portal and listing features.
- A link to 3DS. As part of the transition, the PCI 3DS Data Matrix was updated to version 1.2, which now includes 3DS SDK sensitive data elements.
The deepest change in SSF v2.0 is not about a single requirement but about the philosophy of scope: v1.2.1 asked “how do you protect the payment application”, while v2.0 asks “which sensitive assets do you have in the product and how do you protect each one”.
How does the shift to sensitive assets affect a vendor?
Shifting the focus to sensitive assets means the vendor first identifies and documents all assets requiring protection, and only then selects controls for them – instead of meeting a list of requirements assigned in advance to the payment application. This is a methodological change, not a cosmetic one.
A sensitive asset, in the standard’s terms, is any element of a product (including the product itself) whose unauthorised access, use or modification could compromise security. The new SAID document supports vendors in identifying and documenting such assets – it becomes the starting point of the whole validation.
The practical consequences for a vendor:
- A different validation starting point. Rather than a control list, the project begins with an inventory of sensitive assets – keys, credentials, security logic, the critical code itself.
- A broader scope definition. An asset-based approach can capture elements the “payment application” model did not directly address – a chance for precision, but also a risk of underestimating scope if identification is superficial.
- More responsibility on the vendor. The vendor itself demonstrates which assets it holds and how it protects them, instead of ticking a predefined list – which rewards mature teams and exposes improvisation.
The fix: the first task in an SSF v2.0 project is no longer a control review but a thorough, documented identification of sensitive assets – and it is this that will determine the scope and cost of validation.
Is your software validated to SSF v1.2.1 and you’re unsure how to prepare for v2.0?
Patronusec performs an SSF v2.0 readiness review: we identify your product’s sensitive assets using the SAID approach, map them onto existing controls and flag gaps against the new standard structure. Within 10 working days you receive a written readiness report and a transition plan.
Order an SSF v2.0 readiness review
What does the transition window and v2.0 rollout timeline look like?
Once assessor training becomes available, a 12-month transition window opens in which vendors may still validate to v1.2.1 or already to v2.0. The v2.0 standard was published on 15 Jan 2026, and the supporting materials were released in stages through Q1-Q2 2026.
The timeline, per PCI SSC announcements:
- 15 Jan 2026 – publication of PCI Secure Software Standard v2.0 in the PCI SSC Document Library.
- early February 2026 – expected release of the v2.x templates: ROV (Report on Validation), AOV (Attestation of Validation) and the new Change Impact.
- Q1 2026 – expected v2.0 CBT (computer-based training) for existing Secure Software assessors; instructor-led training (ILT) for new assessors planned for Q2.
- transition window opening – the 12-month period to move from v1.2.1 to v2.0 begins once training is available.
For a vendor this means a decision window, not an immediate mandate. A product validated to v1.2.1 remains valid per the programme rules, but the next validation and listing maintenance will move to v2.0. Whether to squeeze in one more v1.2.1 validation or prepare for v2.0 straight away is best decided on the product’s lifecycle and the next validation date, rather than deferred to the window’s end.
The SSF transition window is not a deferral of the obligation but a decision window: the vendor picks the moment to move to v2.0 within 12 months of training becoming available, matching it to its own validation cycle.
What should a software vendor do right now?
A vendor should already identify its product’s sensitive assets, compare current controls against the new v2.0 structure and plan the transition point within the 12-month window. Early preparation turns the standard change from a risk into an orderly project.
A v2.0 preparation checklist:
- Identify sensitive assets using the SAID approach – the starting point of the whole v2.0 validation, not a task for the end of the project.
- Map current controls onto the new structure – check where v1.2.1 requirements translate directly to v2.0 and where the philosophy change requires new evidence.
- Review the delta change process – adapt it to the new Change Impact template and the wildcard mechanism for non-security-impacting changes.
- Set the transition point – weigh the next validation date and the product lifecycle against the 12-month window, rather than waiting for its end.
- Verify the relationship with SLC – check whether reducing the overlap between standards changes the scope of your development-process validation.
- Plan the evidence – asset identification and an objective-based approach require different documentation from ticking the v1.2.1 control list.
Patronusec supports payment software vendors through this transition within its PCI SSF audit and preparation service – from sensitive asset identification to a transition plan matched to the product’s validation cycle.
FAQ – PCI SSF v2.0
When will PCI SSF v1.2.1 stop applying?
Version 1.2.1 remains valid until the end of the 12-month transition window, which opens once assessor training for v2.0 becomes available. The v2.0 standard was published on 15 Jan 2026, with training and templates released in stages through Q1-Q2 2026. Products validated to v1.2.1 remain valid per the programme rules.
Does a v1.2.1 validation lose validity when v2.0 is released?
Not automatically. A product validated to v1.2.1 remains valid per the programme rules through the transition window. The move to v2.0 happens at the next validation or a significant change requiring reassessment. The timing of the transition is best decided on the product’s lifecycle.
What is SAID in PCI SSF v2.0?
SAID (Sensitive Asset Identification) is a new companion document to the v2.0 standard that supports vendors in identifying and documenting sensitive assets. A sensitive asset is any element of a product whose unauthorised access, use or modification could compromise security. SAID becomes the starting point of a v2.0 validation.
Does PCI SSF apply to software built for internal use?
No. PCI SSF applies to third-party vendors of payment software sold to merchants and service providers. Software built by a merchant or service provider for its own internal use is not subject to SSF validation – though the card data processing environment itself remains subject to PCI DSS.
How does the Secure Software Standard differ from the Secure Software Lifecycle?
The Secure Software Standard (SSS) validates a specific product – its security and integrity. The Secure Software Lifecycle (SLC) validates the vendor’s development process – its secure software lifecycle practices. They are two separate SSF standards; v2.0 of the SSS reduced overlap with the SLC for a clearer division of scope.
How long does preparing for SSF validation with Patronusec take?
The Secure Software Standard (SSS) validates a specific product – its security and integrity. The Secure Software Lifecycle (SLC) validates the vendor’s development process – its secure software lifecycle practices. They are two separate SSF standards; v2.0 of the SSS reduced overlap with the SLC for a clearer division of scope.
Recommended reading
A reading path for payment software security:
- PCI Secure Software Framework (SSF): a key standard for payment software security – the foundation: what the SSF framework and its two standards are.
- P2PE component, solution and application – validation routes for providers – why P2PE application validation does not replace SSF.
- What is a 3DS SDK – requirements and use cases – on-device payment software and its separate standards.
- PCI DSS compliance: navigating the scope without confusion – how payment software relates to the CDE.
PCI SSF v2.0 – free consultation
Patronusec, an accredited QSA, supports payment software vendors in PCI SSF validation – we work with clients across the fintech, e-commerce and financial sectors. In a free 30-minute consultation we will help you:
- identify your product’s sensitive assets using the SAID approach,
- map current v1.2.1 controls onto the new v2.0 structure,
- set the optimal transition point within the 12-month window,
- plan evidence and documentation for the asset-based approach.
Book a consultation | PCI SSF audit | PCI SLC | PCI DSS certification | PCI gap analysis
