PA-DSS: What It Was, Why It Was Retired and What Replaced It

PA-DSS in one paragraph

PA-DSS stands for the Payment Application Data Security Standard. It was the PCI Security Standards Council (PCI SSC) standard for commercial payment software: applications that a vendor sells or licenses to merchants and that store, process or transmit card data. PA-DSS is a retired standard. PCI SSC closed it, together with its validation and listing program, on 28 October 2022, and replaced it with the PCI Software Security Framework (SSF): the PCI Secure Software Standard and the PCI Secure Software Lifecycle (Secure SLC) Standard. A PA-DSS listing never made a merchant PCI DSS compliant on its own, and PCI DSS itself is a different standard that is still very much in force, currently as version 4.0.1.

Full form: Payment Application Data Security Standard.
Owner: PCI SSC, which took it over in 2008 from Visa’s Payment Application Best Practices (PABP) program.
Status: retired on 28 October 2022. Every former listing is expired.
Replaced by: the PCI Secure Software Standard (for the product) and the PCI Secure SLC Standard (for the vendor’s development process).
Not a substitute for: a PCI DSS assessment of the environment the software runs in.

Is PA-DSS still valid? Its status in 2026

No. Since 28 October 2022 PCI SSC no longer validates applications against PA-DSS, no longer qualifies PA-DSS assessors and no longer lists new applications. The last date for submitting a new application for PA-DSS validation was 30 June 2021.

The old list of validated payment applications is still published on the PCI SSC website, but it is marked as closed. Every entry was moved to the category Acceptable Only for Pre-Existing Deployments and is treated as expired. That label means something narrow: an organization that bought and deployed the application before its expiry date may keep using it as far as the PA-DSS program is concerned, and PCI SSC does not ask for it to be revalidated. It does not mean the software is secure today, that the vendor still supports it, or that it meets current requirements.

PCI SSC sends questions about continued use of expired software to the acquirer or the payment brands. Whether an old application is still acceptable for a particular merchant’s compliance is their decision, not the software vendor’s.

So if you are evaluating payment software in 2026, a PA-DSS listing tells you about a past assessment of a past version. It is not evidence of current software validation.

What was PA-DSS?

PA-DSS began as Visa’s Payment Application Best Practices. PCI SSC announced it as an industry standard on 15 April 2008, backed by the five card brands that then made up the Council: American Express, Discover, JCB, Mastercard and Visa.

The idea was simple. A merchant can do everything right and still leak card data if the off-the-shelf software at the till keeps data it should have thrown away, or ships with defaults that undermine the merchant’s own controls. PA-DSS put requirements on the software vendor instead, so that the application a merchant installed would not be the weak link in its PCI DSS compliance.

The mechanics were product-based. A vendor sent a specific version of its application to a Payment Application Qualified Security Assessor (PA-QSA), who tested it in a lab. If the assessment passed and PCI SSC accepted the report, that version appeared on the Council’s list of validated payment applications, with an expiry date. The vendor also had to give customers an implementation guide explaining how to install and configure the application without breaking PCI DSS.

The standard went through several versions:

v1.1 (2008), the first PCI SSC version, then v1.2 (October 2008) and v1.2.1 (July 2009)
v2.0 (October 2010), aligned with PCI DSS 2.0
v3.0 (November 2013) and v3.1 (May 2015)
v3.2 (May 2016), the final version; its validations all expired on 28 October 2022

Who did PA-DSS apply to?

PA-DSS applied to software that handles cardholder data while authorizing or settling card transactions, and that a vendor sells, licenses or otherwise distributes to other organizations. Typical examples were point-of-sale and payment applications installed at merchant sites, payment modules inside larger software products, and, if the vendor chose, applications running on standalone payment terminals.

Two kinds of software were outside it:

applications a merchant or service provider built only for its own use, which are assessed as part of that organization’s own PCI DSS assessment;
payment software offered purely as a hosted service that customers cannot install or control, which falls under the provider’s own PCI DSS assessment.

