P2PE: No Cakewalk for Merchants, But There May Be No Alternative For Reducing Scope

Written by Walter Conway
May 9th, 2012

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

When the PCI Council released version 1.1 of its Point-to-Point Encryption (P2PE) Testing Procedures late last month (April 27), it forced an interesting question: Will P2PE be the only way to remove encrypted data from a merchant’s PCI scope?

Current PCI Council guidance (FAQ 10359) holds that encrypted data can be out of a merchant’s PCI scope “if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” The important word here is “entity.” That is, the ability to decrypt the data must rest with some unrelated third party. With the emergence of P2PE, could this scoping guidance be revised to where the only appropriate “entity” is an approved P2PE provider?

Although I have no inside information on this point, it seems to me and other QSAs that this FAQ has been applied far beyond its original context. Now that we have a P2PE program emerging and approved methods just around the corner, is there really any justification for the PCI Council to keep that FAQ in its present form?

Either way, it’s another reason merchants may want to implement P2PE. That may be the only way to keep their encrypted data out of scope in the future. If that is the case, a lot of merchants (and PCI service providers) could find their PCI world changed by the end of this year.

Therefore, whether merchants are evaluating P2PE or not, it may make sense to start paying attention to the detailed guidance coming from the PCI Council.

P2PE is an exciting development that promises to save merchants a bundle of money in PCI compliance costs by reducing their PCI scope dramatically. What has not been clear until now is just how much work merchants may have to do to get the full benefits of it. Looking at the updated Testing Procedures, it looks like implementing P2PE properly will not be the walk in the Xerox PARC that many merchants seem to think it will be.

The first thing merchants need to know is that they must implement an “approved” approach; that is, a P2PE package accepted by the PCI Council. Approved suites will be listed—likely starting in the third or fourth quarter of this year—on the Council’s Web site.

To get the full benefit of scope reduction, merchants must do three things:

  • Use a PCI PTS approved point of interaction (POI) device that is segmented from the rest of the merchant’s network.
  • Use that POI device for entering all card transactions.
  • Have the approved vendor manage all transaction operations.

Then, so long as the merchant follows the instructions in the P2PE Instruction Manual (PIM), that will be part of every approved approach. Everything should be fine, and the merchant can expect to reap the benefits of a greatly reduced PCI scope.

Merchants evaluating P2PE packages and even implementing encrypting POS devices in anticipation of P2PE may be under the impression that is all they need to do. Unfortunately, the PIM details a lot of actions for merchants, mostly revolving around securing and maintaining the POI devices.

Most of the merchant responsibilities are contained in Domain 3 (there are six Domains in the P2PE Requirements and Testing Procedures), which covers more than 30 pages of the updated document. What follows is a partial list.

Domain 3A addresses physically securing the POI devices throughout their lifecycle. Some of the more important requirements for merchants are:

  • Maintain inventory control and monitoring procedures to identify and locate all devices, including those deployed, awaiting deployment or in transit.
  • As part of the inventory, track 11 device characteristics, including model and serial numbers, location and firmware version.
  • Physically secure all devices in storage.
  • Secure the devices in transit; for example, between store locations.
  • Have procedures for detecting unauthorized or substitute devices.
  • Be able to detect any unauthorized or replacement device prior to installation.

Naturally, merchants will need to log all this activity and produce and audit trail.

Domain 3B deals with secure device management and addresses. Merchant requirements include things such as procedures for removing POI devices for maintenance or repair and provisions for merchants to physically inspect the devices on a regular basis. This section also details the merchant opt-out procedure (required in all approved offerings), should a merchant change its mind.

Domain 3C specifies the contents of the PIM. (Readers interested in the highlights can go directly to page 98 and see all the details.)

The PCI Council is making rapid progress on its P2PE program. Any merchant seriously considering this technology should download the v1.1 documentation and spend some quality time (preferably not just before bedtime) reading it and digesting its implications. The first steps to realizing P2PE are under way. The POI devices can be tested by PCI PTS labs, and the specialized P2PE QSA and PA-QSA training is this month. Soon, these P2PE PA-QSAs will be preparing Reports on Validation and submitting them to the PCI Council for approval and listing.

Smart vendors are already working on all fronts to be among the earliest to get approval. They believe they will have a competitive advantage with the PCI Council’s stamp of approval, and they might be right. After all, merchants will have to implement approved approaches or they won’t be able to qualify for the P2PE scope reduction very easily.

What do you think? Have you looked at P2PE packages or even committed to one? Did you, like me, spend a large part of your weekend digesting the updated P2PE document? As a merchant, are you prepared for the POI device management and tracking requirements? Or are you relying on the PCI Council’s FAQ 10359 to remove your encrypted data from scope? I’d like to hear your thoughts. Either leave a comment or E-mail me.


2 Comments | Read P2PE: No Cakewalk for Merchants, But There May Be No Alternative For Reducing Scope

  1. Jaime Says:

    Walt, what are your thoughts on the applicability of P2PE to merchants who process using a mobile phone application with a swiper? I’ve asked a few QSA’s this question and feeling seems to vary on whether a compliant POI device connected through the phone to a compliant gateway, etc. would allow the merchant to qualify. The crux of the conflict seems to be whether the phone remains in scope as part of the processing environment, or if it can be considered removed because the data is encrypted while being passed to the gateway through an app or the browser.

  2. Andrew Jamieson Says:

    Hi Jamie,
    If the swipe device is PCI PTS certified, AND also compliant tot the SRED requirements of that standard, then it should be possible for the phone to be out of scope. This is basically the crux of the new PCI guidance on mobile payment acceptance, and the whole point of the SRED module (ie to help secure data through encryption to assist with scope reduction).


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.