Tokenization vs Encryption for PCI DSS PAN Protection

Two tools, two problems

Tokenization and encryption both protect the primary account number (PAN), but they solve different PCI DSS problems. Encryption protects PAN that you still need to retain. Tokenization replaces PAN you do not need to retain with a non-sensitive surrogate. Mature PCI DSS programs use both: tokenize everywhere you can to shrink the cardholder data environment, and encrypt everywhere you must actually store PAN.

Under PCI DSS, this distinction matters for scope. A system that stores encrypted PAN is still in scope for PCI DSS because the ciphertext, when decrypted, is cardholder data. A system that stores only tokens is generally out of PCI DSS scope because tokens are not cardholder data -- provided the tokenization implementation meets the PCI SSC's guidance on token generation, mapping, and vault isolation. The scope implication is why tokenization is such a powerful lever in a PCI DSS program and why most CFOs quickly support tokenization projects even when the implementation cost looks high.

How PCI DSS encryption works

PCI DSS Requirement 3 governs stored account data. Acceptable methods for rendering PAN unreadable include one-way hashing, truncation, strong cryptography with associated key management (encryption), and index tokens. Encryption is by far the most common -- AES-256 in authenticated modes is the baseline, with RSA or elliptic-curve key wrapping for key management.

Encryption as a PCI DSS control brings along a whole key-management program:

• Unique keys per environment and purpose.
• Documented key lifecycle -- generation, distribution, storage, rotation, retirement, and destruction.
• Hardware security module (HSM) or equivalent cryptographic module for root keys.
• Key custodians with documented responsibilities and signed key custodian agreements.
• Annual cryptographic key rotation or a cryptoperiod driven by documented risk analysis.
• Access controls that enforce dual control and split knowledge for the most sensitive keys.

All of this is covered by PCI DSS Requirement 3, with supporting testing in Requirements 8 (authentication) and 10 (logging). Encryption is the right tool when the business truly needs the PAN -- card-on-file payments for recurring billing, payment processors performing settlement, or issuers generating card numbers. Encryption does not take the encrypted data out of PCI DSS scope.

How PCI DSS tokenization works

Tokenization replaces a PAN with a surrogate value that has no exploitable mathematical relationship to the original. The mapping from token to PAN is stored in a separate, highly protected system called the token vault. Systems that need to process the PAN (payment gateways, fraud tools, issuer systems) talk to the token vault; every other system holds only the token.

A PCI DSS-compliant tokenization program typically has:

• A centralized token vault operated either in-house on PCI-assessed infrastructure or by a PCI DSS-validated tokenization service provider.
• Strong cryptographic or non-deterministic mapping so tokens cannot be reversed without the vault.
• Unique tokens per PAN, or per PAN plus merchant, or per PAN plus purpose, depending on business need.
• Access controls that limit detokenization to a narrow set of service identities and humans.
• Logging of every detokenization event.
• Documented procedures for token issuance, rotation, and invalidation.

Systems that only hold tokens and never interact with the vault can typically be treated as out of PCI DSS scope. In practice, those systems often include CRM platforms, analytics warehouses, order-management systems, customer support tools, email and marketing platforms, and much of the operational infrastructure that would otherwise be pulled into PCI DSS scope simply because it touches PAN. The net effect is often an order-of-magnitude reduction in the PCI DSS footprint.

Format-preserving tokens

Some applications expect a value that looks like a PAN -- 16 digits, the right leading BIN, Luhn-valid. Format-preserving tokens (sometimes called FPE tokens) satisfy those constraints by producing surrogates that pass PAN-shape validation. Format-preserving tokens are popular for retrofitting tokenization into legacy systems that would otherwise need invasive schema changes.

Format-preserving tokens come with care-and-feeding issues:

