Payment software vendors can no longer validate under PA-DSS, and the two standards that replaced it both reached version 2.0 in 2026. The PCI Software Security Framework (SSF) consists of the PCI Secure Software Standard, which validates a software product, and the PCI Secure Software Lifecycle (Secure SLC) Standard, which validates a vendor's development lifecycle. PCI SSC released Secure Software Standard v2.0 on 15 January 2026 and Secure SLC Standard v2.0 on 28 September 2026, each with a 12-month transition from the previous version that starts once assessor training is available. This guide explains what each standard covers and who it applies to, what changed in v2.0, where identity and non-human credentials sit in the requirements, how to prepare for assessment, and how the SSF relates to PCI DSS and the NIST SSDF. It is written for product security leads, engineering managers and compliance owners at payment software vendors, and for merchants and service providers choosing validated software. Status checked on the PCI SSC website and blog on 27 October 2026.
Key takeaways
- Two standards, two listings. The Secure Software Standard leads to a listing as Validated Payment Software; the Secure SLC Standard leads to a listing as a Secure SLC-Qualified Software Vendor. Neither standard requires an assessment to the other.
- PA-DSS is retired. PCI SSC says the SSF replaced PA-DSS effective 28 October 2022, and the PA-DSS listing remains only as a historical category.
- v2.0 is built around "sensitive assets". Secure Software v2.0 adds a companion Sensitive Asset Identification document, and Secure SLC v2.0 aligns with that focus and adds content on digital tools including AI.
- Outcomes, not prescribed techniques. PCI SSC describes the SSF as focusing on expected security outcomes rather than specific techniques, which gives flexibility but demands a real risk management process and evidence.
- Validation is not the same as compliance. PCI SSC states that compliance programmes, including whether a listed product is required, are managed by the payment brands; listed software helps a merchant's PCI DSS assessment but does not replace it.
What it is and who it applies to
| Aspect | PCI Secure Software Standard | PCI Secure SLC Standard |
|---|---|---|
| What is validated | A specific software product (and, from v2.0, eligible SDKs) | The vendor's secure software lifecycle processes |
| Intended audience (PCI SSC wording) | "Software vendors that develop payment software to support or facilitate payment transactions" | "Software vendors that develop software that is commonly deployed in a payment environment" |
| Purpose (PCI SSC wording) | Assurance that software is "designed, developed, and maintained in a manner that protects payment-related data and payment-related functionality" | Requirements and assessment procedures that vendors use to build secure practices into their lifecycles and validate them |
| Current version | v2.0 (released 15 January 2026) | v2.0 (released 28 September 2026) |
| Previous version | v1.2.1 | v1.1 |
| Assessor | PCI Secure Software Assessor | PCI Secure SLC Assessor |
| Public listing | Validated Payment Software | Secure SLC-Qualified Software Vendors |
| Main companion documents | Sensitive Asset Identification (for use with v2.x), Program Guide v2.x, Summary of Changes v1.2.1 to v2.0, PCI 3DS Data Matrix v1.2 | Program Guide (for use with v2.x), Summary of Changes v1.1 to v2.0, ROV and AOV templates, SSF Assessor Qualification Requirements (2026) |
PCI SSC notes that a vendor with a listed and validated Secure SLC that uses it to develop products receives programme benefits for its associated listed Secure Software products, which is why many vendors with several products pursue both. Merchants and service providers who build their own payment software do not validate under the SSF; their bespoke and custom software falls under PCI DSS Requirement 6.
For merchants and service providers buying software: PCI SSC encourages use of its listings when selecting payment software or a software vendor. When you rely on a listing, check that the exact product version you deploy is listed, that its validation is current and not in a lapsed transition, and that you follow the vendor's implementation guidance, because deviations from that guidance fall back into your own PCI DSS scope. A Secure SLC-qualified vendor tells you about the vendor's process; it does not on its own validate a specific product. Smaller merchants usually gain most from choosing listed software and following its guidance; larger organisations integrating payment software into custom platforms will still need their own Requirement 6 controls around the integration.
Structure and key requirements
Both standards are written as security objectives, each with requirements and test requirements that an assessor uses. In its comparison of SSF and PA-DSS, PCI SSC highlights four structural differences that still shape how vendors should prepare:
- Outcome-based requirements: PA-DSS often specified techniques or technologies; the SSF focuses on expected security outcomes, so the vendor must show its chosen controls achieve the objective.
- Compensating controls: allowed under the SSF when a technical constraint makes an objective impossible to meet, provided the constraint is documented and justified in the reporting template and additional controls address residual risk. PA-DSS required requirements to be met as written.
- Normative Technical FAQs: SSF Technical FAQs must be considered during assessments, unlike the informative PA-DSS General FAQs. Read them as part of the standard.
- New and extended areas: PCI SSC cites attack detection requirements (Objective 9 in v1.x) as new relative to PA-DSS, and web software requirements in Module C as building on PA-DSS concepts.
What changed in Secure Software Standard v2.0
- Sensitive assets: a new companion document, "PCI Secure Software Standard: Sensitive Asset Identification (for use with v2.x)", helps the vendor identify and document the software's sensitive assets. The request for comments described example tables of sensitive data, sensitive resources and sensitive functionality.
- SDKs: software development kits are now eligible for assessment, including EMVCo 3DS SDKs, providing an alternative path intended eventually to replace the PCI 3DS SDK Standard. The PCI 3DS Data Matrix moved to v1.2 with 3DS SDK sensitive data elements.
- Change handling: wildcards cover non-security-impacting changes, and a revised delta change process uses a new change impact template.
- Portal: annual attestations and administrative changes are submitted through the PCI SSC Portal.
- Restructure: the stated aims during consultation were more objective requirements, removing security requirements embedded in test procedures, and eliminating overlap and redundancy. Use the official v1.2.1 to v2.0 summary of changes for requirement-level mapping.
What changed in Secure SLC Standard v2.0
- First major revision since the standard was introduced in 2019, "refocused solely on a software vendor's Secure SLC".
- Aligned with Secure Software v2.0 and its focus on sensitive assets.
- New content on "digital tools", including accounting for artificial intelligence within the vendor's Secure SLC processes. In practice, expect to show how AI coding assistants and other development tools are governed, configured and reviewed.
- Objective requirements intended to accommodate varying levels of lifecycle maturity.
Identity and NHI requirements
The v2.0 sensitive asset model makes credentials and keys central: they are sensitive data and sensitive resources, and the functions that use them are sensitive functionality. Whatever the final requirement numbering, assessors will expect a vendor to show how each of the following is identified, protected and evidenced:
| Identity element | Where it appears | What good evidence looks like |
|---|---|---|
| Authentication to sensitive functions in the product | Product (Secure Software) | Design documentation of which roles can call which sensitive functions, no default or hard-coded credentials, test results |
| Cryptographic keys and secrets used by the product | Product (Secure Software) | Key inventory in the sensitive asset document, key storage design (for example HSM or platform keystore), rotation and destruction procedures |
| Machine credentials of integrations and APIs | Product, and implementation guidance for customers | Guidance telling customers how to configure service accounts, API keys and certificates securely |
| Code signing and update keys | Product and lifecycle | Signed updates verified by the software, protected signing keys, documented key compromise response. See the Code Signing Security Guide. |
| Developer and pipeline access | Lifecycle (Secure SLC) | MFA for source control, least-privilege CI/CD identities, reviewed access to build and release systems |
| Digital tools and AI assistants | Lifecycle (Secure SLC v2.0) | Inventory of tools, the credentials and data they can reach, and review of their output |
For the merchant side of the same problem, see the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6) and the Cryptographic Key Management Guide.
Implementation steps
- Decide the validation route. One product with occasional releases may justify a Secure Software validation alone; a vendor with several products and frequent releases usually benefits from Secure SLC qualification as well. Ask your acquiring banks and payment brands which they require, as PCI SSC directs compliance questions to the brands.
- Obtain the v2.0 documents. Download the standard, summary of changes, Program Guide and templates from the PCI SSC Document Library and read the normative Technical FAQs.
- Build the sensitive asset inventory. List sensitive data (for example account data and authentication data), sensitive resources (keys, credentials, configuration) and sensitive functionality (for example authorisation, key loading, update installation) using the Sensitive Asset Identification document.
- Threat model against the inventory. For each asset, record threats, mitigations and residual risk. Outcome-based requirements are only defensible with this record. See the Threat Modelling Guide.
- Gap assess current controls. PCI SSC notes most PA-DSS controls can be repurposed; map existing controls to v2.0 objectives and list gaps, especially attack detection, update integrity and secure defaults.
- Close lifecycle gaps. Secure coding standards, code review, SAST and SCA in CI, vulnerability handling with defined timelines, secure update delivery, and governance of digital tools and AI assistants.
- Write implementation guidance. Customers need clear instructions on secure installation, configuration, credential handling and updates.
- Engage an assessor early. Choose a listed assessor of the right type and agree the scope and evidence format before formal assessment.
- Plan the transition. Existing v1.2.1 or v1.1 validations have a 12-month transition window that starts when v2.0 training is available; schedule reassessment inside it.
- Maintain the listing. Submit annual attestations through the Portal and run delta assessments for security-impacting changes.
Evidence and assessment
| Evidence type | Examples | Typical gaps |
|---|---|---|
| Documentation | Sensitive asset document, architecture and data flow diagrams, threat model, secure coding standard | Diagrams that do not match the shipped product |
| Process records | Code review records, SAST and SCA results with triage decisions, vulnerability tickets with timelines | Findings closed without justification |
| Testing | Assessor testing of the product, vendor penetration test reports, test results for authentication and attack detection | No tests of negative cases or tamper detection |
| Interviews | Developers, release managers and security staff | Staff unaware of the documented process |
| Change records | Change impact templates, release notes, signed update records | Security-impacting changes classified as non-impacting |
Measure readiness with a small set of indicators: the share of sensitive assets with a documented threat model and mitigation, open high-severity findings older than the vendor's own remediation target, the share of releases that pass automated security gates, mean time to ship a security fix to listed versions, and the number of security-impacting changes correctly routed through the delta process.
Mapping to other frameworks
| Framework | Relationship |
|---|---|
| PCI DSS v4.0.1 Requirement 6 | Applies to the merchant or service provider's bespoke and custom software, including secure development (6.2.1) and annual secure coding training for developers (6.2.2). Using validated software supports, but does not replace, the entity's own assessment. See the PCI DSS 4.0 Guide. |
| NIST SSDF (SP 800-218) | Secure SLC practices align closely with SSDF groups Prepare the Organisation (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide. |
| NIST SP 800-53 Rev. 5 | SA-3 System Development Life Cycle, SA-11 Developer Testing and Evaluation, SA-15 Development Process, Standards, and Tools, SA-17 Developer Security and Privacy Architecture and Design, SC-12 Cryptographic Key Establishment and Management, IA-5 Authenticator Management |
| NIST CSF 2.0 | PR.PS-06 secure software development; GV.SC-06 and GV.SC-07 for merchants assessing software suppliers |
| MITRE ATT&CK | T1195.002 Compromise Software Supply Chain is the threat that update integrity and lifecycle controls address |
This mapping is our own alignment for orientation; PCI SSC does not publish it.
Common pitfalls
- Treating v2.0 as a renaming exercise: the sensitive asset model requires new documentation that drives the whole assessment.
- Missing the transition window: the 12-month transition starts with training availability, not with a date you control, so track PCI SSC announcements.
- Undocumented compensating controls: they are permitted only with a documented technical constraint and additional mitigation.
- Ignoring Technical FAQs: they are normative and assessors apply them.
- Ungoverned AI and digital tools: Secure SLC v2.0 explicitly brings these into scope; an unrecorded assistant with repository access is now an assessment finding waiting to happen.
- Misclassifying changes: treating a change to authentication or cryptography as non-security-impacting undermines the listing.
Practitioner checklist
- Confirm with acquirers and payment brands which validation they expect for each product.
- Download the v2.0 standards, summaries of changes, Program Guides and Technical FAQs.
- Produce the sensitive asset document for every in-scope product.
- Threat model each sensitive asset and record mitigations and residual risk.
- Inventory keys, secrets, service credentials and signing keys, with owners and rotation procedures.
- Bring AI coding assistants and other digital tools into the Secure SLC with inventory, access limits and review.
- Schedule reassessment inside the 12-month transition window.
- Set up annual attestation and delta change processes in the Portal.
Standards and references
- PCI SSC: Secure Software Standard
- PCI SSC: Secure Software Lifecycle (Secure SLC) Standard
- PCI SSC: PCI SSC Releases Version 2.0 of the PCI Secure Software Standard
- PCI SSC: PCI SSC Releases Version 2.0 of the Secure Software Lifecycle Standard
- PCI SSC: Technical Differences Between SSF and PA-DSS
- PCI SSC: Request for Comments, PCI Secure Software Standard v2.0
- NIST: SP 800-218 Secure Software Development Framework
Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · NIST Secure Software Development Framework (SSDF, SP 800-218) Guide · Secure Code Review Guide · PCI DSS Requirements for Service Accounts and NHIs Guide (8.6). This guide summarises the PCI Software Security Framework and is not legal or compliance advice.