The servers that run EMV 3-D Secure decide, millions of times a day, whether an online cardholder is who they claim to be, so a compromise of an Access Control Server, Directory Server or 3DS Server undermines fraud controls for every merchant and issuer that relies on it. The PCI Security Standards Council's PCI 3DS Core Security Standard sets the security requirements and assessment procedures for environments that perform those three functions. This guide explains who the standard applies to, how its two parts are organised, what the seven 3DS-specific requirements expect, where identity and key management fit, how to prepare for a 3DS assessment and how the standard maps to PCI DSS and NIST frameworks. It is for security, compliance and engineering teams at ACS, DS and 3DS Server operators and their hosting providers. For how the protocol itself works and how merchants tune it, see the EMV 3-D Secure Guide; for the wider fraud picture, see the Payment Fraud Guide.
Key takeaways
- It covers 3DS component operators, not merchants. The standard applies to environments that perform ACS, DS or 3DS Server functions as defined in EMVCo's EMV 3-D Secure specification; payment brands decide which entities must validate.
- Two parts, two purposes. Part 1 sets baseline security controls for the environment (P1-1 to P1-7), and Part 2 sets 3DS-specific controls for 3DS data, technology and processes (P2-1 to P2-7).
- Version 1.0 is in force; version 2.0 has been in draft. PCI SSC ran a request for comments on draft v2.0 of the standard and data matrix from 6 December 2023 to 19 January 2024; as of 8 November 2026 the Council's pages fetched for this guide did not show a v2.0 publication date.
- Keys and HSMs carry the most risk. P2-6 Cryptography and key management and P2-7 physical security, which PCI SSC says is required for DS and ACS facilities, are where assessments go deepest.
- Machine identities run the 3DS flow. Server-to-server messaging between 3DS Server, DS and ACS depends on certificates, keys and service accounts, which need the same governance as privileged human access.
What it is and who it applies to
PCI SSC describes the PCI 3DS Core Security Standard as security requirements, validation methods and implementation guidance for environments that perform ACS, DS and/or 3DS Server (3DSS) functions, as defined in the EMV 3-D Secure specification. Its formal title is the PCI 3DS Security Requirements and Assessment Procedures for EMV 3-D Secure Core Components: ACS, DS and 3DS Server. It was introduced in October 2017, and the Council's 25 October 2017 announcement states that compliance requirements for these entities are defined by the applicable payment brands.
| Component | Role in EMV 3DS | Typical operator |
|---|---|---|
| 3DS Server (3DSS) | Collects transaction and device data on the merchant side and sends authentication requests to the Directory Server | Merchants' payment service providers, gateways, large merchants |
| Directory Server (DS) | Routes messages between the 3DS Server and the issuer's ACS for a card scheme | Payment brands or their processors |
| Access Control Server (ACS) | Performs the issuer's risk-based authentication and any cardholder challenge | Issuers or issuer processors |
| 3DS SDK | Runs in the merchant's mobile app; covered by the separate PCI 3DS SDK Security Standard | Software vendors |
Who decides whether you must comply
- Payment brands: PCI SSC states that the payment brands run compliance programmes and that questions about who must validate go to them. A related FAQ tells entities acting as a 3DS Server, DS or ACS to confirm with the brands they serve whether the standard applies.
- EMVCo approval is separate: EMVCo runs functional product approval for 3DS components. A PCI SSC FAQ confirms that a 3DS assessment can take place without an EMVCo Letter of Approval, with the reason recorded in the Attestation of Compliance; whether brands accept that is their decision.
- PCI DSS still applies to account data: a PCI SSC FAQ states that 3DS authentication values and other 3DS sensitive data in the PCI 3DS Data Matrix are not sensitive authentication data under PCI DSS, so the two standards address different data and you may need both. See the PCI DSS 4.0 Guide.
Version status (checked 8 November 2026)
PCI SSC announced revision work on the PCI 3DS Core and SDK standards on 7 September 2023, citing EMVCo's updated 3DS specifications and new Split-SDK implementations, and said organisations can continue to use the published standards. The request for comments on draft PCI 3DS Core Security Standard v2.0 and draft PCI 3DS Data Matrix v2.0 ran from 6 December 2023 to 19 January 2024 and described v1.0 of the standard and v1.1 of the data matrix as the current published versions. Check the PCI SSC document library for any later release before planning an assessment. On the protocol side, EMVCo published draft EMV 3DS Protocol and Core Functions Specification v2.4.0.0 material on 4 November 2026 with comments open until 8 January 2027.
Structure and key requirements
The standard is organised in two parts, supported by the PCI 3DS Data Matrix, which lists the 3DS data elements and key types the requirements apply to. The requirement titles below are those used in the v1.0 Attestation of Compliance template.
| Part 1: Baseline security requirements | Part 2: 3DS security requirements |
|---|---|
| P1-1 Maintain security policies for all personnel | P2-1 Validate scope |
| P1-2 Secure network connectivity | P2-2 Security governance |
| P1-3 Develop and maintain secure systems | P2-3 Protect 3DS systems and applications |
| P1-4 Vulnerability management | P2-4 Secure logical access to 3DS systems |
| P1-5 Manage access | P2-5 Protect 3DS data |
| P1-6 Physical security | P2-6 Cryptography and key management |
| P1-7 Incident response preparedness | P2-7 Physically secure 3DS systems |
What each Part 2 requirement means in practice
- P2-1 Validate scope: document the 3DS environment, every system that stores, processes or transmits 3DS data or can affect its security, data flows and connections to other environments. Scope work here resembles PCI DSS scoping. See the PCI DSS Scoping and Network Segmentation Guide.
- P2-2 Security governance: assigned responsibility for 3DS security, risk assessment and oversight of third parties that host or support the 3DS functions.
- P2-3 Protect 3DS systems and applications: hardening, secure software development and change control for the 3DS application stack and its supporting infrastructure.
- P2-4 Secure logical access to 3DS systems: unique accounts, strong authentication, least privilege and review of access to 3DS systems, including administrative and service access.
- P2-5 Protect 3DS data: protect the data elements listed in the PCI 3DS Data Matrix in storage and transit, and limit retention.
- P2-6 Cryptography and key management: secure generation, distribution, storage, use, rotation and destruction of the keys used in 3DS messaging and data protection, typically with hardware security modules. See the Payment HSMs guide.
- P2-7 Physically secure 3DS systems: PCI SSC's FAQ states that P2-7.1 and P2-7.2 (data centre and CCTV security) apply to DS and ACS systems as critical components, needing elevated physical controls to restrict, manage and monitor access; for locations hosting only a 3DS Server, P2-7 is recommended but not required.
Read the requirement text, testing procedures and guidance in the standard itself from the PCI SSC document library; this summary is not a substitute.
Identity and NHI requirements
A 3DS environment is largely machine-to-machine. The 3DS Server, DS and ACS authenticate each other, sign and encrypt messages, call risk engines and HSMs, and are deployed by pipelines. Each of those interactions uses a non-human identity: a TLS client certificate, a signing key, an HSM partition credential, a database service account or a deployment token. P2-4 and P2-6 cover these as much as they cover administrators.
| Identity in the 3DS environment | Requirement it falls under | Control we recommend |
|---|---|---|
| Administrator and operator accounts | P1-5, P2-4 | Individual accounts, MFA, just-in-time elevation through a PAM tool, session recording |
| TLS certificates for 3DSS, DS and ACS connections | P2-5, P2-6 | Certificate inventory with owners, automated renewal, alerting well before expiry. See the Machine Identity, PKI and Certificate Lifecycle Guide |
| Signing and encryption keys | P2-6 | Keys generated and used inside HSMs, split knowledge and dual control for key ceremonies, documented crypto-periods |
| Application service accounts (database, risk engine, HSM client) | P2-4 | Unique per service, least privilege, no interactive login, secrets in a vault with rotation. See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6) |
| CI/CD and infrastructure automation credentials | P2-3, P2-4 | Short-lived federated credentials, separate pipelines for the 3DS environment, approval gates for production change. See the CI/CD Pipeline Identity Security Guide |
| Third-party support access | P2-2, P2-4 | Named accounts, time-bound access, monitored sessions |
The control column reflects NHI Mgmt Group's recommendations for meeting the intent of the requirements; the assessor will test against the standard's own testing procedures. For key management practice, see the Cryptographic Key Management Guide.
Implementation steps
- Confirm the obligation. Ask each payment brand you serve whether you must validate to PCI 3DS Core, by when and in what form, and record the answer.
- Get the current documents. Download the standard, the PCI 3DS Data Matrix and the reporting templates from the PCI SSC document library, and check for any release after v1.0.
- Define scope (P2-1). Map the 3DS environment, data flows, connected systems and third parties. Reduce scope with segmentation where you can.
- Decide how Part 1 will be evidenced. If a current PCI DSS assessment already covers the same environment, ask your 3DS assessor how the standard and reporting templates let you use it; otherwise plan a Part 1 assessment.
- Gap-assess Part 2. Work through P2-2 to P2-7 with owners. Start with key management and physical security, which take longest to fix.
- Remediate in priority order. Key ceremonies and HSM configuration, privileged and service access, logging, then documentation. Test changes in a non-production 3DS environment against EMVCo test tooling before release, and keep a rollback plan for each production change so authentication traffic is not interrupted.
- Run a readiness review. Have an internal or external party walk the testing procedures before the formal assessment.
- Engage a 3DS assessor. PCI SSC lists qualified 3DS assessors, who assess under the 3DS Assessor Program Guide.
- Submit and maintain. Send the Report on Compliance and Attestation of Compliance to the brands as they require, then keep controls running between assessments.
Decision points
- Build or outsource: merchants and smaller PSPs often use a hosted 3DS Server from a provider that has validated, which moves most of the burden to the provider; confirm the provider's attestation covers the functions you use. See the PCI DSS for Service Providers and Responsibility Matrix Guide.
- Own data centre or cloud: cloud hosting is possible, but ACS and DS operators must show how P2-7 physical controls are met by the hosting provider.
- Dedicated or shared HSMs: dedicated payment HSMs simplify evidence for P2-6; shared or cloud HSM services need clear evidence of key isolation and dual control.
Evidence and assessment
| Area | Evidence assessors typically ask for |
|---|---|
| Scope (P2-1) | Network and data flow diagrams, system inventory, segmentation test results |
| Governance (P2-2) | Named responsibilities, risk assessment, third-party agreements and oversight records |
| Systems (P2-3) | Hardening standards, change records, secure development evidence, vulnerability scans |
| Access (P2-4) | Account lists including service accounts, MFA configuration, access reviews, privileged session logs |
| Data (P2-5) | Data inventory mapped to the PCI 3DS Data Matrix, encryption configuration, retention settings |
| Keys (P2-6) | Key inventory, key ceremony scripts and logs, HSM configuration, crypto-period records, custodian forms |
| Physical (P2-7) | Data centre access lists, CCTV retention, visitor logs, hosting provider attestations |
Metrics that show the programme is working
- Key inventory accuracy: keys found in HSMs and configuration that are missing from the key inventory (target zero).
- Certificate health: 3DS connection certificates expiring within 30 days without a renewal ticket.
- Privileged access: percentage of administrative sessions through the PAM tool with recording.
- Service account hygiene: percentage of 3DS service accounts with an owner, least-privilege review and rotation in date.
- Patch latency: median days to remediate critical vulnerabilities on 3DS systems.
- Assessment findings: open findings from the last assessment and readiness review.
Mapping to other frameworks
| PCI 3DS requirement | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| P2-1 Validate scope | CA-2, PM-5 | ID.AM |
| P2-2 Security governance | PM-9 | GV.RR |
| P2-3 Protect 3DS systems and applications | CM-3, SA-11 | PR.PS |
| P2-4 Secure logical access | AC-6, IA-2(1) | PR.AA |
| P2-5 Protect 3DS data | SC-8, SC-28 | PR.DS |
| P2-6 Cryptography and key management | SC-12 | PR.DS |
| P2-7 Physical security | PE-3, PE-6 | PR.AA |
This mapping is NHI Mgmt Group's own, at category level, to help teams that already run NIST controls reuse evidence. We have not listed PCI DSS v4.0 requirement numbers because PCI SSC does not publish a 3DS to PCI DSS crosswalk on its web pages. It does not mean a PCI DSS assessment satisfies Part 2. For the related PCI key management standard, see the PCI PIN Security and Key Management Operations Guide.
Common pitfalls
- Assuming PCI DSS is enough: 3DS data is not sensitive authentication data under PCI DSS, and Part 2 controls are 3DS-specific, so a PCI DSS Attestation of Compliance does not show 3DS compliance.
- Scope drawn too tightly: monitoring, jump hosts, deployment pipelines and HSM management stations left out of the 3DS environment even though they can affect its security.
- Key ceremonies without evidence: keys generated correctly but with no signed ceremony record, custodian forms or crypto-period documentation for the assessor.
- Unmanaged machine credentials: long-lived service account passwords and shared API credentials between 3DS components, outside any vault or rotation process.
- Physical controls assumed from the cloud provider: ACS and DS operators who cannot produce evidence of how P2-7 data centre and CCTV controls are met.
- Building to a draft: designing controls around draft v2.0 content seen during the comment period rather than the published standard your assessor will use.
Practitioner checklist
- Confirm in writing with each payment brand whether and when you must validate to PCI 3DS Core.
- Download the current standard, PCI 3DS Data Matrix and templates from the PCI SSC document library and check for releases after v1.0.
- Document the 3DS environment scope, data flows and third parties (P2-1).
- Inventory every key, certificate and service account in the 3DS environment, each with an owner.
- Keep 3DS keys in HSMs under dual control with recorded key ceremonies (P2-6).
- Put all administrative access through MFA and a PAM tool with session recording (P2-4).
- Confirm DS and ACS facilities meet P2-7 data centre and CCTV requirements, including at hosting providers.
- Run a readiness review against the testing procedures before engaging a 3DS assessor.
- Track the six metrics above between assessments.
Standards and references
- PCI SSC: PCI 3DS Core Security Standard
- PCI SSC: What to know about the new PCI 3DS Core Security Standard
- PCI SSC: Update on revision efforts for PCI 3DS Core and SDK standards
- PCI SSC: Request for comments, draft PCI 3DS Core Security Standard v2.0
- PCI SSC: FAQ on 3DS components in scope for Requirement P2-7
- PCI SSC: FAQ on 3DS authentication values and sensitive authentication data
- PCI SSC: FAQ on EMVCo Letters of Approval and 3DS assessments
- EMVCo: EMV 3-D Secure
Related NHI Mgmt Group resources: EMV 3-D Secure Guide · Payment Fraud Guide · Payment HSMs · PCI DSS 4.0 Guide. This guide summarises the PCI 3DS Core Security Standard and is not legal advice.