I have a confession to make: I’m a tokenization junky. I live and breathe tokenization, and have been for a few years now. Since I’m serving as lead chair on the PCI Security Standards Council’s Tokenization Working Group, it’s my job to know everything about tokenization that’s going on in the industry and report back to and advise the council. I also happen to work for a company that’s heavily invested in tokenization, and I am keenly interested in helping data security pros understand the benefits of the technology as well as its boundaries.
The good news is that there is an amazing amount of interest in tokenization, and to feed that interest, there’s a lot being written about it in blogs and in the trades. The industry is moving fast to set standards for tokenization and develop new ways of applying it to data protection, and companies are hungry for information. With this rapid advancement comes misinformation, even by those who have implemented a tokenization solution within their enterprises. Five tokenization myths in particular are making their rounds from one article or presentation to another, and I’m taking this opportunity to set the record straight and state the truth.
Myth 1: Tokenization Doesn’t Require Encryption or Key Management
Truth: Much to my dismay, I’m seeing an average of one article per week that applauds tokenization on the simple fact that it doesn’t require encryption or encryption keys. That’s simply not true.
In reality, with tokenization, sensitive data is encrypted and stored in a central data vault in most instances, although it is not an absolute requirement. This then enables the tokens to be redeemed back to the original value when desired and allowed.
Therefore, in most cases there is still a requirement to also manage encryption keys. The difference is that the keys are limited to the centralized tokenization system and not distributed throughout the enterprise.
Myth 2: Tokenization Is an Immature Technology
Truth: Tokenization was introduced to the data security market five years ago. As companies began using it, the industry began to take notice, resulting in more vendors introducing tokenization solutions within the last couple of years. With these product releases, the media, industry analysts and the Payment Card Industry’s Data Security Standards Council (PCI SSC) began to investigate it further.
While initially drawing the attention of companies wanting to use it to secure credit-card numbers and reduce scope for PCI Data Security Standard (DSS) audits, a relatively new adaptation called “Format Preserving Tokenization” also allows it to maintain some of the characteristics of the original data, such as the length and data type as well as some of the original data values.
For instance, the token, while randomly generated, can share the last four digits of a credit card or Social Security number. Tokenization is also being used to protect any type of personally identifiable information (PII) and protected health information (PHI) to comply with privacy laws.
To further underscore the maturity of the tokenization data security model, several standards are in the works, including:
- The PCI SSC Scoping Special Interest Group (SIG) is working on definitions and the application of tokens as it relates to PCI DSS.
- The Accredited Standards Committee X9 has begun working on a standard to define tokenization requirements related to credit-card data in the financial services industry.
- The Hospitality Technology Next Generation Payments Workgroup already issued a tokenization standard for credit-card data for use within the hospitality industry.
Myth 3: Tokenization Is a Silver Bullet for All Use Cases
Truth: Without a doubt tokenization is great for protecting cardholder information; PII such as Social Security and driver’s license numbers, passwords and birthdates; and PHI for electronic health records (EHR).
However, tokenization isn’t always the silver bullet for all data security requirements and use cases. For instance, scanned documents like loan applications, job applications or insurance claims forms are not typically tokenized, but rather are simply encrypted. The good news here, however, is that the image files and tokenized data can share the same centralized key management solution.
Myth 4: There Are No Companies Using Tokenization in Production
Truth: In fact, many North American and European retail, hospitality, financial services and insurance companies — both large and mid-sized — have implemented tokenization to protect cardholder information and reduce scope for PCI DSS.
What’s more, many are extending it to protect other types of sensitive information such as customer loyalty and other personal data, corporate intellectual property and confidential employee information.
Myth 5: Concrete Examples of Using Tokenization to Reduce Scope Do Not Exist
Truth: There are a number of instances where companies have implemented tokenization to reduce scope for PCI DSS compliance and audits. For example, a US$500 million U.S. direct marketer implemented tokenization last year to protect cardholder information gathered by phone, mail order and online orders and comply with PCI DSS. By substituting tokens for credit-card numbers in applications, the e-tailer was able to take 80 systems — nearly 90 percent of its infrastructure — out of scope for PCI DSS audits, leaving only 10 systems to be audited.
As part of the tokenization deployment, more than 1 million credit-card numbers stored in the company’s SQL database were converted, securing the data in a segregated vault environment and replacing the sensitive data with tokens on all out-of-scope systems. The Format Preserving Tokenization solution the e-tailer chose plugged directly into the company’s architecture and applications, with minimal change to the capturing applications, so business operations have not been impeded in any way. Tokenization allowed the company to avert nearly 90 percent of its PCI DSS compliance costs. The company now estimates that this reduction in scope has the potential to save it approximately $250,000 annually in staff and administrative overhead. The company is now in the process of reinvesting their cost savings to tokenize customer loyalty data and other PII.
In another example, one of the UK’s oldest, largest and most esteemed retailers recently implemented tokenization across its heterogeneous IT infrastructure throughout its retail, order management and data warehouse systems, without costly programming modifications to applications and databases or requiring additional computing resources to hold encrypted cardholder information to meet PCI DSS encryption requirements. Because the Format Preserving Tokenization solution the company chose has ability to run on all of its systems non-intrusively, they were able to meet all of the PCI DSS encryption requirements and avoid additional programming and hardware costs that would have been required to run the other solutions they considered. The company also avoided having to add staff to ensure PCI DSS compliance.
The value of tokenization is indisputable for any company that wants to secure credit-card numbers and reduce the costs of PCI DSS compliance and annual audits, or to protect any other type of customer, patient, employee or company-confidential information. Its appeal is quickly extending beyond the retail industry to financial services, insurance and hospitality industries and healthcare.
In the near future, I expect to see companies in many other segments begin to show interest, including government entities, as privacy laws come into play in the United States as they have in Europe. As tokenization goes mainstream it’s important to understand exactly what it is and what it isn’t. I’m sure we’ll be seeing more myths emerge, but for now I hope this helps correct the ones floating around the data security industry now.
Gary Palgon is the lead chair of the Scoping Special Interest Group’s Tokenization Working Group for the PCI Security Standards Council. He also vice president of product management and nuBridges. Gary can be reached at firstname.lastname@example.org.