You've likely heard the rumors in vendor meetings and compliance calls. As the PCI SSC rolls out version 2.0 of the Secure Software Standard, myths are spreading. Some arise from wishful thinking about reducing scope, others from misinterpretations of the consolidation roadmap. A few are just outdated assumptions that haven't been challenged.
These myths lead to poor planning. Teams delay necessary assessments, vendors misallocate budgets, and when reality hits, it's often mid-implementation with a hard deadline looming.
Let's clear this up.
Myth 1: SDKs Aren't Subject to Secure Software Assessments
Reality: Software development kits are explicitly eligible for assessment under v2.0, including EMVCo 3DS SDKs. If your team builds or distributes an SDK that handles payment data or authentication flows, it's in scope.
This isn't a minor clarification; it's a change to what qualifies as assessable software. The PCI 3DS SDK Standard exists as a separate framework, but v2.0 offers an alternate assessment path. Eventually, the 3DS SDK Standard will be phased out as part of the standards consolidation. The PCI 3DS Data Matrix has been updated to version 1.2 to reflect 3DS SDK sensitive data elements.
If your team works on SDKs for mobile payment flows, authentication handoffs, or tokenization, you're now under a different compliance model. Don't assume your current assessment approach still applies.
Myth 2: The Sensitive Asset Identification Document Is Optional
Reality: It's a required companion document. Version 2.0 includes this document to help you identify and document sensitive assets within your software. If you can't define what constitutes a sensitive asset in your codebase, you can't scope your assessment correctly.
Think of it as the software equivalent of CDE scoping. You need to know where payment-related data resides, where payment-related functionality executes, and what components interact with them. The companion document provides a structured way to map this out before your assessor arrives.
Skipping this step leads to circular conversations during the assessment. "Is this module in scope?" becomes a recurring question because nobody documented the data flows upfront. Use the companion document to build that map now, not during the assessment window.
Myth 3: We Can Use v1.2.1 Indefinitely
Reality: Once training is available, a 12-month transition period begins. The v2.0 computer-based training is expected by Q1 2026, with instructor-led training planned for Q2. That starts the clock.
Twelve months may seem generous until you consider your assessment cycle, vendor coordination, and the learning curve for new requirements. If your current assessment expires six months into the transition period, you're already working under v2.0 whether you planned for it or not.
The supporting templates (Report on Validation, Attestation of Validation, and the new Change Impact template) are expected in early February 2026. Don't wait for the official transition announcement to start reviewing what's changed. The Summary of Changes document is available now in the PCI SSC Document Library.
Myth 4: Standards Consolidation Means Less Work
Reality: Consolidation means one assessment path instead of multiple overlapping standards, but it doesn't reduce the rigor of what's assessed. If you're managing separate assessments for 3DS SDKs and other payment software, consolidation simplifies your workflow. It doesn't exempt you from the underlying requirements.
The benefit is administrative, not technical. You'll have one set of assessor qualifications to track, one reporting format, one portal for attestations. But the security controls your software must demonstrate remain comprehensive. In some cases, bringing SDKs under the Secure Software Standard increases visibility into components that previously operated in a gray area.
Expecting consolidation to mean "less compliance overhead" sets you up for disappointment. Plan for streamlined processes, not reduced scope.
Myth 5: The Wildcard Feature Lets Us Skip Change Assessments
Reality: Wildcards account for non-security impacting changes. The keyword is "non-security impacting." Version 2.0 introduces wildcards because minor version updates (like dependency patches, UI tweaks, performance optimizations) were triggering full re-assessments even when they didn't touch sensitive assets or security controls.
But you still need to demonstrate that a change is non-security impacting. That's where the new Change Impact template comes in. You document the change, show why it doesn't affect security controls or sensitive data flows, and use the wildcard to maintain your validation status without a full re-assessment.
This is a practical improvement, not a loophole. If your change affects authentication logic, cryptographic implementations, or data handling routines, it's security-impacting. The wildcard doesn't apply. Treating wildcards as blanket exemptions will lead to assessor pushback and potentially invalid attestations.
What to Do Instead
Start with the companion document for sensitive asset identification. Map your software's data flows and payment-related functionality before you're in an assessment cycle. This exercise surfaces scope questions early, when you can still adjust architecture or documentation.
Review the Summary of Changes document to understand what's different between v1.2.1 and v2.0. Don't rely on secondhand interpretations or vendor webinar summaries. The actual changes are specific and technical.
If you're assessed under the PCI 3DS SDK Standard, engage your assessor now about the transition path. The alternate assessment route under v2.0 may simplify your compliance posture, but only if you plan the migration deliberately.
Watch for the template releases in early February 2026 and the CBT availability in Q1. Once training launches, your 12-month transition clock starts. Use that time to update internal processes, train your development teams on the new change impact requirements, and align your assessment schedule with the new framework.
These myths persist because change is uncomfortable and standards consolidation sounds abstract. But v2.0 is concrete, the timelines are set, and the scope expansion to SDKs is real. Plan accordingly.