• They can be confused with real PANs by testers, developers, and incident responders. Clear documentation and distinct BIN ranges help.
• They must not be trivially reversible -- format-preserving encryption (FPE) is different from format-preserving tokenization, and PCI DSS treats them differently.
• Detection rules (DLP, log scrubbing) must handle format-preserving tokens differently from real PANs to avoid noise.
• Logs and audit trails should clearly indicate whether a value is a token or a real PAN.

Used well, format-preserving tokens let you deploy tokenization without re-architecting systems. Used poorly, they recreate PCI DSS confusion.

Vault management

The token vault is the highest-value asset in a tokenization program. It sits squarely in the PCI DSS cardholder data environment and deserves the strongest controls in the program:

• Dedicated network segment with the fewest possible connections in and out.
• Strict allow-list of service identities and humans authorized to detokenize.
• Hardware-backed cryptography for the vault's encryption keys.
• Comprehensive logging of every token-to-PAN lookup.
• Rate limiting and anomaly detection on detokenization requests -- a compromised service account that starts detokenizing at unusual volume is one of the clearest intrusion signals.
• Robust disaster recovery and backup controls that preserve the confidentiality of the vault's contents.

Whether you run the vault yourself or buy from a tokenization service provider, you need evidence that these controls are in place. If you use a service provider, their PCI DSS AOC and Responsibility Matrix are required evidence.

When each applies

• Tokenize everywhere PAN is not strictly needed for business function. This usually covers customer service tooling, CRM, analytics, marketing, order management, and most of your application stack.
• Encrypt PAN in the systems that must retain it -- payment processors, settlement systems, recurring-billing engines, and the token vault itself.
• Use P2PE for card-present environments to remove the merchant's internal network from PCI DSS scope entirely.
• Truncate or hash PAN where you only need the last four or a reference value -- receipts, reports, analytics dashboards. Truncation is free scope reduction.

The strategic question is rarely "tokenize or encrypt" but "how do we combine tokenization, encryption, truncation, and P2PE to arrive at the smallest possible PCI DSS scope with the strongest possible protection."

How this fits into PCI DSS compliance

Tokenization and encryption interact with a majority of PCI DSS requirements. Requirement 3 covers stored account data protection. Requirement 4 covers PAN transmitted over open, public networks. Requirement 6 covers the secure development of the tokenization and encryption systems themselves. Requirement 7 and 8 cover access to the token vault and to decryption keys. Requirement 10 covers logging of detokenization and key use. Requirement 11 validates that the controls actually work.

Most importantly, tokenization directly affects PCI DSS scoping -- and scope drives everything else in the PCI DSS program. A solid tokenization rollout is often the single highest-ROI PCI DSS investment a program can make, because it compounds across every subsequent control, every subsequent assessment, and every subsequent ASV scan.

Common mistakes

• Treating encryption as scope reduction. Encrypted PAN is still cardholder data and the system remains in PCI DSS scope.
• Shipping tokens alongside PAN in logs or analytics because the application is not consistently tokenizing on the way in.
• Deploying format-preserving tokens without distinguishing them from real PANs, leading to confusion during investigation.
• Leaving legacy databases with residual PAN after a tokenization rollout, creating PCI DSS findings years later.
• Weak key management that puts encryption controls out of compliance with PCI DSS Requirement 3.6 and 3.7.
• Running the token vault on shared infrastructure that lacks the segmentation and hardening PCI DSS expects.
• Relying on a tokenization service provider without confirming their PCI DSS validation and Responsibility Matrix.
• Skipping detokenization rate limiting, leaving the vault vulnerable to bulk extraction through a compromised service account.
• Tokenizing only the happy path and leaving batch jobs, exports, or backup pipelines handling real PAN.

How episki helps

episki maps your tokenization and encryption controls to every affected PCI DSS requirement, collects evidence from vaults and HSMs, and flags drift before your QSA does. We make it easy to prove to an assessor that tokens stay tokens, keys are managed, and the vault is airtight. Learn more on the PCI DSS hub.