ControlSolid
Payment Security

PCI 3DS Readiness: Scope, Evidence, and Common Gaps

Published July 2026

What PCI 3DS addresses

The PCI 3DS Security Standard, published and maintained by the PCI Security Standards Council, defines physical and logical security requirements for organizations that operate the environments supporting EMV 3-D Secure. Those environments are typically run by issuers, acquirers, and technology providers that host the Access Control Server (ACS) or Directory Server (DS) components used during authentication of card-not-present transactions.

PCI 3DS focuses on the systems that perform authentication — not the merchant checkout experience. It sits alongside the EMVCo 3-D Secure protocol specification, which defines how the messages flow. Where EMVCo says how 3DS works technically, PCI 3DS says how the operating environment must be secured.

Who may need to prepare

  • Issuers running or hosting an ACS.
  • ACS or DS providers (including managed and cloud-hosted services).
  • Technology providers that operate parts of the 3DS environment on behalf of issuers or acquirers.
  • Organizations pursuing listing or contractual assurance for 3DS operations.

Merchants integrating a 3DS SDK generally do not undergo a PCI 3DS assessment themselves; their obligations remain under PCI DSS and their processor's requirements. But they still need to understand which of their partners are 3DS-assessed and where responsibilities divide.

Scoping considerations

Scope is the single biggest driver of PCI 3DS effort. The standard applies to the 3DS Environment (3DE), which includes the systems and personnel that support 3DS functions, and the connected-to and security-impacting systems that touch that environment.

Practical scoping questions:

  • Which components host the ACS or DS, and where are they physically located?
  • Which administrative networks, jump hosts, and identity systems reach the 3DE?
  • Which shared services (logging, monitoring, key management, backup) touch the 3DE?
  • Which third-party providers run parts of the 3DE, and what evidence do they supply?
  • How is the 3DE segmented from the corporate network and other production workloads?

Structure of the PCI 3DS Security Standard

The PCI 3DS Security Standard is organized into two parts. Part 1 restates the baseline security requirements that also appear in PCI DSS — network security, patching, vulnerability management, access control, logging, physical security, and personnel practices — and applies them to the 3DS Environment (3DE) instead of the cardholder data environment. Part 2 adds 3DS-specific control objectives that reflect the unique risks of running an ACS or DS: protection of authentication data at rest and in transit, cryptographic operations tied to authentication, secure software development for 3DS components, and specific requirements for the physical environment where sensitive 3DS systems live. Treating Part 1 as "we already do PCI DSS, so we're fine" is a common source of findings — the scope, evidence, and depth of testing are different.

Relationship to EMVCo 3DS protocol versions

PCI 3DS and the EMVCo 3-D Secure protocol specification are complementary and are maintained by different bodies. EMVCo defines the protocol itself — currently the 3DS 2 family, with versions 2.2 and 2.3 in active deployment — and manages the certification of ACS, DS, and 3DS SDK products against the protocol. PCI 3DS governs the security of the operating environment for the ACS and DS. Vendors and issuers should track both: moving from 2.2 to 2.3, for example, brings new data elements, new authentication flows, and new integration points that can change the 3DE scope and the data protected within it. Assessment planning benefits from lining up EMVCo protocol milestones with PCI 3DS reassessment windows.

Architecture and data-flow review

A defensible 3DS assessment package starts with an accurate architecture diagram and data-flow description. This should show every component in the 3DE, every trust boundary, every management interface, and every place cryptographic keys are generated, stored, or used. A common source of findings is a diagram that no longer matches production — a new cloud region, a management plane that has been quietly consolidated, or a shared Kubernetes cluster that expanded to include 3DS workloads without formal review.

Physical security and hosting model

PCI 3DS carries specific physical security expectations for the facilities that host sensitive 3DS components, including data-center access controls, visitor management, and protections for media that leaves the facility. Organizations that run the 3DE in a public cloud must document the shared responsibility split clearly: the cloud provider typically owns physical and environmental controls (backed by their own assurance reports such as SOC 2 and ISO 27001), while the customer owns everything from the hypervisor boundary up. Copying a cloud provider's attestation into the evidence pack is not enough — the customer must map each shared control to a provider report and identify the customer-side controls that complete the picture.

Evidence and documentation preparation

Typical evidence expectations include:

  • Scope description of the 3DE and its supporting systems.
  • Data-flow diagrams for authentication and management traffic.
  • Cryptographic inventory: keys, algorithms, storage, rotation, and access.
  • Change and vulnerability management records covering the 3DE.
  • Access management records: identities, roles, privileged access, and reviews.
  • Logging and monitoring configurations covering authentication and administrative events.
  • Third-party attestations for hosting, cryptographic services, or connected providers.

Common readiness gaps

  • 3DE segmentation that looks strong on paper but has drifted operationally as workloads move to shared clusters.
  • Key management that relies on undocumented "how we've always done it" processes rather than a documented cryptographic key inventory.
  • Missing or partial logging on administrative interfaces to the ACS or DS, especially for break-glass access.
  • Shared identity providers that grant broader access to the 3DE than intended through inherited group memberships.
  • Vendor and shared-responsibility gaps between the customer and cloud/hosting provider, with no explicit mapping to provider attestations.
  • Change management records that don't include 3DE-specific approvals and testing, or that treat protocol upgrades as routine.
  • Incident response runbooks that do not distinguish the 3DE from the rest of production and therefore miss required notifications.

Relationship to PCI DSS and other payment standards

PCI 3DS and PCI DSS are separate standards with overlapping expectations. Many controls (network segmentation, patching, logging, personnel screening, incident response) look familiar because they exist in both. But they are scoped differently: PCI DSS is about the cardholder data environment; PCI 3DS is about the 3DS environment. An organization can be in scope for one, both, or neither depending on what it actually operates.

Vendors that also touch payment software or payment infrastructure may need to consider PCI SSF (for payment software) or PCI PIN (for cryptographic operations on PINs) in parallel — the readiness work benefits from being planned together.

Practical readiness checklist

  1. Confirm the 3DS role: ACS operator, DS operator, or supporting provider.
  2. Document the 3DE with current diagrams and a written scope description.
  3. Perform a gap assessment against the current PCI 3DS Security Standard.
  4. Address cryptographic, segmentation, access, and logging gaps first.
  5. Consolidate evidence and third-party attestations in one place.
  6. Engage a qualified 3DS Assessor for the formal assessment when ready.

How ControlSolid supports PCI 3DS readiness

ControlSolid provides PCI 3DS readiness support — scoping, architecture and data-flow review, gap assessment, evidence preparation, and remediation planning — and coordinates a clean handoff to the qualified 3DS Assessor performing the formal assessment. ControlSolid does not perform official PCI assessments or issue PCI certifications; those results come from a qualified assessor company recognized by the PCI Security Standards Council.

See the PCI DSS & Payment Security service page for the readiness engagement.

Authoritative sources

Discuss Your Readiness