What is the PCI 3DS Core Security Standard and who does it apply to?
The PCI Security Standards Council publishes the PCI 3DS Core Security Standard to secure environments where specific 3-D Secure (3DS) functions take place. In practice, it protects the authentication layer that connects cardholders, merchants, and issuers during an online transaction. Furthermore, the standard splits into two parts: Part 1 covers Baseline Security Requirements, while Part 2 targets the unique risks of authentication environments.
The standard applies to entities that perform any of three core 3DS functions:
- 3DS Server (3DSS): the merchant-side component that initiates the authentication request
- 3DS Directory Server (DS): the card scheme component that routes messages between the 3DSS and the ACS
- 3DS Access Control Server (ACS): the issuer-side component that authenticates the cardholder
How does PCI 3DS relate to PCI DSS?
PCI 3DS and PCI DSS are independent but complementary standards. If your 3DS Data Environment sits inside a Cardholder Data Environment, and a PCI DSS assessment from the last 12 months already covers all 3DS components, you can reuse those results to satisfy PCI 3DS Part 1. As a result, you avoid assessing the same controls twice.
However, Part 2 always applies fully to 3DS components, regardless of your PCI DSS status. In fact, it covers authentication-specific risks that PCI DSS does not address, such as the protection of authentication data during a transaction, cryptographic operations inside the ACS and DS, and the integrity of 3DS messages between participants.
What does the PCI 3DS SDK Security Standard cover?
The PCI 3DS SDK Security Standard governs 3-D Secure Software Development Kits (3DS SDKs) that merchants integrate into their mobile apps. Specifically, it applies to 3DS SDK Vendors, meaning the entities that build these SDKs. SDKs run on untrusted consumer devices that may be rooted, jailbroken, or under active attack. Therefore, the standard mandates strong defenses across five areas:
- Protection of sensitive 3DS SDK data elements
- SDK hardening against reverse engineering and hooking
- Secure storage and transmission of cryptographic material
- Anti-debugging and runtime integrity checks
- Secure key management within the SDK
Are Hardware Security Modules (HSMs) required in 3DS environments?
HSMs are mandatory for Access Control Server (ACS) and Directory Server (DS) environments. Specifically, you must perform all key management activities for specified cryptographic keys inside an HSM that is either FIPS 140-2 Level 3 (or higher) certified, or PCI PTS HSM approved.
This rule matters because ACS and DS environments run the cryptographic operations that anchor the entire 3DS trust model. In addition, keys used to sign and verify authentication messages cannot sit in software keystores, because attackers can extract them. However, the rule softens for 3DS Server (3DSS) environments, where an HSM is strongly recommended but not strictly required.
Can sensitive 3DS data be stored temporarily for troubleshooting or debugging?
No. You must securely delete sensitive 3DS SDK data elements as soon as the 3DS transaction completes. In addition, you cannot retain them beyond the transaction unless the standard explicitly permits it, and permitted cases are narrow.
The debugging rule is equally strict. Specifically, 3DS vendors must never debug code or troubleshoot issues using live or production Authentication Challenge Data (CReq/CRes messages). Instead, all debugging must take place in a dedicated test environment using manually generated test data. As a result, this rule requires separate non-production pipelines and strict access controls to prevent production data from leaking into development tools.
