This past week, Bob Russo, General Manager of the PCI SSC, held Webcasts to discuss the changes coming to version 3 of the PCI DSS and PA-DSS. For the most part, these Webcasts were nothing special. Just a scripted regurgitation of what was published in the Version 3.0 Change Highlights document release earlier this month.
However, at around 35 minutes into the Webcast I attended, things got very interesting and an actual useful piece of information was shared. For it was at that point that Mr. Russo launched into a discussion about mobile payments and the use of consumer devices such as smartphones and tablets for the processing of card transactions. Mr. Russo stated:
“The fact is that many consumer mobile devices simply cannot provide the level of security needed to adequately protect payment card data. In other words, they cannot create a trusted environment equivalent to the PCI DSS compliant cardholder data environment.”
Whoa! Now there is a piece of information I was not expecting. I looked at the slide and these are the bullets on the slide.
- PCI Standards focus on merchant acceptance
- Mobile payment acceptance still evolving
- Understand risk and use PCI SSC resources
- PCI SSC is working with industry
Mr. Russo went on to say:
“We encourage merchants to understand the risk of using mobile, work with their acquirer and make their own decisions about mobile and whether they are willing to accept that risk.”
“We’re working with others in the industry including: standards bodies, vendors, banks and processors. But we are unwilling to lower the bar for security by writing a standard that current mobile devices could meet. If we wrote a secure standard for mobile now, no consumer devices would be able to meet it.”
The bottom line in all of this is that all of you merchants using iPads, iPhones, Android phones and tablets and similar devices are using them at your own risk. They are not PCI compliant. Not only that, you should have cleared that decision with your acquiring bank so that they also accepted the risk that you were using mobile devices to accept payments.
Mr. Russo referred Webcast attendees to reference the PCI SSC Information Supplement ‘Accepting Mobile Payments with a Smartphone or Tablet’ for additional information regarding the use of such devices.
Mr. Russo also reminded everyone that mobile payments from the consumer side are not within the purview of the PCI SSC and the PCI standards. So wallet applications, near field communication (NFC) and the like will not be regulated by the PCI standards.
These statements though leave a lot of questions for QSAs.
- How are QSAs supposed to reference these non-compliant devices in the merchant’s Report On Compliance (ROC)?
- Do QSAs mark this in the ROC as non-compliant and which requirements do QSAs flag as non-compliant? Is it because the devices are not PTS compliant or are their other requirements that are not met?
- Do QSAs need a compensating control for these devices? And exactly what would the controls be that would make these devices acceptable?
- Do QSAs need to obtain a letter from the merchant’s acquiring bank(s) acknowledging the use of these devices and their approval of their use?
I am sure this will create many interesting discussions at the PCI Community Meeting that is just a few weeks out. So stay tuned.
PCI Guru 
It’s not strictly a PCI requirement but in the UK, VISA has made it clear that using a card not present method, e.g. merchant provided tablet giving access to the web site when in a card present setting, e.g. in the shop, would never be acceptable unless a P2PE reader was used to input the card data i.e. making it a card present method.
Thanks for the update.
The most common implementation would seem likely to be using the smartphone/tablet to access a payment gateway service via https. I’m not clear why this should be much different to an SAQ-C-VT scenario. Indeed since there is no connection to any other merchant infrastructure it might be more secure. Why has the PCI SSC not explicitly commented on this approach?
A customer accessing a Web site though any devices’ browser via SSL/TLS/etc. is never in scope.
Where this changes is when the merchant or their third party is accessing a Web site via a browser to process payments such as with a call center. The risk is that a piece of malware could end up on the call center workstations that records their keystrokes. Since they process volumes of potential credit/debit card transactions, the number of PANs collected is large. That is why the PCI SSC tells us to ensure that these workstations are protected and included in the scope of the assessment.
Hi Mate,
Even those devices are provided by the merchant themselves e.g. PC based kiosks directing customers to their website to make a payment (similar to if they were doing it from their own devices at home)?
Cheers,
Ash
If you are providing the mechanism (PC, tablet, whatever) for your customers to use. Who do you think is liable if a keyboard logger or memory scraper gets installed and captures your customers’ cardholder data? That would be your organization. So I would highly recommend that you heavily secure any such devices and patch them regularly.
Asking as a developer, does this mean that there taking card payments through a mobile app is dead in the water unless I want to fall foul of PCI? Or is there any way that I can take a card payment through a mobile app other than using an IFrame to a PSP form?
It just means you do not want to develop the card transaction processing solution. You want to use the processors’ or acquirers’ solution for processing mobile payments.