PCI Secure Software Standard: Validating Payment Software and SDKs

The PCI Secure Software Standard is part of the PCI Security Standards Council's Software Security Framework, which replaced the older Payment Application Data Security Standard (PA-DSS). It validates that specific software products protect payment data and other sensitive assets through secure design, development and maintenance. Its companion, the Secure Software Lifecycle (Secure SLC) Standard, validates a vendor's development processes as a whole.

Version 2.0 of the Secure Software Standard took effect in January 2026, alongside the previous version. It shifts to a principles-based focus on sensitive assets, adds a module for software development kits, requires assessors to review source code, and introduces a tiered approach to updates. This guide explains the framework, both standards, modules, the validation process, the transition from PA-DSS and how the standards relate to PCI DSS.

What is the PCI Software Security Framework?

The PCI SSC launched the Software Security Framework (SSF) in 2019 to address modern software development, which had outgrown PA-DSS. The SSF contains two standards with separate validation programmes:

• PCI Secure Software Standard: requirements for the security of a specific software product, validated by a Secure Software Assessor and listed on the PCI SSC website.
• PCI Secure SLC Standard: requirements for a vendor's secure software lifecycle practices, validated by a Secure SLC Assessor, after which the vendor is listed as Secure SLC Qualified.

PA-DSS was retired on 28 October 2022. Existing PA-DSS validated applications moved to a status indicating they are acceptable only for pre-existing deployments, and new validations use the SSF.

From PA-DSS to the Software Security Framework

PA-DSS was designed for installed payment applications in the 2000s, with prescriptive requirements tied to card data storage and specific technologies. As software moved to cloud services, APIs, mobile apps, continuous delivery and microservices, its approach became hard to apply. The SSF was designed to be outcome-based and technology-neutral, to cover a broader range of software, and to recognise vendors that build security into their development lifecycle. The split into product validation and lifecycle validation lets mature vendors manage frequent releases without a full reassessment for every change.

Sensitive assets explained

Version 2.0 centres on sensitive assets: data, functions and resources that must be protected because their compromise could harm payment security. Cardholder data and sensitive authentication data are obvious examples, but sensitive assets also include cryptographic keys, authentication credentials, security configuration, and functions that process or move payment data. Vendors document these in a sensitive asset identification document, then show how each is protected in storage, in transit and in use, and how access is controlled. This approach lets the standard apply to software that does not directly store card numbers but still plays a security-critical role in payments.

Who should use it?

• Payment software vendors, including POS systems, payment gateways' client components, and software on payment terminals.
• SDK providers whose libraries are embedded in merchant or partner applications to handle payment data.
• Vendors of publicly accessible software, such as web-based payment pages and services.
• Merchants and acquirers choosing validated software to reduce risk.

Is it mandatory or voluntary?

Voluntary under PCI SSC rules, but frequently required by payment brands, acquirers, processors or enterprise customers. Using validated software can support a merchant's PCI DSS compliance, but does not make the merchant compliant on its own.

Secure Software Standard v2.0

Version 2.0, with its programme guide, took effect in January 2026 and can be used alongside v1.x during a transition. According to published analyses, key changes include:

• Sensitive asset focus: the standard moves away from a narrow "payment software" classification to protecting sensitive assets, documented in a mandatory sensitive asset identification document.
• Security objectives: control objectives are renamed security objectives, with a set of core objectives and a baseline of strong cryptography rather than long lists of specific technical requirements.
• Modules: a new module for SDKs; a module for publicly accessible software, replacing the former web software module; and a simplified module for point-of-interaction device software.
• Source code access: vendors must provide source code to the assessor, with testing combining document review, static analysis and dynamic analysis.
• Update tiers: low-impact changes are Tier 1 and high-impact changes Tier 2; Secure SLC qualified vendors can self-approve certain Tier 1 security patches, while Tier 2 changes need assessor involvement.
• Versioning and listings: wildcard versioning reduces re-registration for minor updates, and listings are flagged and then expire if annual requirements are missed.
• Vulnerability reporting: standardised expectations using CVSS or an equivalent scoring method.

Secure Software Standard v1.x

