The Differences between PCI-Validated P2PE and Non-Validated P2PE Solutions

On January 25^th, we released our latest paper, the Impact of PCI-Validated P2PE, authored by our P2PE QSA Coalfire.® Last week we discussed the first major section of the paper, The Role of P2PE, EMV and Tokenization in Securing Payments.

This week’s blog discusses the second major section of the white paper, The Differences between PCI-Validated P2PE and Non-Validated P2PE Solutions. And next week we will discuss the last major section, The Return on Investment (ROI) and Total Cost of Ownership (TCO) of a PCI-validated P2PE Solution.

The white paper can be downloaded in its entirety or via these 3 sections on our Resources page.

How the PCI P2PE Standard Applies to PCI DSS

Before considering the specific impact of P2PE on a merchant’s environment, it is important to understand how encryption fits into the larger context of a merchant’s compliance with the PCI DSS. Since its first version released in 2004, the PCI DSS security framework has provided a list of controls that are required to address security threats that could compromise cardholder data within a merchant environment. Each security control—whether through physical security, technical controls, or organizational policies and procedures—is associated with one or more identified threats that may jeopardize the security of credit card data.

Throughout the PCI DSS, different forms of encryption are required in conjunction with other technical, physical, and procedural controls within the cardholder data environment (CDE). See our white paper for a list of all applicable controls to the CDE.

Intent of the PCI P2PE Standard

Recognizing the presence of existing encryption solutions and the growing need for guidance on their proper implementation, the PCI SSC sought to identify the specific impact of transaction encryption within its standards framework and provide a structure for companies to receive PCI SSC scope reduction from implementation of approved encryption solutions. It was very important for the PCI SSC to clearly identify which risks could be fully addressed and the associated controls which might be reasonably omitted in order to adequately protect card data. Some of the questions that needed to be answered included:

• How strong must the encryption be to safely courier data without being vulnerable to brute-force decryption?
• What key management practices are adequate to protect the private key from compromise?
• What controls are necessary at the point of encryption to protect sensitive encryption keys?
• How can a merchant trust the integrity of the decryption environment to be free from vulnerabilities?
• How will these controls be validated?

In 2012, the PCI SSC released the first version of the PCI P2PE standard, the P2PE program guide, and the special P2PE self-assessment questionnaire (SAQ) for merchants.Updated in 2015, PCI P2PE version 2.0 establishes a specific list of controls that encryption providers must enact in order to be listed as an approved P2PE solution or component.

Non-Validated (Unlisted) Encryption Solutions

Encryption solutions that have not been validated by the PCI SSC, but still provide functions such as encrypting within the point of interaction (POI) terminal and decrypting outside the merchant environment, are generally called unlisted P2PE solutions or End to End Encryption (E2EE) solutions.

“The trouble with unlisted solutions is that there may be no way for a merchant to know whether the provider has fully addressed the controls identified by PCI SSC as necessary to properly protect the account data. Many of the unlisted solution providers Coalfire has reviewed do use very secure processes; however, since unlisted solutions have not been assessed under the standardized PCI P2PE framework by qualified assessors, merchants using these solutions may still need to implement additional security countermeasures to ensure threats associated with the absence of these controls.”

Additionally, unlisted solutions do not qualify for the reduced SAQ P2PE, so merchants using these solutions should use the SAQ D (or ROC template if applicable).

PCI-Validated (PCI-Listed) P2PE Solutions

PCI-Validated P2PE solutions have been assessed by a QSA (P2PE) as having met the PCI P2PE standard and are therefore listed on the PCI website under Approved P2PE Solutions. In addition to meeting the P2PE standard, the decryption component of the solution must operate within a secure environment that has been assessed to the full PCI DSS standard.

Other requirements include:

• Assessment of the key management practices and cipher strength
• The use of certified key injection facilities (KIFs)
• Use and configuration of PTS-approved POI devices with encryption performed in the SRED (secure reading and exchange of data) tamper resistant security module (TRSM)
• Positive device identification prior to decryption
• Key management/decryption in hardware security modules (HSMs) that have been validated by PCI and/or FIPS 140-2 Level 3

Differences between Validated and Non-Validated P2PE Solutions

“It is impossible to generalize and say that all non-validated solutions are missing any specific security control(s), because every solution is different. While it is true that all validated solutions have been assessed as meeting the criteria for the PCI P2PE program, the only general statement that can be made about non-validated solutions is that they have not yet been validated to actually meet the same standard. For some, it may simply be a matter of completing the assessment process. For others, non-validated solutions may be lacking important security controls that prevent them from becoming validated, such as performing key management functions without the use of an approved HSM or using PTS devices that lack the SRED-certified TRSM.”

The Benefits of PCI Validation for Merchants

There are numerous tangible benefits merchants receive from using a solution that has been through the validation process.

PCI-Authorized Scope Reduction

Merchants who use a validated solution within their environment and keep this environment segmented from any card data from other channels (e.g., e-commerce) are eligible to complete the authorized self-assessment questionnaire SAQ P2PE that is known and accepted by all acquirers. Under PCI DSS v3.2, this represents a significant reduction of controls, reducing the number of questions by nearly 90% for merchants moving from the SAQ D (329 questions) to SAQ P2PE (33 questions).

Another aspect of scope reduction is the impact of PCI P2PE on the definition of the CDE itself. Since merchant systems can no longer access the cardholder data once it is properly encrypted, P2PE effectively reduces the number of networks and systems considered to be within the scope of the PCI DSS assessment. This scoping guidance is endorsed by PCI and commonly followed by assessors, but only for solutions that have been through the validation process.

Card Brand Programs

Visa Technology Innovation Program (TIP)

Merchants who accept at least 75% of their transactions through a PCI-validated P2PE service may qualify to apply through their acquirer for the Visa TIP program, which allows approved merchants the ability to discontinue their annual assessment process to revalidate PCI DSS compliance. While available for merchants of any size, this program is especially valuable for high-volume or geographically dispersed merchants who may otherwise undergo a more strenuous and costly assessment process.

Visa Secure Acceptance Program

This program incentivizes acquirers by providing safe harbor for fees in the event of a compromise for Level 3 and 4 card-present merchants who use a PCI-validated P2PE solution. There is no application process, although a merchant should still strive for full PCI DSS compliance and have documentation showing that 100% of transactions were accepted via a listed solution.

Solution for Challenging Compliance Issues

Mobile Acceptance

Mobile point-of-sale (mPOS) apps available for download for consumer mobile devices (like Android, iOS and Windows Mobile) do not qualify for PA-DSS, making it difficult for merchants to assess the compliance of these software applications.

PCI P2PE is perfectly suited to address these issues. By encrypting all card data within a validated card reader before it passes through the mobile device, the consumer mobile device is rendered out of scope for PCI DSS compliance (so long as it is not used for any other payment function), ensuring compliant card acceptance via a consumer mobile device.

Foreign Networks

Because systems and networks between the encryption point and the decryption environment are no longer in scope due to the P2PE encryption, this unique advantage can address complex network responsibility challenges for some merchants. For example, store-within-a-store retail concepts often use their host store’s network to provide Internet connectivity, but cannot treat the host network as a true “open, public network” (as defined in Requirement 4). For instance, in a case study published by PCI, The Hillman Group, discusses this specific challenge and their use of Bluefin’s P2PE solution to transmit P2PE-encrypted account data over their host’s network without bringing it into scope.

Join us next week when we will wrap up our blog series with the last white paper section, the TCO and ROI of a PCI-validated P2PE solution.