“PA-DSS compliant”, “certified” and “listed”

All three phrases are still common. PCI SSC’s own terms were validated and listed: one version of an application had been assessed by a PA-QSA, accepted by the Council and published on the list. Vendors often marketed this as “PA-DSS certified” or “PA-DSS compliant”. Whatever the wording, it now describes a historical validation of a specific version. There is no PA-DSS certification left to obtain.

PA-DSS vs PCI DSS

The two standards were designed to work together, which is exactly why they are confused. The difference is what gets assessed.

PCI DSS applies to an organization: a merchant, a service provider or anyone else handling account data. It covers the whole cardholder data environment, meaning networks, systems, people, processes and every application inside it.
PA-DSS applied to a product: one version of one commercial payment application, tested in a lab.

A validated application helped a merchant mainly because it did not store prohibited data and supported controls the merchant needed, such as individual user accounts, logging and encryption. But that only held if it was installed as the implementation guide described, in an environment that itself met PCI DSS. PCI SSC was explicit that using a PA-DSS validated application did not by itself make an organization PCI DSS compliant, and the application stayed in scope of the merchant’s own PCI DSS assessment. PCI SSC says the same about software validated under the Software Security Framework today.

	PCI DSS	PA-DSS
What is assessed	An organization’s cardholder data environment	A specific version of a commercial payment application
Who is responsible	The merchant or service provider	The software vendor
How it is validated	Assessment by a QSA, or a self-assessment questionnaire, as the acquirer or payment brands require	Lab assessment by a PA-QSA, then a listing by PCI SSC
Status in 2026	Active; v4.0.1 is the only active version	Retired on 28 October 2022

For the related question of how card-industry security standards differ from chip-card requirements, see the difference between EMV and PCI compliance.

What did PA-DSS focus on?

Without restating the requirements themselves, the controls clustered around a set of themes that still matter to anyone writing payment software:

Not keeping what you don’t need. The first and best-known requirement: no sensitive authentication data after authorization (see the table below), including in logs, debug files and crash dumps.
Protecting the card data you do keep. Masking the card number on screen, making stored card numbers unreadable, and managing the cryptographic keys properly.
Cleaning up after older versions. Removing data and key material that earlier releases of the same application had left behind.
Access and authentication. Individual accounts and strong authentication for anyone who can reach card data, with no shared or default credentials.
Logging. Recording access to card data and administrative actions in a way a merchant could feed into its own central logging.
Secure development. Developer training, code review, testing for common vulnerabilities, removing test accounts and test data before release, and controlled change management.
Network exposure. Not depending on insecure services, configuring wireless securely where the application used it, and never storing card data on a server that faces the internet.
Remote access and updates. Strong authentication for vendor remote access and a secure way to deliver patches.
Data in transit. Encrypting card data sent over public networks, and never sending card numbers unprotected by email or chat.
Documentation and training. The implementation guide, plus training for customers, resellers and integrators who installed the application.

What may and may not be stored after authorization

This rule was PA-DSS Requirement 1, and the same rule now sits in PCI DSS v4.0.1 Requirement 3.3.1. It is the point about payment applications that comes up most often, including in training and exam questions.

Data element	Category	After authorization
Full track data from the magnetic stripe, or its equivalent on the chip	Sensitive authentication data	Must not be kept, even if encrypted
Card verification code (CVV2, CVC2, CID, CAV2)	Sensitive authentication data	Must not be kept, even if encrypted
PIN and PIN block	Sensitive authentication data	Must not be kept, even if encrypted
Primary account number (PAN)	Cardholder data	May be kept where there is a business need; must be made unreadable when stored
Cardholder name, expiration date, service code	Cardholder data	May be kept where there is a business need; must be protected

So for the familiar question “Which of the following is not permitted to be stored after authorization, even if encrypted: expiration date, service code, cardholder name, magnetic stripe data or masked PAN?” the answer is magnetic stripe data. The other four are cardholder data that may be retained if protected. Card issuers, and companies supporting issuing services, have a narrow, separately controlled exception.