Many products remain validated under v1.x, which organised requirements into core control objectives covering minimising the attack surface, software protection mechanisms, secure software operations and the secure software lifecycle, with modules for account data protection, terminal software and web software. Vendors with v1.x validations should plan their move to v2.0 as PCI SSC confirms retirement dates for v1.x.

Secure SLC Standard

The Secure SLC Standard assesses whether a vendor has a mature, documented secure development lifecycle: governance, threat identification, vulnerability detection and mitigation, change management, software integrity protection, security in release and update processes, and stakeholder communication. A draft v2.0 was published for comment in 2025, and reports indicate v2.0 was released in September 2026, introducing a lifecycle steward role, an objective on secure software retirement, and new reporting documents, with a transition period from v1.1 once assessor training is available. Being Secure SLC Qualified also allows faster update approvals under the Secure Software Standard.

The validation process

1. Determine eligibility and scope: which product, version and modules apply.
2. Prepare documentation: architecture, sensitive asset identification, threat model, cryptography, configuration guidance and vulnerability management.
3. Engage a Secure Software Assessor listed by PCI SSC.
4. Assessment: document review, source code review, static and dynamic testing, and evidence of controls.
5. Report submission to PCI SSC and payment of listing fees.
6. Listing on the PCI SSC website as validated software.
7. Maintenance: annual attestations and assessment of updates according to their tier.

What assessors look for

• Identification of sensitive assets and functions, and protection of them throughout their lifecycle.
• Strong cryptography with sound key management.
• Authentication and access controls for sensitive functions.
• Secure defaults and minimal attack surface.
• Input validation and protection against common attacks.
• Logging of security-relevant events without exposing sensitive data.
• Threat modelling and secure design documentation.
• Vulnerability detection, remediation and disclosure processes.
• Secure update mechanisms and integrity protection.
• Clear implementation guidance for customers.

Maintaining a listing

Validation is not permanent. Vendors must submit annual attestations confirming that listed software continues to meet the standard and that vulnerability management continues, and must have changes assessed according to their impact. Under v2.0, a missed annual deadline flags the listing, and if not resolved within a set period, the listing expires and a full reassessment is needed. Wildcard version numbering allows minor non-security updates without re-registration. Vendors should build these obligations into release management so listings stay current alongside rapid development.

SDKs and mobile payments

Payment SDKs are embedded in other companies' applications, which creates particular risks: the SDK must protect sensitive assets even when the host app is not under the vendor's control. The v2.0 SDK module addresses this with requirements on secure integration guidance, protecting data and keys within the host environment, and integrity checks. For accepting card payments on commercial off-the-shelf mobile devices, PCI SSC has separate standards, such as Mobile Payments on COTS (MPoC), with their own validation programmes. Vendors of mobile payment acceptance solutions should check which standard fits their product.

Choosing validated software as a merchant or acquirer

Merchants and acquirers can check the PCI SSC website for validated software and Secure SLC Qualified vendors. When evaluating listings, confirm the product version matches what will be deployed, read the vendor's implementation guidance and follow it exactly, check the listing status and expiry, and remember that configuration and integration choices can undo the software's protections. Validated software reduces risk and may simplify parts of a PCI DSS assessment, but the merchant's environment still needs its own controls.

Benefits and limitations

• Benefits: recognised assurance for payment ecosystem partners, faster sales to acquirers and enterprises, clearer security design, and, with Secure SLC qualification, more efficient update approvals.
• Limitations: validation costs and time, ongoing annual obligations, and the need for source code access under v2.0; validation covers the listed product and version, not every deployment.

How it relates to PCI DSS

Aspect	Secure Software Standard	PCI DSS
Applies to	Software products and vendors	Entities that store, process or transmit cardholder data
Assessed by	Secure Software Assessors	QSAs or self-assessment
Outcome	Listed validated software	Report or self-assessment of compliance
Relationship	Validated software supports DSS compliance	Requirement 6 covers security of custom-built software

Preparing your engineering team

Teams that pass validation smoothly usually treat it as an engineering project rather than a paperwork exercise. Practical preparation includes running a threat modelling workshop for the product, reviewing every place sensitive assets are stored, transmitted or logged, replacing custom cryptography with standard libraries, adding static and dynamic analysis to the build pipeline, reviewing third-party components and their vulnerabilities, writing clear implementation guidance for customers, and rehearsing how the team responds to vulnerability reports. A pre-assessment by the chosen assessor can reveal gaps early. Because v2.0 requires source code review, code quality and readability also affect how quickly the assessment proceeds.

