What must an SDK provider know about PCI SSF v2.0 certification? An SDK provider validating under PCI Secure Software Standard v2.0 (published 15 Jan 2026) starts not from a control list but from identifying its component’s sensitive assets – keys, credentials, security logic and the critical code itself – supported by the new SAID document. This changes the order and priorities of the whole validation project.
Canonical definition: The PCI Secure Software Standard is a PCI Software Security Framework standard validating whether payment software – including libraries and SDKs – is designed, developed and maintained to protect sensitive assets and defend against attacks.
An SDK is a special case of payment software: a library embedded in others’ apps, often running on devices beyond the provider’s control. This article distils the v2.0 requirements into two lists for an SDK developer: five things to do first and five mistakes to avoid.
PCI SSF v2.0 for SDK – key takeaways:
- PCI Secure Software Standard v2.0 was published on 15 Jan 2026 – the first full revision of the standard, shifting the focus to identifying and protecting sensitive assets (PCI SSC blog).
- The new companion document SAID (Sensitive Asset Identification) supports the provider in identifying sensitive assets – for an SDK, the starting point of the whole validation.
- The objective-based approach means the SDK provider demonstrates how it meets a security objective, instead of ticking a rigid control list.
- Once assessor training becomes available (CBT expected in Q1 2026), a 12-month window to move from v1.2.1 to v2.0 begins.
- A payment SDK may fall under several regimes at once: SSF for the software and – for a 3DS SDK – the separate PCI 3DS SDK Security; the developer must split these tracks.
- Patronusec, an accredited QSA, supports SDK developers in preparing for SSF v2.0 validation – from sensitive asset identification to a transition plan.
Table of Contents
What is PCI SSF v2.0 and why does it apply to an SDK developer?
PCI Secure Software Standard v2.0 validates the security of payment software, including libraries and SDKs that process or protect payment data or sensitive assets. An SDK developer supplying a component to other companies’ payment applications falls within the standard’s scope as a software provider.
PCI SSF (Software Security Framework) replaced the former PA-DSS and comprises two standards: the Secure Software Standard (product validation) and the Secure Software Lifecycle (development process validation). An SDK, as a specific product, is validated under the Secure Software Standard – and from 15 Jan 2026 under its v2.0 version, the first full revision since the standard was introduced.
Why is an SDK a special case? A library does not run on its own – it is embedded in apps the SDK provider does not control, and it often executes on end users’ devices. That makes identifying sensitive assets (keys, data, logic) and protecting them even in an unknown execution environment the core of validation – and the new v2.0 asset-based approach fits this better than the “payment application” model from the 1.x line.
For an SDK developer, the most important change in v2.0 is that validation starts from the question “which sensitive assets does my library carry and how do I protect each one”, not from a control list assigned in advance to an application.
What does version 2.0 change from an SDK provider’s perspective?
Version 2.0 shifts the focus from the payment application to sensitive assets, rebuilds the standard’s structure, reduces overlap with the SLC and modernises the delta change process. For an SDK provider, the first is most important – because it determines where the project starts.
The most important changes, per the PCI SSC blog:
- A 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 SAID document.
- A rebuilt structure and terminology. The requirements were reorganised for easier navigation; overlap with the framework’s other standard (SLC) was also reduced.
- A modernised change process. A new Change Impact template and wildcards for non-security-impacting changes – important for an SDK released often and in many versions.
- Portal and listing improvements. A portal for the provider to submit annual attestations and administrative changes.
For an SDK this has concrete implications. A library is often updated quickly – the new delta change process and wildcards let you distinguish security-relevant changes from purely functional ones, simplifying listing maintenance under frequent releases. And the asset-based approach rewards teams that already think about keys and data in terms of protection rather than list compliance.
Version 2.0 rewards the SDK provider that knows every sensitive asset in its library – and exposes the one that used to “pass validation” without a full map of what its code protects.
Top 5 things an SDK developer must do first
The five tasks below set the right order for an SDK v2.0 validation project. Their common denominator: start from understanding what your library protects, before you prove how it protects it.
Identify sensitive assets using SAID. This is the foundation of v2.0 and the first step, not the last. For an SDK, sensitive assets are usually: keys and cryptographic material, credentials, security logic (for example tamper detection), processed payment data and the critical code itself. Document each one.
Set the boundary of what you deliver relative to the host environment. An SDK runs inside someone else’s app. Establish explicitly what the library is responsible for and what belongs to the integrator – this determines your validation scope and the content of your customer guidance.
Map security objectives to evidence. The objective-based approach requires demonstrating how you meet an objective, not ticking a control. For each sensitive asset, prepare evidence: design, configuration, test result, procedure.
Restructure your change process for the new delta model. Adapt versioning and release documentation to the Change Impact template and wildcards, so that frequent SDK releases do not trigger full revalidation for non-security-impacting changes.
Split the tracks if your SDK is a 3DS SDK. A 3DS SDK’s security is assessed by the separate PCI 3DS SDK Security standard, and its protocol conformance by EMVCo approval. These are different documents and different laboratories from SSF. Plan them as separate streams.
Patronusec Insight: In our project experience, SDK developers most often defer sensitive asset identification to the end, treating it as a formality to complete before the audit. In v2.0 this reverses the right order: without a thorough asset map, you cannot set the scope, choose the evidence or estimate the cost of validation. We recommend dedicating the first days of the project solely to SAID – an investment that pays back in every later phase.
Top 5 things an SDK developer must avoid
The five mistakes below most often extend or block an SDK’s v2.0 validation. Their common denominator: thinking in terms of the old “payment application” model instead of the new, asset-based one.
❌ Treating SAID as an end-of-project formality. Sensitive asset identification is the starting point of validation, not a document to finish before the audit. Missing an asset at this stage propagates through the whole project.
❌ Assuming EMVCo approval handles security. For a 3DS SDK, EMVCo approval confirms protocol conformance, not the library’s resilience – that is assessed by the separate PCI 3DS SDK Security standard. Confusing these tracks is the most common cause of slippage.
❌ Ignoring the execution environment. An SDK runs on devices whose state you do not control. A design assuming a “trusted environment” will not pass – asset protection must work even when the host is hostile.
❌ No clear integration guidance for customers. If secure use of the SDK depends on correct integration and you do not document it, the sensitive assets are effectively protected by someone who does not know how. Integrator guidance is part of the product’s security.
❌ Delaying the transition-window decision. Delaying the choice of whether to validate once more to v1.2.1 or straight to v2.0 pushes the project to the end of the 12-month window – where assessor queues and time pressure raise the risk.
The most common cause of failure in SDK validation is not weak cryptography but a disordered map of what the library protects and in what environment – v2.0 will not forgive that gap as easily as the 1.x model.
How to plan the move to v2.0 within the transition window?
An SDK developer should decide the transition point on the library’s release cycle and the next validation date, rather than deferring the decision to the window’s end. The 12-month window opens once assessor training becomes available, with supporting materials released in stages through Q1-Q2 2026.
The timeline, per PCI SSC announcements:
- 15 Jan 2026 – publication of PCI Secure Software Standard v2.0.
- early February 2026 – expected v2.x templates (ROV, AOV, Change Impact).
- Q1 2026 – expected CBT training for existing assessors; ILT for new ones in Q2.
- transition window opening – 12 months to move from v1.2.1 to v2.0 once training is available.
The practical decision for an SDK developer depends on the release cycle. A very frequently released library benefits from an earlier move to v2.0, because the new delta change process better fits its rhythm. An SDK just before a major v1.2.1 validation may complete the current cycle and move to v2.0 at the next validation. The key is to weigh this against the asset map – if SAID reveals gaps, the transition must be planned with room for remediation.
Patronusec supports SDK developers through this transition within its PCI SSF audit and preparation service – from sensitive asset identification to a plan matched to the library’s release cycle.
FAQ – PCI SSF v2.0 for SDK
Does every payment SDK fall under PCI SSF?
It does if it is payment software supplied to other organisations that processes or protects payment data or sensitive assets. The specific validation requirements depend on the SDK type and the expectations of partners and payment networks. An SDK built solely for internal use is not subject to SSF validation, though the card data processing environment remains subject to PCI DSS.
How does SDK validation in SSF differ from EMVCo approval for a 3DS SDK?
They are two separate tracks. PCI SSF (Secure Software Standard) validates payment software security. For a 3DS SDK, EMVCo approval (protocol conformance) and PCI 3DS SDK Security (library resilience) additionally apply. A 3DS SDK developer plans these streams separately, because they have different documents, laboratories and schedules.
What is SAID and why is it key for an SDK?
SAID (Sensitive Asset Identification) is a new companion document to v2.0 supporting the identification and documentation of sensitive assets. For an SDK it is key, because a library carries concentrated assets (keys, data, security logic), and v2.0 validation starts precisely from their map – not from a control list.
When must I move from v1.2.1 to v2.0?
Within the 12-month transition window that opens once v2.0 assessor training becomes available (CBT expected in Q1 2026). A product validated to v1.2.1 remains valid per the programme rules through the window; you move to v2.0 at the next validation. The timing is best matched to the SDK release cycle.
Is the asset-based approach harder for a small SDK team?
Not necessarily – for a team that already thinks about keys and data in terms of protection, it is more natural than ticking a list. The difficulty arises with improvisation: when nobody holds a full map of what the library protects. SAID orders this once, and the asset map then serves at every subsequent validation.
How long does preparing an SDK for SSF v2.0 validation with Patronusec take?
The time depends on the SDK’s complexity, the number of sensitive assets, the state of documentation and whether you validate for the first time or move from v1.2.1. After a free scope-assessment call we present a fixed-price quote covering asset identification, gap analysis and validation readiness.
Recommended reading
A reading path for payment software security:
- PCI SSF v2.0 vs v1.2.1 – what changes for a payment software vendor – the foundation: the full scope of the v2.0 changes.
- A PCI Secure SLC-compliant development process – the framework’s other standard, validating the development process.
- What is a 3DS SDK – requirements and use cases – if your SDK performs 3DS authentication.
- PCI Secure Software Framework (SSF): a key standard for payment software security – the wider framework context.
PCI SSF v2.0 for SDK developers – free consultation
Patronusec, an accredited QSA, supports payment software vendors, including SDK developers, in PCI SSF validation. In a free 30-minute consultation we will help you identify your library’s sensitive assets and plan the move to v2.0.
