Tokenisation and PCI Scope: What Tokens Do and Do Not Do

What a token is, precisely

The PCI SSC defines tokenisation as “a process by which the primary account number (PAN) is replaced with a surrogate value called a ‘token,’” with de-tokenisation the reverse process of redeeming a token for its PAN. The security of an individual token “relies predominantly on the infeasibility of determining the original PAN knowing only the surrogate value.” Visa's Core Rules use a narrower definition for network tokens: a Token is “a type of Payment Credential issued in accordance with the EMV Payment Tokenisation Specification – Technical Framework,” a Token Requestor is an entity registered with a Token Service Provider to initiate requests for payment tokens, and a Token Service Provider is an entity that provides a token to a token requestor. EMVCo describes an EMV payment token as a unique alternative value that is “constrained in how it can be used” — for example to a specific merchant, device or payment scenario.

Network tokens behave differently in authorisation

Under Visa's rules, if a transaction is initiated with a token it must be submitted for online authorisation, and Visa reserves the right to decline, on an issuer's behalf, a transaction initiated with a token where the token does not comply with the domain control requirements in the EMV Payment Tokenisation Specification. That domain restriction is the point: a stolen network token is bound to a context it cannot be used outside of. A gateway or vault token, by contrast, is a reference inside one provider's system with no network-level standing, and it is the type most merchants mean when they say “card on file.” Both are useful; they are not interchangeable, and a provider claiming tokenisation may be offering either.

What tokenisation does to PCI DSS scope

The PCI SSC's scoping rules are specific. All elements of the tokenisation system and process, including de-tokenisation and PAN storage, are part of the cardholder data environment and are in scope. Any system component or process with access to the tokenisation system or the tokenisation/de-tokenisation process is in scope, as is anything located within or connected to the CDE. Components that generate a token in exchange for a PAN, or redeem a PAN in exchange for a token, are in scope. Systems that are adequately segmented from the tokenisation system and the CDE, that store, process or transmit only tokens, and that handle no cardholder data or sensitive authentication data, “may be considered outside of the CDE and possibly out of scope.” Note the hedging in the Council's own wording.

The conditions attached to out-of-scope

For tokens and the systems holding them to be out of scope, the Council lists conditions that all have to hold: recovery of the PAN from the token must not be computationally feasible from knowledge of only the token, multiple tokens or other token-to-PAN combinations; the PAN cannot be retrieved even if the token and its systems are compromised; those systems are segmented from anything able to submit a de-tokenisation request, reach the vault or keys, or access token input data; they are not connected to the tokenisation system or the CDE and hold no credentials that authenticate into it; they handle no cardholder data through any other channel; and systems that previously held cardholder data have been examined to confirm all traces were securely deleted. That last one is the condition most often skipped, because it is archaeology rather than architecture.

Getting the most scope reduction

The Council's own recommendations are worth following literally: replace PAN storage with tokens wherever possible; limit the existence of PAN to the point of capture and the card data vault; minimise the number of components that touch PAN before tokenisation; ensure PAN is not present in the same environment as the tokens outside the vault; remove all cardholder data from source systems once tokenised; prefer a solution where PAN cannot be retrieved once a token has been issued, so refunds, chargebacks and loyalty tracking work without the merchant accessing the PAN; enforce separation of duties between token users and administrators; and combine tokenisation with point-to-point encryption so the only PANs in the environment sit inside a secure PTS-approved point-of-interaction device. The Council also notes that where a token can be used to generate a transaction, additional measures may be needed against fraudulent use of the token itself.

Single-use, multi-use, and getting your tokens back

The Council distinguishes single-use tokens, which typically represent one transaction, from multi-use tokens, which represent a specific PAN and always map that PAN to the same token value within the system — which is what makes recurring billing and customer history possible. That mapping lives with the provider that issued it, so portability is a commercial question to settle before integration rather than at cancellation. Our guide to moving stored cards between processors covers the migration itself, and merchants should review their use of tokens as part of annual PCI DSS scope validation to confirm cardholder data is not retrievable outside the defined CDE.