Skip to main content
Commerce Security Authority
Category: Tokenization

Tokenization

Also known as: payment tokenization, card tokenization
Simply put

Tokenization is the process of replacing sensitive data, such as a payment card number, with a non-sensitive stand-in value called a token. The token maps back to the original data but has no meaningful value on its own if it is exposed. In payments, this can mean the card number is replaced with a substitute number stored on a device or at a merchant.

Formal definition

Tokenization converts sensitive data into a non-sensitive digital replacement (a token) that can be mapped back to the original value, typically through a secured lookup or token vault rather than through a mathematical relationship with the original data. This distinguishes it from encryption, which reversibly transforms data using a cryptographic key, and from truncation, masking, and hashing, which either remove, obscure, or produce a fixed-length representation of data without necessarily supporting recovery of the original value. In a payment context, a token may replace the primary account number (PAN) at the point of storage or transaction; however, tokenization's effect on PCI DSS scope depends on the specific implementation, the strength of the token-to-PAN mapping controls, and validation, not on use of the term alone. Beyond payments, the term is also applied to asset representation on distributed ledgers, which is a separate use of the word from card and cardholder-data tokenization.

Why it matters

Tokenization matters because a token, unlike the payment card data it replaces, has no meaningful value on its own if it is exposed. When a token replaces a primary account number (PAN) at the point of storage or transaction, a system or database that holds only tokens presents a less attractive target than one holding live card numbers. This can reduce the exposure of cardholder data across merchant, processor, and device environments, provided the mapping between token and original value is protected by strong controls.

For merchants and processors, tokenization is frequently discussed in the context of PCI DSS scope. It is important to be precise here: tokenization's effect on scope depends on the specific implementation, the strength of the token-to-PAN mapping controls, and validation, not on use of the word 'tokenization' alone. A poorly protected token vault, or a reversible mapping accessible within the merchant environment, may not deliver the scope reduction that teams expect. Scope determinations should be confirmed against the current published PCI DSS standard and, where relevant, the assessor's findings rather than assumed from the label.

The term is also used outside of payments, for example to describe the representation of real tradable assets as blockchain tokens. That usage is a separate application of the word from card and cardholder-data tokenization, and conflating the two can lead to misunderstanding when evaluating data-protection controls in a payments program.

Who it's relevant to

Compliance officers and QSAs
Those responsible for PCI DSS validation need to understand that tokenization may reduce the exposure of cardholder data, but its effect on scope depends on implementation, the strength of the token-to-PAN mapping controls, and validation. Scope reduction claims should be confirmed against the current published standard rather than assumed from the term itself.
Security engineers and architects
Engineers designing storage and transaction flows should distinguish tokenization from encryption, truncation, masking, and hashing, and recognize that the security of a token rests on protecting the secured lookup or token vault that maps it back to the original value, not on the substitution alone.
Merchants and payment processors
Merchants and processors that store or handle card numbers may use tokenization to replace the PAN at the point of storage or transaction, including stand-in values saved on a device or at the merchant's site. They should evaluate whether their specific implementation and controls deliver the data-exposure and scope outcomes they expect.
Teams evaluating cross-domain terminology
Analysts and decision-makers reviewing vendor materials should be aware that 'tokenization' is also used to describe representing real tradable assets as blockchain tokens, which is a separate use of the word from card and cardholder-data tokenization.

Inside Tokenization

Token
A surrogate value that substitutes for a primary account number (PAN) or other cardholder data. A token has no exploitable meaning or value on its own and is intended to be usable in place of the original data within defined systems and processes.
Detokenization
The reverse process of mapping a token back to the original cardholder data. This function is typically restricted to a tightly controlled environment and limited set of authorized systems or personnel, since it reintroduces access to sensitive data.
Token vault or mapping mechanism
The data store or algorithmic mechanism that associates tokens with the original values. Vault-based approaches maintain a lookup mapping, while vaultless approaches derive tokens through a repeatable process. The vault or mapping mechanism concentrates risk and remains in scope for protection.
Format-preserving vs. non-format-preserving tokens
Tokens may preserve the length and format of the original PAN (for example, retaining a recognizable structure) or use an unrelated format. Format preservation can ease integration with existing systems but does not by itself change how the token affects scope.
Distinction from encryption
Tokenization replaces data with an unrelated surrogate value, whereas encryption transforms data using a key that can reverse the process. Unlike encryption, a well-implemented token is not mathematically derived from the PAN in a way that can be reversed without access to the vault or mapping mechanism.
Distinction from truncation, masking, and hashing
Truncation permanently removes a portion of the PAN, masking hides digits for display, and hashing produces a one-way value. Tokenization differs in that it is intended to allow controlled recovery of the original data via detokenization, unlike truncation and hashing.
Scope impact
Replacing stored cardholder data with tokens may reduce the systems considered in scope for PCI DSS, but the effect depends on implementation, how detokenization is controlled, and validation. Systems that can detokenize or that access the vault typically remain in scope.

Common questions

Answers to the questions practitioners most commonly ask about Tokenization.