For what a track actually contains, see data layout on magnetic stripe cards; for how card verification values are derived, see computing card verification values.

Why was PA-DSS retired?

PA-DSS was written for a world of installed software: a vendor shipped a release, a lab tested that release against a fixed list of controls, and merchants ran it on their own machines for years. Payment software no longer looks like that. It is delivered as cloud services, mobile apps, SDKs and APIs, and it changes continuously rather than in occasional releases.

PCI SSC’s stated reason for moving on was that payment software had changed, in how it is architected and in how it is developed, and that it faces more complex attacks than before, so a different kind of standard was needed. The replacement does two things differently. It separates the question “is this product secure?” from “does this vendor build and maintain software securely?”, and it is built around security objectives, so a vendor can show that an objective is met in more than one way, instead of following one prescriptive set of controls written for one style of software.

The handover was gradual. PCI SSC published the new standards in January 2019 and ran both programs side by side. New PA-DSS submissions stopped on 30 June 2021, and on 28 October 2022 the remaining validations expired and the program closed.

What replaced PA-DSS: the PCI Software Security Framework

The PCI Software Security Framework is made up of two standards, each with its own validation program, its own assessors and its own public list.

PCI Secure Software Standard

This is the closest successor to PA-DSS. It validates the security of a payment software product. Assessments are carried out by Secure Software Assessors, and validated products appear on PCI SSC’s list of Validated Secure Software (previously described as Validated Payment Software). Version 2.0 was published in January 2026 as the first major revision, replacing v1.2.1. It also brings software development kits, including EMVCo 3DS SDKs, into scope. PCI SSC has said a 12-month transition from v1.2.1 to v2.0 begins once v2.0 assessor training is available.

PCI Secure Software Lifecycle (Secure SLC) Standard

This standard has no PA-DSS equivalent. It validates the vendor rather than a single product: how it designs, builds, tests, releases and maintains payment software over time. Assessments are carried out by Secure SLC Assessors, and qualified vendors appear on PCI SSC’s list of validated secure software lifecycles. Version 2.0 was published in September 2026, replacing v1.1, again with a 12-month transition that starts once training is available.

The PA-QSA program closed with PA-DSS. Assessors who wanted to keep evaluating payment software had to qualify under the new framework as Secure Software Assessors, and PCI SSC removed the PA-QSA list.

None of this changes what PCI DSS asks of merchants. Software validated under the new framework still has to be deployed in an environment that meets PCI DSS, and it does not replace a PCI DSS assessment.

PA-DSS vs PCI DSS vs PCI SSF at a glance

Framework	Purpose	Applies to	Status (October 2026)
PA-DSS	Validate one version of a commercial payment application	Vendors of payment software sold or licensed to third parties	Retired on 28 October 2022; former listings expired
PCI DSS	Protect account data wherever an organization stores, processes or transmits it	Merchants, service providers and other entities handling account data	Active; v4.0.1 is the only active version. PCI SSC consulted on the next iteration in June–July 2026; no successor has been published
PCI Secure Software Standard (SSF)	Validate the security of a payment software product	Payment software vendors, and SDK vendors from v2.0	Active; v2.0 published January 2026, transition from v1.2.1
PCI Secure SLC Standard (SSF)	Validate a vendor’s secure development and maintenance practices	Software vendors	Active; v2.0 published September 2026, transition from v1.1

What should you do with an old PA-DSS application?

Many merchants still run software that was once PA-DSS validated. That is not automatically a problem, but the old listing no longer answers the question. A sensible approach:

Treat the listing as history. It describes an assessment of a past version against a retired standard.
Ask your acquirer. PCI SSC leaves continued use of expired applications to the acquirer and the payment brands. Find out whether the application is still acceptable for your compliance, and for how long. Acquirers sit at the center of this relationship; see the primary players in payments processing.
Keep it in your PCI DSS scope. The application is assessed like any other system component in your cardholder data environment, against PCI DSS v4.0.1.
Check vendor support. Software that no longer receives security fixes, or that only runs on an unsupported operating system, makes current patching and vulnerability-management requirements hard to meet whatever its old status.
Re-test the data rules. Ask your assessor to confirm the application does not keep sensitive authentication data anywhere, including logs and temporary files.
Plan the replacement. When you buy new software, ask the vendor for current evidence, such as a listing under the Secure Software Standard, and ask your acquirer what it expects to see.

