PCI 3DS Compliance for ACS, DS, and 3DS Server Providers: Who Needs What

Ask five people in payments what PCI 3DS actually requires, and you'll usually get five different answers. Some assume it's just PCI DSS with a different name. Others think it only applies to card issuers. A few have never heard of it until an acquirer or network sends them a validation request out of nowhere.

None of that is surprising. PCI 3DS sits in an odd corner of the compliance world — tied closely to EMVCo's protocol work, but governed separately by the PCI Security Standards Council, and applied differently depending on which piece of the 3-D Secure chain you actually operate. If you run an ACS, a Directory Server, or a 3DS Server, the standard applies to you, but not in the same way, and not with the same paperwork.

We'll walk through what each role actually does, what the standard expects from each one, and how the validation process plays out in practice.

First, What Is PCI 3DS Actually Protecting?

3-D Secure is the mechanism behind that extra authentication step you sometimes see when paying online — the one-time code, the bank app prompt, the "verify it's you" screen. It's how issuers confirm a cardholder is really the one making a purchase, without adding friction to every single transaction.

The PCI 3DS Core Security Standard exists to secure the infrastructure that makes that authentication possible. Specifically, it covers three components: the 3DS Server, the Directory Server, and the Access Control Server. Together, these make up what PCI calls the 3DS Environment, and that environment — not just the servers themselves, but the networks, facilities, and supporting systems around them — is what gets assessed.

One thing that trips people up early: PCI 3DS is not PCI DSS. They come from the same council, but they protect different things. DSS is about the cardholder data environment, where card numbers live. 3DS is about the authentication environment, where the decision to approve or challenge a transaction gets made. A lot of organizations end up needing both, but they're validated on separate tracks, by separate assessors, with separate reports.

The Three Roles, and Who Usually Runs Them

Before getting into requirements, it helps to actually know what each piece does, because the compliance burden follows the function almost exactly.

If your organization performs any of these functions, even as a vendor operating on behalf of a bigger client, PCI 3DS applies. Size doesn't matter here. A small processor running an ACS on behalf of a regional issuer has the same obligation as a major bank running one in-house.

Who Actually Has to Validate

The PCI SSC requires validation from anyone who performs or provides ACS, DS, or 3DSS functions. In practice, that catches a wider group than most people expect:

• Issuers and issuer processors running an ACS
• Networks and their designated Directory Server operators
• Acquirers, gateways, and PSPs running a 3DS Server
• Third-party vendors delivering any of the above as a hosted or white-label service

Here's a nuance worth knowing: not every requirement in the standard applies with equal weight to every role. The physical security controls under Requirement P2-7 — things like restricted data center access and CCTV monitoring — are mandatory for DS and ACS environments, since those systems handle more sensitive network- and issuer-level data. For a location running only a 3DS Server, those same controls are recommended but not required. So "we're in scope" is really just the starting point. The real work is figuring out exactly how the standard maps to your specific role.

What's Actually in the Standard

PCI 3DS breaks into two parts, and once you see the split, the standard stops feeling like a black box.

Part 1 covers baseline security requirements — the stuff you'd expect from any mature security program. Access control, network segmentation, vulnerability management, incident response, personnel policies. If your team already runs PCI DSS or holds an ISO 27001 certification, a good chunk of this will look familiar.

Part 2 gets specific to how 3DS actually works: protecting the cryptographic keys used in authentication, securing data as it moves between the 3DSS, DS, and ACS, and — for DS and ACS in particular — locking down the physical environments where these systems run.

Here's how that plays out across the three roles:

Getting Through Validation

The process tends to follow the same general sequence regardless of which role you're in:

Most organizations pursue EMVCo's functional testing first, since the two processes are closely related in practice and card networks generally expect to see it. But an EMVCo Letter of Approval is not a formal prerequisite for a PCI 3DS assessment to begin — PCI SSC's own guidance confirms an assessment can proceed without one already in hand, with the Attestation of Compliance simply noting an alternate basis for the assessed implementation. Once functional testing is underway or complete, a qualified 3DS Assessor helps scope the environment — deciding exactly which systems, networks, and physical locations fall inside the assessment boundary. Get this step wrong and everything downstream gets more expensive.

The assessment itself involves interviews, configuration sampling, and document review against the applicable requirements. Once that's done, it results in a 3DS Core Report on Compliance and an Attestation of Compliance, which get submitted to the relevant payment brands. If gaps turn up along the way, there's a remediation cycle before the organization is considered fully validated.

And like most PCI programs, this isn't a one-time project. Validation runs annually, so budgeting and staffing for it needs to be treated as a recurring line item, not a one-off initiative.

A Few Things People Get Wrong

"We already passed EMVCo testing, so we're PCI 3DS compliant." Not the same thing. EMVCo confirms your implementation follows the protocol correctly. PCI 3DS confirms the environment running that implementation is actually secure. Most organizations need both, and they're two completely separate processes.

"PCI 3DS and the PCI 3DS SDK standard are basically the same thing." They're not, even though the names are similar. The SDK standard covers organizations building 3DS software development kits for the consumer-facing app side. It's a distinct program with its own requirements — passing one doesn't validate you against the other.

"This is really only an issuer's problem." As the table above shows, acquirers, PSPs, gateways, and network operators all carry their own share of the obligation, depending on which piece they run.

Why This Is Worth Taking Seriously

It's easy to treat any PCI standard as paperwork to get through once a year. But the 3DS environment sits at a genuinely sensitive point in the transaction chain — a compromised ACS or Directory Server doesn't just affect one merchant's checkout flow, it can touch authentication decisions across an entire card network. Teams that treat the assessment as a real security exercise, rather than a box to check, tend to walk away from it in a much stronger position than teams that just want the certificate.

Where to Start

PCI 3DS compliance isn't one standard applied uniformly — it's three distinct sets of obligations shaped by where you sit in the authentication flow. The fastest way to get clarity is to nail down which of the three roles actually applies to you, then map your environment's real boundaries before an assessor ever walks in the door.

If you're at the beginning of that process, start with scoping. Bringing in a qualified 3DS Assessor early to define the environment properly will save far more time than trying to fix scope after the assessment is already underway.

FAQs