 |
 |
 |
A couple of months ago I wrote an article where I discussed some of the reasons in favor of implementing tokenization, or the substitution of surrogate numbers at the POS for card data, as a way to greatly reduce card data risk and PCI assessment scope. Well, after conducting over 100 hours of interviews with merchants, banks, PCI assessors and card processors, it turns out that there are a lot of arguments against tokenization. I think I heard them all. If you want to read some of them for yourself, go to the PCI Knowledge Base and register, then search the Knowledge Base for "tokenization." Before you do that, you might want to read this summary of the "anti-tokenization" positions taken by a number of the members of the PCI Knowledge Base. Companies have already spent money on encryption—The most popular reason for not implementing tokenization is that companies have already implemented data encryption and key management systems costing hundreds of thousands of dollars, and they did not feel they either needed tokenization, or they were unwilling to be perceived by upper management as "changing course" by recommending they remove the data they just spent all this money to protect. Applications managers won't give up the data—A near rival for the top reason for resisting tokenization is that business managers and application owners use card numbers in many different places in their business processes and applications, and that the security managers, who typically prefer tokenization (as it reduces their own risks), do not believe they can successfully argue that the applications could be rewritten to work with the token numbers instead. They feel that the costs for changing the application code cannot be justified by the level of risk reduction. Merchants are waiting for their bank or database vendor—Some of the merchants said they would be willing to consider tokenization, but not from the current crop of smaller, independent vendors. Some said they felt such solutions would soon be offered by their own bank or card processor, others (typically in IT) said they wanted to wait until tokenization is an option built into their DB management software. Tokenization is too new or unproven—Some of the merchants who resist using token numbers as substitutes for card data are simply objecting to the fact that there are not enough reference accounts who are willing to talk about their experiences. Very few companies want to be first to take what they perceive as an additional risk relative to their credit card data, so they want to be assured their peers are involved. The fact that this becomes a self-fulfilling prophecy is clearly not lost on these merchants. Tokenization vendor is a "single point of failure'—Some of the merchants and PCI assessors we interviewed expressed concern that by having the card data from hundreds, even thousands of companies concentrated in "one place" (a tokenization vendor's systems) that this could make the vendor such an attractive target (like the Dept of Defense or National Security Agency), that so many talented crackers would be pointed at the repository. With that, they reason, "someone" would break down the defenses. This treasure trove of data would be equally attractive to privileged insiders, thus making a detailed review of any tokenization vendor's solution absolutely mandatory. Tokenization pricing models are immature and too variable—We spoke with a few merchant who had done head-to-head comparisons among the major tokenization vendors and they encountered highly "flexible" pricing models. A larger concern was that the merchants had no idea how to tell if they were getting a good deal, as the pricing models were difficult to compare across vendors. Bottom Line—Despite how attractive tokenization sounds as a concept, there is substantial resistance to the products and services as they exist in the marketplace today, sufficient to limit the growth of this market in the next 1-2 years. Again, if you want to discuss this column or any other security or compliance issues, please send me an E-mail at This e-mail address is being protected from spambots. You need JavaScript enabled to view it or visit www.KnowPCI.com and click "Add Your Knowledge" to join the PCI Knowledge Base. |
