Credit Card Tokenization is a very popular antidote to costly and time-consuming PCI regulations, but are all implementations equally secure? Early studies on tokenization focused on the cryptanalysis of the token generation process, especially when early implementations sought to create 16 digit numeric tokens to satisfy constraints in legacy commerce systems. Fast forward to 2016, most of those problems do not exist today; however, anecdotes from consulting with Fortune 500s suggest other insecure properties not involving crypto can vary and emerge in tokenization systems. This talk will dig into several sanitized examples from consulting engagements which reduce “PCI Compliant” Credit Card Tokenization from “silver bullet” to “speed bump” status when big-picture security controls are missing. Specifically: abusing separation of duties by rogue partial insiders via public APIs commonly found in e-commerce applications; discovery of accidental side channels of critical information flow, such as timing analysis or response differentiation, which can be abused to reveal full PANs (primary account numbers); whether DevOps cultures could promote rogue admins abusing tokenization presentation logic implemented in JavaScript; and for good measure: some common programming defects which at best render tokenization pointless, and at worst could allow for a breach. With each example, we’ll look at potential solutions.