This is general guidance, not a compliance determination. Your acquirer and your assessor make that call for your organization.

What should software vendors do now?

If you build payment software and your customers used to ask for PA-DSS, the practical path is:

Find out who is asking for validation, and what they will accept. Acquirers, payment brands, large merchants and your customers’ assessors may each expect something different.
Choose the right standard. The Secure Software Standard validates a product; the Secure SLC Standard validates your development process. Many vendors pursue both.
Work to the current versions. Version 2.0 of both standards is published. Confirm with an assessor how the transition periods affect your timing.
Design the data rules in. Decide early where the card number lives, how it is protected and how keys are managed, and make sure sensitive authentication data is never written anywhere after authorization.
Build lifecycle evidence. Threat modeling, secure coding standards, security testing, vulnerability handling and change control are what an assessor will want to see working, not just written down.
Engage a qualified assessor. PCI SSC publishes the lists of Secure Software and Secure SLC Assessors.
Write implementation guidance. As with PA-DSS, your customers need to know how to deploy your software without weakening their own compliance.

And remember the rule that carried over from PA-DSS: validating your software does not make your customers PCI DSS compliant.

Frequently asked questions

What does PA-DSS stand for?

Payment Application Data Security Standard. It was a PCI Security Standards Council standard for commercial payment software.

Is PA-DSS still valid in 2026?

No. PCI SSC retired PA-DSS and closed its program on 28 October 2022. All former listings are expired.

What replaced PA-DSS?

The PCI Software Security Framework, made up of the PCI Secure Software Standard and the PCI Secure Software Lifecycle (Secure SLC) Standard. Both are at version 2.0.

Is PA-DSS the same as PCI DSS?

No. PCI DSS applies to organizations that handle card data and covers their whole environment. PA-DSS applied to individual versions of commercial payment applications. PCI DSS remains in force; PA-DSS does not.

Does using PA-DSS or SSF validated software make a merchant PCI DSS compliant?

No. Validated software can make compliance easier, but the merchant’s own environment still has to meet PCI DSS, and the software remains in scope of the merchant’s assessment.

Can a business still use an old PA-DSS application?

Organizations that deployed an application before its listing expired may continue to use it as far as the PA-DSS program is concerned. Whether that is acceptable for their compliance is decided by their acquirer and the payment brands, and the application must still meet PCI DSS as part of their environment.

What did “PA-DSS listed” mean?

That a specific version of an application had been assessed by a PA-QSA and published on PCI SSC’s list of validated payment applications. The list is still online, marked closed, with every entry moved to “Acceptable Only for Pre-Existing Deployments”.

Can I still get PA-DSS certification?

No. PCI SSC stopped accepting new submissions on 30 June 2021 and closed the program on 28 October 2022. Payment software is now validated under the Secure Software Standard.

What happened to PA-QSAs?

The PA-QSA program closed with PA-DSS. Assessors who wanted to keep evaluating payment software had to qualify under the Software Security Framework as Secure Software Assessors.

What is the current version of PCI DSS?

PCI DSS v4.0.1. Version 4.0 was retired at the end of 2024, and the requirements that were future-dated in v4.0 became mandatory on 31 March 2025. PCI SSC asked for industry feedback on v4.0.1 in mid-2026 as the first step toward its next iteration, but no successor version has been published.

Official PCI SSC sources

This article is an independent explainer written by Ambimat. It summarizes PCI SSC’s publications in our own words and is not affiliated with or endorsed by PCI SSC. The standards themselves are available from the PCI SSC Document Library.

PA-DSS (Payment Application Data Security Standard): What It Was and What Replaced It