Tokenization vs. Encryption: Which Reduces PCI Scope More?

In most environments, tokenization reduces PCI DSS scope more than encryption does. Encrypted primary account numbers (PAN) are still cardholder data, and they stay in scope for any organization that can decrypt them. Systems that hold only tokens, and have no way to turn a token back into a PAN, can fall out of scope entirely. Encryption only delivers comparable scope reduction when you never hold the decryption keys, which is the model behind point-to-point encryption (P2PE).

The details matter, though. Both techniques can be deployed in ways that shrink scope a lot, or barely at all. Here's how the PCI Security Standards Council (PCI SSC) looks at each one.

What's the difference between tokenization and encryption?

Encryption transforms a PAN using an algorithm and a key. Anyone with the right key can reverse it, so the ciphertext still represents the card number. For PCI DSS purposes, encrypted PAN is still PAN.

Tokenization replaces the PAN with a surrogate value, the token. The link back to the real PAN is kept by the tokenization system, usually in a secure data store called a token vault or card data vault. Systems that receive a token can use it as a reference, for refunds or recurring billing for example, without ever handling the card number.

Does encrypted cardholder data stay in PCI scope?

Usually, yes. PCI SSC FAQ 1086, "How does encrypted cardholder data impact PCI DSS scope?", sets out the position. The Council also explained it in a PCI Perspectives blog post. Encrypted cardholder data stays in scope in these situations:

• On systems that perform encryption, decryption or key management.
• When the encrypted data isn't isolated from encryption, decryption and key management processes.
• When the encrypted data sits on a system or media that also holds the decryption key.
• When the encrypted data is in the same environment as the decryption key.
• When the encrypted data is accessible to an entity that has access to the decryption key.

The Council's FAQ allows one narrow exception. When an entity receives or stores only data that another party encrypted, and it has no ability to decrypt it, that encrypted data may be out of scope for that entity. It has to be validated that the entity has no access to the cleartext data, the encryption process or the keys.

So if you encrypt a customer database yourself and manage the keys, you've met the requirement to render stored PAN unreadable (Requirement 3.4 in PCI DSS v3.2.1, 3.5.1 in v4.0). You haven't reduced scope. You've also added key management requirements to your to-do list. Encryption in transit works the same way. It's required when card data crosses open, public networks, but it doesn't take the sending or receiving systems out of scope.

When do tokenized systems fall out of scope?

The PCI SSC's PCI DSS Tokenization Guidelines information supplement (August 2011) sets out the Council's position. It's clear that tokenization doesn't remove the need to comply with and validate PCI DSS. What it can do is reduce the number of system components the requirements apply to.

What stays in scope

According to the guidelines, all components of the tokenization system are part of the cardholder data environment (CDE) and always in scope. That includes the card data vault, token generation and mapping, de-tokenization, and the cryptographic key management that protects the vault. If you run tokenization in-house, those components need the full weight of PCI DSS.

What can come out of scope

Systems that store, process or transmit only tokens may be considered out of scope when they:

• Are segmented from any application, system, process or user that can submit a de-tokenization request.
• Aren't connected to the tokenization system or its processes, including the vault.
• Hold tokens from which recovering the PAN isn't computationally feasible.

The first condition is where scope reduction often breaks down. If an order management system can call a de-tokenization API, or an operator in the billing tool can reveal the full PAN, that system is back in scope. Controlling who and what can de-tokenize is the heart of a tokenization design.

A caution about high-value tokens

The guidelines point out that some tokens can be used directly as payment instruments, for instance to initiate a new transaction. They call these "high-value tokens." Because they can be monetized, they may be worth as much to an attacker as the PAN itself, and they may need additional controls even if the PAN can't be recovered from them.

This is also a reminder that "token" means different things in payments. Payment tokens issued under card network or EMVCo frameworks serve a different purpose from the tokens a merchant uses to keep PAN out of its own systems. Check which kind you're dealing with before drawing scope conclusions.

Where does point-to-point encryption fit?

P2PE is the case where encryption does reduce merchant scope substantially. In a PCI-listed P2PE solution, card data is encrypted inside an approved payment terminal at the moment of capture. It's decrypted only in the solution provider's secure environment, and the merchant never has access to the keys. That lines up with the FAQ 1086 exception: the merchant handles only data it can't decrypt.

Merchants that process all card payments through a PCI-listed P2PE solution and follow the solution's P2PE Instruction Manual may be eligible for SAQ P2PE, one of the shortest self-assessment questionnaires. The current version of the standard is P2PE v3.1, published in September 2021.

Encryption solutions that aren't on the PCI SSC list may still be well built, but they don't qualify a merchant for SAQ P2PE. Any scope reduction they provide is a conversation with your acquirer and assessor.

Which reduces PCI scope more in practice?

It depends on who holds the keys or runs the vault, and how card data enters your environment. Here's how the common patterns compare:

Many organizations combine the two. A merchant might capture card-present payments with a P2PE solution and receive a token back from the provider for refunds and recurring charges. The encryption protects the capture point and the tokenization protects everything downstream.

For card-not-present channels, the same logic applies to hosted payment pages and provider-side tokenization. The less of the transaction flow your systems touch in cleartext, the smaller your CDE.

What should you check before relying on either?

Before you tell an assessor that a tokenization or encryption design takes systems out of scope, confirm these points:

• Key custody. Who generates, stores and can use the decryption keys? If it's you, the encrypted data is in scope.
• De-tokenization access. List every system, service account and role that can de-tokenize or reveal full PAN. Each one is in scope.
• Entry points. Find every place PAN enters before it's encrypted or tokenized, including web pages, call center workflows and back-office processes such as disputes.
• Leftover PAN. Run data discovery to catch cleartext PAN in logs, exports and legacy tables that predate the new design.
• Token format. If tokens look like card numbers, make sure you can reliably tell them apart. Otherwise data discovery results get noisy and assessors ask questions.
• Service provider evidence. If a third party runs the vault or the decryption environment, get its Attestation of Compliance and a clear split of responsibilities, and manage it under Requirement 12.8.
• Validation. Scope reduction has to be confirmed, typically by a Qualified Security Assessor or Internal Security Assessor. Document the design so it can be.

Frequently asked questions

Does encrypting our database take it out of PCI scope?

Not if you hold the keys. Encryption satisfies the requirement to render stored PAN unreadable, but the database, the applications that decrypt it and your key management all stay in scope.

Are tokens cardholder data?

A token from which the PAN can't feasibly be recovered isn't cardholder data. The tokenization system that maps tokens back to PAN is always in scope, and tokens that work as payment instruments may need extra protection.

If our payment provider returns tokens, are we out of scope?

Partly. Systems that store only those tokens and can't de-tokenize can come out of scope. Anything that captures, receives or passes PAN before tokenization, including the pages or devices where customers enter card data, still needs attention.

Is PCI DSS v4.0 changing any of this?

Not the underlying logic. PCI DSS v4.0 was published in March 2022, and v3.2.1 remains active until March 31, 2024. The requirement to render stored PAN unreadable moves to 3.5.1, and the scoping principles above carry over.

Key takeaways

• Encryption protects data but rarely shrinks scope for whoever holds the keys.
• Tokenization can take downstream systems out of scope, provided they can't de-tokenize and aren't connected to the tokenization system.
• The token vault, tokenization service and key management are always in scope.
• PCI-listed P2PE is the encryption model that delivers real merchant scope reduction, because the merchant never has the keys.
• Whatever design you choose, map every place PAN enters and every path back to cleartext before claiming anything is out of scope.