PCI 3DS Core Security Standard

Why does it matter?

EMV 3-D Secure adds an authentication layer to card-not-present purchases that helps prevent unauthorized transactions and protects the merchant from exposure to CNP fraud, which makes the servers that run it, the ACS, the DS and the 3DS Server, high-value components. The PCI 3DS Core Security Standard exists so that those components and the 3DS data passing through them are protected to one set of requirements that payment brands can require in their compliance programs and that qualified PCI 3DS Assessors can test the same way everywhere.

Key benefits include:

• One standard for three components

The same requirements apply to 3DS Server, Directory Server and Access Control Server functions as defined in the EMVCo 3DS Core Specification, with the HSM and data center requirements concentrated on the DS and ACS.

• Baseline plus 3DS-specific controls

Part 1 carries technical and operational requirements that reflect general information security principles; Part 2 adds the controls specific to 3DS data, technologies and processes (FAQ Q3).

• A defined data set to protect

The PCI 3DS Data Matrix names the EMVCo-defined data elements, the 3DS sensitive data and the key types the requirements cover, so scoping starts from a published list (FAQ Q5).

• Reuse of PCI DSS work where environments overlap

Where the 3DS environment and the cardholder data environment are one, validated PCI DSS controls may be used toward the Part 1 requirements under Appendix B of the standard; Part 2 is always assessed on its own (FAQ Q12, Q13).

• Qualified assessors and a living interpretation

Assessments are performed by PCI 3DS Assessors, and the Technical FAQs are a mandatory part of the standard that can interpret, add to or extend its requirements between revisions.

How does it work?

The standard defines a 3DS environment (3DE): the systems where 3DSS, DS or ACS functions are performed. Part 1 Baseline Security Requirements apply technical and operational security requirements that reflect general information security principles and practices common to many industry standards and should be considered for any type of environment; Part 2 3DS Security Requirements apply security controls intended specifically to protect 3DS data, technologies and processes. Each requirement is accompanied by an Implementation Guidance column, which gives examples of how a requirement could be met but is not itself a requirement and does not preclude other methods (FAQ Q4).

Part 2 is where the component-specific weight lies. Requirement P2-5 covers protection of 3DS data: P2-5.4.2 requires 3DS sensitive data, including the Authentication Value, to be encrypted before any permitted storage, unless the value is dynamic or already protected by strong cryptography as the payment system defines (Technical FAQ Q1). Requirement P2-6 covers cryptography and key management for all 3DS components, and P2-6.1.2 requires environments housing DS and ACS systems to use a FIPS 140-2 Level 3 (overall) or higher certified, or PCI PTS approved, HSM for all key management activity; P2-6.2 and P2-6.3 also apply only to the ACS and DS, and an HSM is recommended but not required where only a 3DS Server is present (Technical FAQ Q2). Requirements P2-7.1 and P2-7.2, on data center and CCTV security, likewise apply to DS and ACS systems (Technical FAQ Q5).

Validation is a brand decision: the payment brand compliance programs define whether an entity must validate, and queries about compliance go to the applicable brand (FAQ Q2, Q7). A PCI 3DS Assessor performs the assessment and documents the result in the 3DS Report on Compliance and attestation documents; where PCI DSS controls have been applied and validated for all 3DE system components, the assessor documents that coverage toward Part 1 (FAQ Q13). Since September 29, 2023, Technical FAQ Q3 allows non-console HSM access solutions to meet P2-6.2.1 through P2-6.2.5 by an alternative set of criteria met in its entirety, instead of only by an independent laboratory evaluation against ISO 13491.

Key Elements

• 3DS Server, Directory Server and Access Control Server

The three core components defined in the EMVCo 3DS Core Specification whose operators the standard applies to (FAQ Q2); the draft v2.0 adds the Split-SDK Server.

• Part 1: Baseline Security Requirements

Technical and operational requirements for environments where 3DS functions are performed, reflecting general information security principles common to many industry standards (FAQ Q3).

• Part 2: 3DS Security Requirements

