Evan Schuman's StorefrontBacktalk

The guideline itself says that token programs “do not eliminate the need to maintain and validate PCI DSS compliance, but they may simplify a merchant’s validation efforts by reducing the number of system components for which PCI DSS requirements apply. Verifying the effectiveness of a tokenization implementation is necessary and includes confirming that PAN is not retrievable from any system component removed from the scope of PCI DSS.”

Typically, tokens merely replace the storage of sensitive card information. But some approaches enable the token to, theoretically, be able to make transactions directly. If that’s the case, it needs additional safeguards. Indeed, such transaction-capable tokens may thrust that chain right back into PCI scope.

“An important consideration when evaluating tokenization is whether the token itself can be used in lieu of cardholder data to perform a transaction. Tokens that can be used as payment instruments (sometimes called high-value tokens) could potentially be monetized or used to generate fraudulent transactions, and may therefore have the same value to an attacker as the data they are intended to replace,” the guidance says.

“Tokenization [packages] that support these types of tokens should have additional controls in place to detect and prevent attempted fraudulent activities. Additionally, tokens that can be used to initiate a transaction might be in scope for PCI DSS, even if they cannot directly be used to retrieve PAN or other cardholder data. Merchants should therefore consult with their acquirer and/or the payment brands directly to determine specific requirements for tokens that can be used as payment instruments.”

The guidance also gets very specific about how tokens would have to act and be used to keep a retailer out of PCI danger. “Recovery of the PAN value associated with a token must not be computationally feasible through knowledge of only the token, multiple tokens or other token-to-PAN combinations. The PAN cannot be retrieved even if the token and the systems it resides on are compromised.”

Another key out-of-scope issue deals with the reversible-encryption token approach, which the Council document describes as one “where the token is mathematically derived from the original PAN through the use of an encryption algorithm and cryptographic key.” In those instances, the document says, “the resultant token is an encrypted PAN and may be subject to PCI DSS considerations in addition to those included in this document. The PCI SSC is further evaluating how these considerations may impact PCI DSS scope for reversible, encryption-based tokens.”

The report also encourages retailers to have a precise method to distinguish between tokens and actual PANs.

“Without the ability to distinguish between a PAN and a token, the merchant or service provider may not realize that the tokenization system isn’t functioning as intended. Additionally, PANs could be mistakenly identified as tokens, which can lead to mis-scoping of the CDE and the possibility that PANs are left unprotected and open to compromise,” it says. “Note that some tokens are designed to mimic the type and format of the original PANs, and it may not be possible for a human reviewer to distinguish between the two types of data. In this instance, a specific tool may need to be utilized or a function performed to verify that an alleged token is actually a token and not a PAN. The mechanism or method for distinguishing between tokens and PANs for a particular tokenization [approach] should be shared with the merchants using that [token application] to allow merchants the ability to verify that their CDE has been accurately defined and scoped.”