Category: 3-D Secure
Directory Server (DS)
Also known as:
Simply put
In EMV 3-D Secure, the Directory Server is a component operated within a card brand's network that helps route authentication messages between a merchant's side of a transaction and the card issuer's side. It also helps determine whether a given card can participate in 3-D Secure. It is a distinct role in the 3-D Secure ecosystem and should not be confused with general-purpose network directory servers such as LDAP directories.
Formal definition
The Directory Server (DS) is a role defined in the EMV 3-D Secure protocol, typically operated by a card scheme, that sits between the 3DS Server (merchant/acquirer side) and the Access Control Server (issuer side). It maintains card-range data used to determine 3-D Secure eligibility and routes authentication request/response messages across the EMVCo-defined interfaces. This DS role is separate and unrelated to general LDAP directory servers (for example, Active Directory Domain Services, 389 Directory Server, or PingDS/PingDirectory), which store and serve network directory objects over LDAP and are not part of the 3-D Secure message flow. Where a Directory Server participates in EMV 3-D Secure, its security controls are addressed by the PCI 3DS Core Security Standard rather than by PCI DSS alone; readers should confirm applicable requirements against the current published PCI 3DS materials.
Why it matters
In EMV 3-D Secure, the Directory Server sits at the center of the authentication ecosystem, connecting the merchant/acquirer side of a transaction to the card issuer side. Because it routes authentication messages and helps determine whether a given card can participate in 3-D Secure, its availability and integrity directly affect whether cardholder authentication can be attempted at all. Teams that build or assess 3-D Secure implementations need to understand this role precisely, because a component labeled "directory server" in a payments context is fundamentally different from a general-purpose LDAP directory server used for network identity and object storage.
Who it's relevant to
3-D Secure solution providers and card schemes
Organizations operating a Directory Server, generally card schemes, need to treat it as a defined role within the EMV 3-D Secure protocol and confirm which security controls apply. Where the DS participates in EMV 3-D Secure, its controls are addressed by the PCI 3DS Core Security Standard rather than by PCI DSS alone, and applicable requirements should be verified against current published PCI 3DS materials.
Merchant and acquirer engineering teams
Teams integrating a 3DS Server should understand that the Directory Server routes authentication messages between their side of the transaction and the issuer side, and helps determine whether a given card can participate in 3-D Secure. Recognizing the DS as a distinct 3-D Secure role helps avoid conflating it with LDAP infrastructure used elsewhere in their environment.
Compliance officers and assessors
Assessors scoping a 3-D Secure environment need to identify the Directory Server as an EMV 3-D Secure component and confirm the relevant standard, since PCI 3DS Core Security Standard addresses the DS role. Requirement wording and applicability should be checked against the current published PCI 3DS documents rather than assumed.
Infrastructure and identity teams
Staff who manage general-purpose LDAP directory servers such as Active Directory Domain Services, 389 Directory Server, or PingDS/PingDirectory should note that these are unrelated to the 3-D Secure Directory Server role. The naming overlap is a common source of confusion, and the two should not be treated as interchangeable in scoping or design discussions.
Inside DS
Card-range data
The Directory Server maintains and distributes ranges of primary account numbers (PANs) that indicate which issuer Access Control Servers (ACS) participate in 3-D Secure and how they can be reached. This routing information lets the DS determine whether a given card is enrolled and where to direct authentication messages.
Message routing function
The DS routes EMV 3-D Secure messages (such as authentication requests and responses) between the merchant/acquirer-side 3DS Server and the issuer-side ACS, acting as the intermediary component defined by the EMVCo 3-D Secure protocol.
EMVCo-defined interfaces
The DS connects to the 3DS Server and the ACS over the interfaces specified in the EMV 3-D Secure specification. Its behavior and message formats are governed by that protocol rather than by a general-purpose directory access protocol.
Card brand / network operation
A Directory Server is typically operated by or on behalf of a payment card brand (network), which is responsible for the participating card ranges and the ACS endpoints within its 3-D Secure ecosystem.
PCI 3DS applicability
Because it is a core 3-D Secure environment component, the Directory Server falls within the scope addressed by the PCI 3DS Core Security Standard. Practitioners should confirm the applicable requirements and current version against the published standard rather than assuming coverage under PCI DSS alone.
Common questions
Answers to the questions practitioners most commonly ask about DS.
Is the 3-D Secure Directory Server the same thing as an LDAP directory service?
No. Despite the shared word "directory," the EMV 3-D Secure Directory Server (DS) is not an LDAP directory service and does not store generic directory objects, user accounts, or certificate revocation lists in an LDAP tree. In the EMV 3-D Secure protocol, the DS is a component operated by or on behalf of a card scheme that sits between the merchant-side 3DS Server and the issuer-side Access Control Server (ACS). It maintains card-range data used to determine whether a given account range is enrolled and which ACS should handle a request, and it routes 3-D Secure authentication messages between the 3DS Server and the ACS over the defined EMVCo interfaces. Any resemblance to LDAP-based products is coincidental naming, not a shared function.
Is the 3-D Secure Directory Server outside the scope of any PCI standard?
No, that would be misleading. The Directory Server is one of the 3-D Secure environment components addressed by the PCI 3DS Core Security Standard, which is a separate standard from PCI DSS. Organizations operating a DS should confirm applicability and the specific requirements against the current published PCI 3DS documentation rather than assuming the DS falls under PCI DSS alone or under no standard. PCI 3DS is distinct from PCI DSS, PA-DSS, the PCI Software Security Framework, PCI PIN, and PCI P2PE, and the controls that govern the DS come from PCI 3DS, not from an LDAP or general-purpose directory context.
How does the Directory Server determine which Access Control Server should handle an authentication request?
The DS maintains card-range data supplied by participating issuers or their ACS providers. When a 3DS Server submits an authentication request, the DS uses the account range associated with the transaction to identify whether that range is participating and to route the message to the appropriate ACS. This routing role is central to how the DS connects the merchant side and the issuer side of a 3-D Secure transaction; readers should confirm the exact message flows and interface behavior against the current EMV 3-D Secure specification, since details can vary by protocol version.
What role does the Directory Server play in the overall 3-D Secure message flow?
The DS acts as an intermediary and router. It receives authentication-related messages from the 3DS Server, uses card-range data to identify the correct ACS, and passes messages between the two over the EMVCo-defined interfaces. It does not itself authenticate the cardholder; that function is performed by the issuer's ACS. The DS is intended to enable correct routing and participation checks, and it should not be described as performing risk decisioning or challenge flows on its own. Implementers should treat the DS, 3DS Server, and ACS as separate roles with distinct responsibilities.
What should teams consider when assessing a Directory Server for compliance?
Because the DS is a component addressed by the PCI 3DS Core Security Standard, assessment should follow the requirements defined there, confirmed against the current published version, since numbering and wording can differ between releases. Teams should scope the DS as part of the 3-D Secure environment, consider the systems and interfaces that connect to the 3DS Server and ACS, and avoid assuming that controls written for LDAP directories, general infrastructure, or PCI DSS alone map directly onto the DS role. Confirm which requirements apply to your specific operating model rather than relying on a fixed requirement reference.
Does the Directory Server store or process cardholder data or sensitive authentication data?
The DS works with card-range data used for participation checks and routing, which is different from storing full cardholder data or sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, PINs, or PIN blocks. Any handling of account-related data by the DS should be scoped and validated against the applicable PCI 3DS requirements and, where relevant, PCI DSS, based on the actual implementation rather than on the component name. Sensitive authentication data must not be retained after authorization in any environment, so implementers should confirm exactly what data the DS receives, uses, and retains in their deployment.
Common misconceptions
The 3-D Secure Directory Server is an LDAP directory service (such as an LDAP server, 389 Directory Server, or similar) that stores directory objects.
The 3-D Secure Directory Server (DS) is a component defined in the EMV 3-D Secure protocol. It maintains card-range data and routes 3-D Secure messages between the 3DS Server and the issuer Access Control Server over EMVCo-defined interfaces. It is not an LDAP directory service and is unrelated to general-purpose directory technologies.
The Directory Server performs the actual cardholder authentication decision.
The DS routes authentication messages and provides card-range/routing information; the authentication decision is made on the issuer side by the Access Control Server (ACS). The DS is intended to facilitate correct routing, not to authenticate the cardholder itself. As with other single controls, 3-D Secure participation does not by itself eliminate fraud.
The Directory Server is out of scope for PCI standards, or is governed by no specific standard requirement.
As a core 3-D Secure environment component, the DS is addressed by the PCI 3DS Core Security Standard, which is separate from PCI DSS. Practitioners should confirm the specific applicable requirements against the current published PCI 3DS standard rather than assuming it is unregulated.
Best practices
Design and assess the Directory Server as an EMV 3-D Secure component, confirming its message routing and card-range handling behavior against the current EMVCo 3-D Secure specification rather than treating it as a generic directory service.
Confirm the Directory Server environment against the applicable requirements of the current PCI 3DS Core Security Standard, and verify version and requirement wording against the published standard instead of assuming a fixed requirement number.
Keep card-range data used for routing accurate and current so that authentication requests are correctly directed to the appropriate issuer Access Control Server.
Secure the EMVCo-defined interfaces between the 3DS Server, Directory Server, and ACS, treating these connections as part of the in-scope 3-D Secure environment.
Coordinate with the operating card brand (network) on participating card ranges, ACS endpoints, and any brand- or region-specific network rules, recognizing that liability shift and related rules are governed by card brand rules that vary and change.
Avoid relying on 3-D Secure routing alone as a fraud control; treat it as one layer that may help reduce card-not-present fraud and combine it with other detection and authentication measures appropriate to the transaction risk.