On February 6, 2026, a ransomware attack hit US payment gateway BridgePay. The outage took down their gateway API and hosted payment pages. Restaurants in Florida went cash-only, and some city offices in Texas lost their payment portals after card transactions flatlined.
Banks and merchants remember these disruptions. The outage did not prove card data was at risk. BridgePay’s initial forensic findings said nothing was compromised. It did show how stuck merchants are when a payment vendor goes down, and that is why risk teams now ask vendors to prove their software and development pipeline are secure.
This blog explains how the PCI Software Security Framework (SSF) works. It covers the two separate standards (Secure Software and Secure SLC), along with the assessment process and the usual trouble spots for engineering teams.
What Is PCI SSF Compliance?
PCI SSF compliance is the process of proving your payment software and your engineering practices meet the PCI Security Standards Council’s security rules. The framework officially replaced the old Payment Application Data Security Standard (PA-DSS) on October 28, 2022.
People often search for PCI SSF certification. The framework calls this result validation. PCI SSC lists validated products and qualified vendors rather than issuing certificates, which is why contracts usually say listed rather than certified. A related PCI compliance test can help organizations evaluate their payment software security controls against applicable PCI requirements.
PA-DSS validated a product at a point in time. SSF splits the problem in two. One standard covers the product. The other covers the vendor’s development lifecycle. Security becomes something you maintain rather than something you pass once.
That change affects how you sell your software.
- It is not a legal mandate. No government agency will arrest you for skipping it. The PCI SSC doesn’t force every software company to validate.
- Your clients enforce it. Payment brands like Visa and Mastercard, along with acquiring banks, use the SSF list as a third-party risk filter. If a major processor or merchant won’t install your software without a listing, you need it to close the deal. It is a contract requirement, not a law.
Who Needs PCI SSF Compliance?
PCI SSF is primarily for software vendors that develop payment software or maintain a payment-relevant development lifecycle. Your need for formal validation depends on the payment-brand rules for your customers, your contracts, and what your buyers require.
If your company only uses the software, your own obligations sit under PCI DSS. Using a payment application does not automatically make you responsible for obtaining its SSF validation. It also does not mean DSS is your only consideration. Your acquiring bank or a customer may still require validated software as a condition of doing business.
Under the latest v2.0 rules, eligibility comes down to what the software actually handles. If your software handles sensitive payment assets, check it against the Secure Software Program Guide. Touching a sensitive asset does not automatically make you eligible.
Eligible software types include:
- Point-of-sale (POS) applications
- ATM software
- Payment gateways and tokenization services
- In-app payment SDKs and 3DS SDKs
- Fraud monitoring tools (if they handle sensitive assets)
- Key management software
These are examples of software categories that may qualify. Final eligibility depends on the applicable PCI Secure Software Program Guide criteria and how the software actually functions.
If you build any of these, you pick a path. You can validate a specific product through the Secure Software Standard, or validate your entire engineering process through the Secure SLC Standard.
The Two Standards Under PCI SSF
The PCI Software Security Framework (SSF) consists of two independent assessments: the Secure Software Standard for your product, and the Secure SLC Standard for your development process. A successful assessment in one does not automatically qualify you for the other.
PCI Secure Software Standard
The PCI Secure Software Standard checks your actual software product and its sensitive assets. Assessors test whether your application protects payment transactions and card data under real-world conditions. A successful validation gets your product listed as Validated Payment Software.
The January 2026 update (v2.0) changed the rules. It drops the old “payment application” label. It focuses on the data your software touches. SDKs, including EMVCo 3DS SDKs, are now eligible under a new module. The standalone 3DS SDK standard stopped accepting new submissions on 31 October 2026. It now runs as Module D inside the Secure Software Standard. Once validated, your listing lasts for three years, provided you submit annual attestations.
PCI Secure Software Lifecycle (Secure SLC) Standard
The Secure Software Lifecycle Standard checks your engineering process rather than a single piece of software. Assessors look at how you build and maintain code, including your development environment, build pipelines, third-party supply chain, and vulnerability management. A successful validation gets you listed as a Secure SLC Qualified Software Vendor.
The September 2026 update (v2.0) added new requirements for the modern development stack. You now need a formal Software Bill of Materials (SBOM), a designated SSLC Steward to oversee the lifecycle, and documented controls for any AI coding assistants your team uses.
If you still hold a v1.1 validation, watch for the training announcement. PCI SSC has said a 12-month transition from v1.1 to v2.0 begins once the v2.0 assessor training becomes available, which is expected in Q4 2026. Plan your reassessment around that window rather than a fixed calendar date.
PCI Secure Software vs. Secure SLC
| Comparison | Secure Software | Secure SLC |
| Assessment scope | Payment software product | Vendor’s software lifecycle |
| Main focus | Product security | Secure development and maintenance practices |
| Assessment subject | Software product | Software vendor |
| Validation outcome | Validated Payment Software | Secure SLC Qualified Software Vendor |
These assessments are completely independent. A validated product does not make your company Secure SLC-qualified. A secure development process does not automatically get every product listed.
The two are separate, but they are not unrelated. If you hold a validated Secure SLC and use it to develop a listed Secure Software product, PCI SSC gives that product program benefits. That is a reason to think about which assessment to start with.
PCI SSF Compliance Requirements
The PCI SSF requirements come in two sets. The Secure Software Standard looks at the product you sell, and the Secure SLC Standard looks at the environment where you build it.
PCI Secure Software Standard Requirements
The Secure Software Standard checks your actual application. The rules now focus on what data and functions the software handles, not just the old payment application label.
Vendors must meet these core technical requirements:
- Sensitive modes – Administrative, privileged, and maintenance modes must be gated by strong authentication, with lockout after failed attempts.
- Documentation – Maintain a Software Bill of Materials and current architecture records. Under v2.0, you also have to identify and document every sensitive asset using the Sensitive Asset Identification (SAID) companion document.
- Logging – Generate and protect logs for sensitive operations and suspicious events.
If your sensitive asset inventory is out of date, parts of the product will fall outside the assessment. Update it when the architecture or the product changes. You cannot protect what your inventory does not cover.
PCI Secure SLC Standard Requirements
The Secure SLC Standard checks how you build software. It asks you to prove secure lifecycle governance through a secure software development framework, secure design, a protected development environment, and controlled build processes.
The September 2026 update (v2.0) added new requirements for the modern development stack:
- Supply Chain – Maintain a formal Software Bill of Materials covering third-party and open-source components.
- Development Environment – Keep pre-production separate from production. Production payment data must not be used in test environments, and you need protected records of who accessed the codebase and when.
- Digital Tools – Document how digital tools are selected, validated, and overseen by a human. This covers AI coding assistants but also IDEs, build systems, and code repositories.
- Personnel – Assign an SSLC Steward to run the lifecycle. The standard allows this to be an individual or a group, and the steward owns the training and approval processes.
If your developers use AI coding assistants or other digital tools, the standard expects documented selection, human oversight, validation, and traceable records. Your assessor will test whether those records exist and match how you actually work.
PCI SSF Assessment and Validation Process
The PCI SSF assessment is a formal PCI audit conducted by a PCI SSC-qualified SSF Assessor Company. You cannot self-certify. The process follows a fixed sequence, and teams that try to skip steps usually pay for the work twice.
1. Determine the Applicable Standard
Decide whether you need the Secure Software Standard, the Secure SLC Standard, or both. A client asking for “SSF” might mean either one. Get the answer in writing before you spend money on scoping, so your team does not waste months on the wrong path.
2. Define the Assessment Scope
Identify the product, its sensitive assets, the applicable requirements, and the modules in play. For Secure SLC, define the lifecycle scope, development environments, and third-party tools. This is usually where you spot issues, mostly because your documentation no longer matches what your engineers actually do.
3. Conduct a Gap Assessment
Compare your current controls, development practices, and documentation against the rules through a structured security testing assessment. Missing records, weak change control, and unmanaged open-source dependencies will show up here. It costs far less to find these problems now than during the formal assessment.
4. Remediate Identified Issues
Fix the technical and process problems before the assessor arrives. Remediation is not just patching software. Your team needs to write down what they do, prove they do it consistently, and make sure your actual workflow matches the evidence an assessor will request.
5. Engage a PCI SSC Qualified Assessor
Pick a company listed by the PCI SSC for the specific Secure Software or Secure SLC assessment. A strong background in PCI DSS does not automatically qualify a firm for SSF. Verify their listing on the PCI SSC website and confirm scope in writing.
6. Complete the Assessment and Obtain Validation
The assessor reviews documentation, tests controls, and for Secure Software v2.0 examines source code and runs static and dynamic analysis. Secure SLC assessments focus on lifecycle evidence and may draw on source code where the requirements call for it. Outcomes land in one of two places. You either get a Validated Payment Software listing or a Secure SLC Qualified Software Vendor listing. Assessors act as independent auditors; they will not fix your code for you. The PCI SSC handles reporting and listing once it accepts the work.
7. Maintain Validation
Validation does not stay valid on its own. Secure Software Standard listings are generally valid for three years, subject to early expiry and program requirements, with annual attestations submitted through the PCI SSC Portal. Secure SLC has its own maintenance and reassessment rules. Confirm those in the Secure SLC Program Guide rather than assuming the Secure Software timeline applies. New vulnerabilities pop up, software changes, and third-party dependencies get compromised. Vendors need ongoing vulnerability management, change impact analysis, and a plan for the full reassessment at the end of the three-year cycle for Secure Software.
PCI SSF vs. PCI DSS
The PCI SSF checks the software product and the vendor building it. PCI DSS checks the environment where that software runs and stores card data.
| Comparison | PCI SSF | PCI DSS |
| Primary focus | Payment software security and secure software lifecycle | Security of payment account data environments |
| Intended audience | Payment software vendors | Entities in scope for PCI DSS (merchants, processors, service providers) |
| Assessment | Software product or vendor lifecycle assessment | Assessment of the applicable PCI DSS environment and scope |
| Outcome | Validated Payment Software or Secure SLC Qualified Software Vendor | PCI DSS compliance validation |
| Relationship | Supports secure payment software | Addresses security across the payment environment |
SSF validation does not replace PCI DSS compliance. PCI DSS does not universally require SSF-validated software. However, payment brands, acquiring banks, processors, or customers may require it as part of their third-party risk management.
A merchant can pass a PCI DSS audit by locking down their network, even if the point-of-sale software they bought is full of flaws. A software vendor can hold a validated product while their corporate office network stays completely outside PCI DSS scope. The two programs cover different surfaces. SSF validates the code you buy, and DSS validates the network you run it on.
Treat PCI DSS obligations and SSF validation as separate questions. Your DSS scope depends on your environment. Your SSF obligation depends on what your customers and payment brands require from your software.
How Qualysec Can Help with PCI SSF Compliance
Qualysec prepares payment software vendors for PCI SSF compliance. The firm does not perform the final audit, but helps prepare your evidence for the assessor.
Qualysec is not a PCI SSC-qualified SSF Assessor Company. It does not perform the validation or submit the assessment to PCI SSC. Only a PCI SSC-qualified SSF Assessor Company can issue the formal validation. Always verify your assessor’s listing on the PCI SSC website.
You have a customer demanding an SSF listing, and your developers are buried in tickets. Nobody on the team has time to read a hundred-page standard. Qualysec does that work. It holds CREST accreditation for penetration testing and tests payment systems under strict rules.
- Readiness Reviews: Compare your code and development process against the v2.0 rules.
- Technical Testing: Real attacks against your access controls and logging to fix flaws before an auditor does.
- Evidence Organization: A clean package of your test results and policies, organised around the requirements your assessor will test against.
Qualysec gets you ready for the audit and continues security testing after you pass.
If a customer questionnaire is sitting in your inbox, start with a readiness call. Qualysec will look at your product and existing evidence, then tell you what needs fixing before you spend money on the formal assessment.
Conclusion
PCI SSF compliance often decides if a bank or processor will deploy your software or drop you during a third-party risk review.
The Software Security Framework (SSF) was updated in 2026 to match how teams build payment software today. Secure Software v2.0 introduced sensitive asset identification and opened eligibility to SDKs, including 3DS SDKs. Secure SLC v2.0 added requirements for digital tools, including AI, covering selection, human oversight, validation, and traceable records. Check which version applies to you and prepare evidence against its specific requirements.
Do not wait for an assessor to find missing records. Scope the right standard, fix your documentation, and test your controls before you schedule the formal audit. If a customer is already asking for a listing, start preparing now to reduce the risk of delays and unexpected findings during the formal assessment.
If your team needs help with that prep work, Qualysec can review your code and documentation before you hire an assessor. Reach out to find out exactly where you stand.
FAQs
1. What types of software are eligible for PCI SSF validation?
Eligibility depends on the software’s purpose and the PCI Secure Software Program Guide. The standard covers payment software sold, distributed, or licensed to third parties. Under the current Program Guide, software built strictly for internal company use does not qualify.
2. Is SaaS software eligible for PCI SSF validation?
Yes. The PCI SSC confirms that software-as-a-service can be validated under the Secure Software Standard if it meets the applicable eligibility criteria. The delivery model alone does not make your product ineligible.
3. How often must PCI SSF validation be renewed?
Secure Software Standard validations are generally valid for three years, subject to early expiry and program requirements. Vendors submit annual attestations through the PCI SSC Portal and manage software changes through the applicable PCI SSC process. Secure SLC has its own maintenance and reassessment requirements. Check the Secure SLC Program Guide for those rather than assuming the Secure Software timeline applies.