Controls specific to 3DS data, technologies and processes, including P2-5 on 3DS data protection, P2-6 on cryptography and key management and P2-7 on the physical security of DS and ACS facilities.

• PCI 3DS Data Matrix

A separate supporting document, at v1.1 when the 2023 request for comments opened, that identifies the EMVCo-defined 3DS data elements subject to the standard, the 3DS sensitive data and the cryptographic key types subject to HSM requirements (FAQ Q5).

• Implementation Guidance column

Additional information on how a requirement could be met; not a requirement, and it neither replaces nor extends the requirement it accompanies (FAQ Q4).

• Technical FAQs

An integral and mandatory part of the standard, considered during every assessment; the April 2021 set covers P2-5, P2-6 and P2-7, and the September 2023 revision of Q3 added alternative criteria for HSM access.

• PCI 3DS Assessors

Qualified through the 3DS Assessor Program: from Q4 2017 P2PE Assessors and Visa 3-D Secure v1 assessors who were also QSAs, then from early 2018 QSAs with three years' experience, training and an examination (FAQ Q6).

• Appendix B: alignment with PCI DSS

Sets the conditions for using PCI DSS assessment results toward Part 1 where the 3DE and the cardholder data environment are combined; PCI DSS results cannot be used to validate Part 2 (FAQ Q13).

What does it cover?

The standard applies to entities that perform or provide 3DSS, DS or ACS functions, and third-party service providers that can affect those functions or the security of their environments may also be required to meet the requirements applicable to the service they provide (FAQ Q2). It applies to the 3DS environment whether or not account data is present: a 3DS entity involved only in transactions using EMVCo payment tokens may have no PCI DSS obligation and still be in scope for PCI 3DS (FAQ Q11). It does not cover 3DS Software Development Kits, which fall under the separate and independent PCI 3DS SDK Security Standard, and validation against one of those standards does not imply or result in validation against the other (FAQ Q10).

What are its objectives?

The FAQs published with version 1.0 and the 2023 request for comments describe what the standard is for:

To protect the environments where 3DS Server, DS and ACS functions are performed, through baseline technical and operational requirements (Part 1).

To protect 3DS data, technologies and processes with controls specific to 3DS, including encryption of 3DS sensitive data and HSM-based key management for the DS and ACS (Part 2).

To implement physical and logical security controls that support the integrity and confidentiality of the 3DS transaction process, as the request for comments describes the standard.

To give payment brands a common standard on which their compliance programs can require validation by qualified PCI 3DS Assessors.

To align with PCI DSS where environments overlap, so that Part 1 can draw on a PCI DSS assessment without replacing or diminishing either standard.

Framework in Context

PCI 3DS Core was announced the week of October 25, 2017 at the PCI Europe Community Meeting and sits beside PCI DSS as a separate, independent standard: PCI DSS applies wherever payment card account data is stored, processed or transmitted, PCI 3DS wherever 3DSS, ACS or DS functions are performed, and an entity meeting both consults its acquirer or payment brand on which to validate (FAQ Q11). The PCI 3DS SDK Security Standard covers 3DS SDK developers under its own program (FAQ Q10). PCI SSC revised the standard's interpretation through the Technical FAQs in April 2021 and September 2023, and ran a request for comments on draft PCI 3DS Core Security Standard v2.0 and draft PCI 3DS Data Matrix v2.0 from December 6, 2023 to January 19, 2024, with the draft covering the ACS, DS, 3DS Server and Split-SDK Server; no v2.0 publication appears on the PCI SSC pages read, so v1.0 remains the version in force.

Common Framework Mappings

PCI 3DS Core is commonly mapped to PCI DSS, whose Part 1 alignment the standard itself documents in Appendix B, and to the general security control frameworks that its baseline requirements reflect.

Mapped frameworks include:

CIS Controls v8.1

ISO 27001:2022

NIST CSF 2.0

PCI DSS 4.0.1

PCI PIN Transaction Security (PCI PTS)

PCI Point-to-Point Encryption (PCI P2PE)

PCI Software Security Framework (PCI SSF)

SOC 2