Is tokenization the same as encryption?
No. Tokenization and encryption transform data differently. Encryption uses a cryptographic algorithm and key to convert cardholder data into ciphertext that can be reversed by anyone holding the key, meaning the original PAN remains mathematically derivable from the ciphertext. Tokenization substitutes the PAN with a surrogate value (a token) that typically has no mathematical relationship to the original data; recovery generally depends on a lookup in a secured token vault or a comparable mapping mechanism rather than on a decryption key. Because the mechanisms differ, they carry different risk profiles and should not be treated as interchangeable. Their respective effects on PCI DSS scope depend on the specific implementation and validation, not on the label used.
Does tokenizing card data automatically remove a system from PCI DSS scope?
Not automatically. Replacing a PAN with a token can reduce the scope of systems that no longer store, process, or transmit cardholder data, but scope reduction is not guaranteed by applying the label 'tokenization.' Whether and how much scope is reduced depends on the implementation details, how tokens are generated and mapped, how the token vault and any de-tokenization functions are protected, and how the environment is assessed and validated. Systems that can retrieve the original PAN, and the token vault itself, generally remain in scope. Confirm scope determinations against the current published PCI DSS and any applicable guidance rather than assuming tokenization alone removes scope.
How should the token vault or mapping mechanism be protected?
The component that maps tokens back to the original data, whether described as a token vault or another mapping mechanism, is typically among the most sensitive parts of a tokenization deployment because it can enable recovery of the original PAN. It is generally treated as in scope and protected with strong access controls, monitoring, and the security requirements that apply to systems handling cardholder data. Design decisions about who and what can perform de-tokenization, and under what conditions, materially affect the residual risk. Validate the specific protections against the current published PCI DSS and any applicable supporting guidance.
Can tokenization be used for sensitive authentication data such as CVV2 or full track data?
Sensitive authentication data, including full track data, card verification values such as CAV2, CVC2, CVV2, or CID, and PINs or PIN blocks, must not be stored after authorization even when protected. Tokenization is a data-substitution technique applied to data that is retained for a business purpose; it does not create an exception permitting storage of sensitive authentication data post-authorization. Cardholder data elements that may be stored under defined controls, such as the PAN, are the typical subject of tokenization. Confirm what may and may not be retained against the current published standard.
What is the difference between tokens that can be reversed and tokens that cannot?
Tokens differ in whether the original value can be recovered. Some implementations support de-tokenization, allowing an authorized process to retrieve the original PAN through a vault lookup or comparable mechanism, while others are designed so the original value cannot be retrieved from the token. The reversibility, the strength of the mapping mechanism, and the controls governing de-tokenization all influence the risk and the scope implications of a deployment. Because outcomes depend on implementation and validation rather than on terminology, the specific design should be assessed against the current published PCI DSS and applicable guidance.
How does tokenization relate to truncation, masking, and hashing in an implementation?
Tokenization, truncation, masking, and hashing transform cardholder data in different ways and serve different purposes. Truncation permanently removes a portion of the PAN so it cannot be reconstructed from what remains; masking controls how data is displayed without necessarily altering stored data; hashing produces a fixed representation intended to be non-reversible, though its risk depends on implementation. Tokenization substitutes the value with a surrogate that may or may not be reversible via a mapping mechanism. An implementation may combine several of these techniques for different data flows, and each technique's effect on PCI DSS scope depends on how it is implemented and validated, not on the label alone.

Common misconceptions

Tokenization is just another form of encryption.
Tokenization and encryption are distinct. Encryption transforms data using a reversible key-based algorithm, while tokenization substitutes data with an unrelated surrogate value whose relationship to the original is intended to be recoverable only through a vault or mapping mechanism. Their effect on PCI DSS scope depends on implementation and validation, not on the label alone.
Implementing tokenization automatically removes an environment from PCI DSS scope.
Tokenization may reduce scope, but it does not eliminate it by default. Any system that can perform detokenization, access the token vault or mapping mechanism, or handle cardholder data before tokenization typically remains in scope. Scope reduction must be verified against how the solution is implemented and validated.
Tokenization lets you safely store sensitive authentication data if it is tokenized.
Sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks) must not be stored after authorization, even when transformed. Tokenization applies to reducing risk around cardholder data and does not create an exception permitting retention of sensitive authentication data.

Best practices

Restrict and tightly control detokenization capabilities, limiting them to a minimal set of authorized systems and personnel, since detokenization reintroduces access to sensitive data.
Treat the token vault or mapping mechanism as a high-risk, in-scope system and protect it with strong access controls, monitoring, and segmentation.
Confirm scope reduction claims through validation based on how the solution is actually implemented, rather than assuming that using tokens removes systems from PCI DSS scope.
Do not use tokenization as justification for retaining sensitive authentication data after authorization; ensure such data is not stored regardless of any transformation.
Document how tokenization interacts with related techniques such as encryption, truncation, masking, and hashing, and select the approach that matches the specific data-protection and recovery needs.
Verify controls and any scope implications against the current published PCI DSS standard rather than relying on fixed requirement numbers, since numbering and wording differ between versions.