Problem solve Get help with specific problems with your technologies, process and projects.

Understanding PCI mobile payment processing security guidelines

Mike Chapple discusses the new PCI Mobile Payment Acceptance Security Guidelines and the mobile payment processing implications for merchants.

The past few years have seen the rapid growth of credit card payment processing services among merchants. It's...

no longer uncommon to see a taxicab or restaurant that brings an iPhone to a customer, equipped with a small credit card reader, accepting a payment without the need for the traditional, bulky, hard-wired register systems or a dedicated wireless credit card terminal.

Mobile payment processing is a revolution for retailers, but a disaster for compliance. Until now, merchants that process payments using mobile devices did not have clear guidance regarding the compliance of these devices with the Payment Card Industry Data Security Standard (PCI DSS) and were left in a strange limbo where they might find themselves approached by the same banks that demand they maintain PCI compliance, offering to sell them products that might not be PCI-compliant. Fortunately, merchants, acquirers and everyone involved with PCI DSS compliance have more guidance to work with.

Given this complexity, an organization should only adopt mobile payment processing if there is a compelling business case for the technology.

In this tip, we take a look at the details of the recently released PCI Mobile Payment Acceptance Security Guidelines. This collection of best practices, released by the PCI Security Standards Council (SSC) in February 2013, describes the SSC's interpretation of how PCI DSS affects mobile payment security and educates merchants on the risk factors of using mobile devices to accept credit card payments.

Scope of the guidance

The new guidance is meant to provide advice on how to handle situations where payment applications are running on, to quote from the guidance, "any consumer electronic handheld device (e.g., smartphone, tablet, or PDA) that is not solely dedicated to payment acceptance transaction processing and where the electronic handheld device has access to clear-text data."

What does that mean? This guidance applies to situations where users accept credit cards on iPhones, iPads, Android devices and other mobile platforms that are not dedicated to payment card processing. There are two important topics that aren't given much consideration (if any) within the scope of these guidelines.

First, while many organizations are adopting bring your own device (BYOD) strategies for mobile computing, the PCI SSC is quite leery of BYOD in the guidelines, saying, "Since the BYOD scenario does not provide the merchant with control over the content and configuration of the device, it is not recommended as a best practice." So what does that mean? Is BYOD mobile payment processing allowed or not? The SSC seems to leave it up to often-subjective QSAs to decide whether such a scenario would be PCI-compliant, meaning merchants are left to their own devices (perhaps both literally and figuratively) when determining their compliance posture.

Second, the guidelines do not cover cases where a consumer is inputting a credit card number into his or her own device/application. For example, if you offer a mobile website or app that allows consumers to purchase products online using their own mobile devices, these guidelines do not apply. The parts of the mobile payment ecosystem that the merchant controls (the mobile app, website and back-end systems, in most cases) are certainly subject to the normal PCI DSS requirements, but the consumer is responsible for maintaining the security of the mobile device itself. The guidelines only apply when the merchant is using a device at the point of sale.

So what do the guidelines cover? They cover technologies like Square's mobile card reader and PayPal's PayPal Here reader, which are rapidly being adopted in retail environments.

Best practices for mobile payment acceptance

Any organization considering the adoption of a mobile payment acceptance platform or already using this technology should read the guidelines carefully. They contain security best practices covering three major categories: transaction security, device security and application security.

The guidelines contain three basic objectives for securing transactions: Prevent account data from being intercepted when entered into a mobile device; prevent account data from compromise while processed or stored within the mobile device; and prevent account data from interception upon transmission out of the mobile device.

These objectives have shared responsibility between the merchant and the service provider. The service provider can ensure that the technology itself protects against these attacks, such as requiring the use of strong encryption for transmission of payment card transactions. However, the merchant must also take steps to ensure that the product is used in a manner consistent with secure operation, such as limiting device access to authorized users.

Merchants bear a significant burden of responsibility when it comes to securing the mobile devices themselves. The guidelines contain six specific recommendations in this realm. While each is important in its own right, the most significant is the physical and logical security of mobile devices used for payment acceptance. Merchants must ensure that they have adequate controls in place to protect against theft or unauthorized access to devices used for mobile payments. Merchants must be certain that devices are securely stored when not in use by locking them in a cabinet, securing them to a wall or counter or placing them under constant surveillance. While this may limit the mobility of the device, it also guards against unwanted mobility -- namely, a device walking out the door in the hands of a stranger! Additionally, the application or device must be configured with strong authentication, such as a password or multifactor authentication.

Other recommendations include: protecting the device from malware; ensuring the mobile device isn't "jailbroken"; disabling unnecessary device functions; installing device tracking software for use in case of loss or theft; and ensuring the secure disposal of old devices. For large enterprises, these may be fairly standard mobile device security processes, but smaller organizations will likely need to make a concerted effort to put these processes in place.

The exact division of responsibility between the merchant and payment processing service provider will vary depending upon the specifics of the device types, software and services in use. For example, if the service provider owns and manages the mobile devices on behalf of the merchant, the merchant will have little room to alter the configuration of device functions, but will still bear the burden of protecting against loss, theft and unauthorized access.

Controls in the final category, application security, also place responsibilities on both the merchant and service provider. These include: merchants implementing only those secure services that meet PCI DSS requirements; service providers ensuring merchants have clear instructions for the secure operation of the application; merchants avoiding offline transactions or authorizations; merchants preventing unauthorized usage of devices; and merchants reviewing logs for suspicious activity.

Working through the mobile device guidelines can be a significant undertaking. As with the PCI standard itself, each of the major control areas is subdivided into up to seven specific control objectives, and those objectives may have multiple guidelines for merchants to follow. This all adds up to a 23-page document detailing a complex control environment for mobile payment acceptance. Given this complexity, an organization should only adopt mobile payment processing if there is a compelling business case for the technology -- this is not the area in which to experiment using a "gee whiz" solution. If the business case is justified, an organization's first step should be to sit down with the mobile payment guidelines and read through them line by line, just as you would the PCI DSS itself. Highlight the sections where it's unclear whether your technology or processes would be deemed compliant, and use that marked-up copy of the document to develop a list of action items for remediation.

While the mobile payment guidelines offer quite a few best practices, merchants should be relieved to find that they are mostly common-sense interpretations of the PCI DSS standards. Merchants using mobile devices for payment processing today likely won't need to implement radical changes in order to ensure PCI DSS compliance, if they've been applying a common-sense interpretation of PCI DSS all along. Those considering mobile payment processing implementations in the future will find the documents a helpful resource. Without question, any merchant using or considering use of a mobile payment application should review the guidelines in their entirety.

From the editors: More on mobile PCI compliance

About the author:
Mike Chapple, Ph.D., CISA, CISSP, is an IT security manager with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Chapple is a frequent contributor to, and serves as its resident expert on enterprise compliance, frameworks and standards for its Ask the Experts panel. He is a technical editor for Information Security magazine and the author of several information security titles, including CISSP: Certified Information Systems Security Professional Study Guideand Information Security Illuminated.

This was last published in March 2013

Dig Deeper on PCI Data Security Standard