Secure development practices the standards expect

Both standards expect secure development to be built into everyday work: security requirements defined at design, peer code review with security focus, automated testing including security tests, controlled builds with integrity protection, managed dependencies, documented change control, and a process to receive, assess and fix vulnerabilities with timely customer notification. These overlap strongly with frameworks such as OWASP SAMM and the NIST SSDF, so vendors already following them have a head start.

Documentation you will need

• Sensitive asset identification document.
• Architecture and data flow diagrams.
• Threat model and security design documentation.
• Cryptographic design and key management description.
• Source code and build instructions for the assessor.
• Test results and vulnerability management records.
• Implementation and configuration guidance for customers.
• Secure SLC documentation if seeking qualification.

Timeline and cost considerations

Validation typically takes several months, depending on product complexity, documentation readiness and remediation needs. Products with clean architecture, documented threat models and automated testing move through assessment much faster than those where security knowledge lives only in a few engineers' heads. Costs include assessor fees, PCI SSC listing fees, engineering time for fixes, and ongoing costs for annual attestations and update assessments. Vendors with strong secure development practices and Secure SLC qualification can reduce the cost of maintaining validations over time.

Common mistakes

• Treating validation as a one-off rather than maintaining it through updates.
• Weak or homegrown cryptography.
• Sensitive data in logs or debug output.
• Incomplete threat models.
• Poor customer guidance, leading to insecure deployments.
• Not budgeting for the v2.0 transition and source code review.

Best practices, tools and technologies

• Use well-reviewed cryptographic libraries and hardware-backed key storage.
• Tokenise card data wherever possible to reduce scope.
• Run static and dynamic analysis in CI.
• Maintain an SBOM and monitor third-party components.
• Follow OWASP ASVS for application security requirements and NIST SSDF for lifecycle practices.
• Publish a vulnerability disclosure policy.

We build payment integrations, SDKs and e-commerce payment flows with tokenisation, strong cryptography, code review and security testing through our API integration and e-commerce services.

Real-world example

A fintech company with engineering in India builds a mobile payments SDK used by merchants' apps. An acquirer requires validation before allowing the SDK on its network. The company documents sensitive assets, threat models the SDK, replaces a custom encryption routine with a well-reviewed library, removes card data from crash logs, and prepares source code for the assessor under the v2.0 SDK module. After remediation, the SDK is listed by PCI SSC, and the company pursues Secure SLC qualification so it can self-approve low-impact security patches.

Next steps

1. Confirm whether customers or acquirers require validation.
2. Identify sensitive assets and the right module.
3. Prepare documentation and source code.
4. Engage a Secure Software Assessor.
5. Plan Secure SLC qualification.

Frequently asked questions

What replaced PA-DSS?

The PCI Software Security Framework, with the Secure Software Standard and the Secure SLC Standard.

When did PA-DSS end?

PA-DSS was retired on 28 October 2022, and its validated applications moved to a pre-existing deployments status.

What is new in Secure Software Standard v2.0?

A focus on sensitive assets, renamed security objectives, an SDK module, mandatory source code review, and tiered update rules.

When did v2.0 take effect?

In January 2026, available alongside v1.x during the transition.

Is validation mandatory?

Not under PCI SSC rules, but acquirers, payment brands and customers often require it.

Does validated software make a merchant PCI DSS compliant?

No. It helps, but merchants must still meet PCI DSS for their environment.

What is a Secure SLC Qualified vendor?

A vendor whose secure software lifecycle has been validated against the Secure SLC Standard.

Who performs assessments?

Secure Software Assessors and Secure SLC Assessors qualified by PCI SSC.

Do assessors need source code?

Under v2.0, vendors must provide source code to the assessor.

Are mobile payment solutions covered?

SDKs are covered by the new module; separate PCI standards also exist for mobile payments on commercial devices.

How long does a validation stay valid?

Listings are maintained through annual attestations and update assessments; missed deadlines can lead to expiry and a full reassessment.

Can I still use PA-DSS validated applications?

Only in pre-existing deployments; new validations and new deployments should use software validated under the Software Security Framework.