The PCI Council on Thursday (Sept. 15) is releasing a guidance document on point-to-point encryption (P2PE). This technology—properly implemented—has the potential to reduce PCI scope greatly, and several retailers have already implemented it. But one issue may have early adopters digging up their vendor agreements: Are they sure their implementations—particularly the encrypting POS devices—will pass the Council's new Secure Card Reader testing program? Will their vendors replace the POS devices with compliant ones, assuming they can, and what will that cost?
The idea behind P2PE is that an encrypting POS terminal encrypts the cardholder data (the first "point") immediately as the customer's card is swiped. A third-party service provider (the second "point," and often the merchant's card processor) manages both encryption and key management. The third party is the only one that can access the actual cardholder data. The result is that when P2PE is properly implemented, almost all the merchant's systems are out of PCI scope because the merchant has no way to decrypt the data or ever to get access to the clear-text cardholder data.
To be effective, P2PE relies on a secure hardware device, the encryption software and a PCI-compliant service provider. Today it is difficult for any QSA to assess the hardware and software systems to determine if they are compliant. For example, is the hardware tamper resistant, was the software/firmware securely developed and can the merchant ever access any cardholder data or data from the card's magnetic stripe? This is the challenge that the PCI Council's P2PE guidance is designed to address.
Although merchants and QSAs want black-and-white answers, we all need to manage our expectations. As with the Council's previous tokenization document, the guidance will provide exactly that: guidance. It will have definitions and describe some use cases, but I do not expect it to give blanket endorsement to any technology. And we should not expect to get simple answers to complicated scoping questions.
As I write this, I have no inside knowledge of the details. But at its heart, I expect the most important element will be defining a new process for testing P2PE devices by PTS (PIN Transaction Security) laboratories similar to how PIN-encrypting devices (PEDs) are tested today.
The Council informed QSAs it will soon release a new version of its Point of Interaction Security Requirements that are part of the PCI PTS. Of special note for P2PE fans is that the PCI PTS will now include a new approval class (Secure Card Reader) for testing and approving P2PE devices, even if they do not accept PINs.Once a PTS lab approves a P2PE device, the merchant should have some level of assurance that its device can (I did not say "will") protect cardholder data. The QSA's role is to determine whether the device is properly configured so that the merchant cannot access any PAN or magstripe data.
P2PE vendors and manufacturers will submit their devices to a PTS lab just like they do their PIN pads today. The PCI Council will (presumably) list all approved devices, and merchants can check that list before they sign on the dotted line. The issue for early adopters is, what do they do if their devices are not on the approved list?
From this QSA's perspective, about the only thing merchants can do today is to check their contract to see if there is any provision that covers this eventuality. For example, if the vendor has other devices that are approved, can the merchant trade in its unapproved devices and get some discount? Similarly, if a merchant's device appears in a Visa security bulletin, is there some price break (say, based on age of device) on replacements? Unfortunately, if the vendor has no approved device options, the merchant could be out of luck.
Merchants may want to recognize this situation and include some provision in their vendor agreements. My guess is that most experienced vendors' P2PE devices will pass the Council's testing regime. The terminal manufacturers are smart people, many make PTS-approved devices already, and everybody has to have anticipated something like this. But just in case, merchants may want to consider a provision in their contract or service-level agreement should their vendor's promise to reduce PCI scope not be realized.
It also is interesting to note the Council's expected testing and approval regime will apply to almost any POS device that reads and encrypts cardholder data. That means this Secure Card Reader designation will cover peripherals attached to a mobile device that encrypt the data and then pass only that encrypted data to the mobile smart device for transmission and processing. My guess is that including these peripheral devices in the Secure Card Reader class may be what the Council referred to in its Mobile Payments announcement this past June.
Like merchants, vendors and QSAs everywhere, I am anxiously awaiting details from the PCI Council on P2PE implementation guidelines. It has been two years since the Council's first study identifying P2PE as a promising technology for reducing PCI scope and speeding compliance.
What do you think? Have you implemented P2PE? Are you looking at it? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].