PCI P2PE vs. E2EE – Scoping it Out

Many payment processors sell “End-to-End Encryption” (E2EE) payment terminals with slick marketing that describes how well the solution protects payment card data. While encryption is an effective tool for protecting payment card data, merchants need to look beyond the marketing to understand the impact this has on their PCI DSS compliance obligations. This post will explain the Point-to-Point Encryption (P2PE) program and then cover how E2EE branded solutions fit in (or don’t) with P2PE scope, requirement applicability, and compliance reporting reduction benefits.

As a Qualified Security Assessor (QSA), I regularly encounter merchants that believe their use of a payment terminal branded as E2EE automatically qualifies them for significant reduction in the number of PCI DSS requirements that are applicable to their environment and the scope of applicability of these requirements within the environment. However, this is not the case and is often the result of confusion between E2EE and the official PCI P2PE program. Merchants with E2EE solutions are often left struggling to implement PCI DSS requirements that they didn’t think would apply on systems that they didn’t think were in scope with a looming assessment deadline.

TrustedSec has years of experience as a QSA company assisting organizations with their PCI DSS compliance obligations, including working with acquirers and card brands to help understand their specific requirements for E2EE solutions. Please get in touch with us for more assistance.

What is the P2PE Program?

The P2PE standard defines how payment terminals communicate with the processor and includes both encryption processes and encryption key management processes. The intent is that payment card account data entered into a terminal is immediately encrypted and that the only party that can decrypt the card data is the processor, regardless of any intrusions into a merchant network. In theory, the only significant threat to a P2PE terminal is physical tampering, e.g., installation of a skimmer or unauthorized substitution of a terminal with an attacker’s terminal.

The official P2PE program published by the PCI Security Standards Council (PCI SSC) includes:

• A standard that defines how P2PE solutions must be designed by the processor
• A validation program so that a processor’s P2PE solution can be independently evaluated for compliance with the P2PE standard
• A page that lists the validated P2PE solutions
• A self-assessment questionnaire for merchants that only includes the PCI DSS requirements that are applicable to a validated and listed P2PE solution

There is also a process for a merchant to create their own merchant-managed P2PE solution, but this is rare. Most P2PE solutions are created, managed, and validated by a processor.

The P2PE standard is separate from and builds on the PCI Pin Transaction Security (PTS) Point of Interaction (POI) Standard for payment terminal hardware. The use of PTS validated hardware does not result in any PCI DSS compliance scope or requirement applicability benefits, but a PTS validated terminal is a prerequisite for a P2PE solution and is often required by acquiring banks regardless of whether a P2PE solution is being used.

Benefits of Validated P2PE Solutions

Less Applicable PCI DSS Requirements

Merchants are not required to use a P2PE solution, but a merchant that uses a validated P2PE solution can meet the eligibility criteria for SAQ P2PE which contains only 15 applicable requirements (plus 6 additional requirements that only apply if the merchant handles paper records, but this is rare). Merchants that must complete a Report on Compliance (ROC) but would otherwise be eligible for SAQ P2PE also benefit as they may use the Self-Assessment Questionnaire (SAQ) to determine applicability of the requirements in the ROC, as per PCI FAQ 1331.

The next smallest SAQ that a merchant could use for a non-P2PE Internet-connected payment terminal solution is SAQ B-IP which contains 37 applicable requirements (plus 15 for paper records), more than doubling the size of the compliance effort relative to SAQ P2PE. SAQ B-IP also requires isolation of the payment terminals from other systems in the merchant environment (i.e., network segmentation) while SAQ P2PE does not.

To contrast SAQ P2PE with SAQ B-IP, the applicable requirements (excluding requirements for paper records) in SAQ P2PE are related to:

• Protecting the terminals from physical tampering and substitution
• Security awareness training, including tampering awareness and what to do if tampering is suspected
• Managing the relationship with third-party service providers
• Maintaining an incident response plan

SAQ B-IP includes all the requirements in SAQ P2PE but adds requirements related to:

• Firewall rulesets that protect the payment terminals
• Encryption of transmitted payment card account data
• Configuration and vulnerability management of the firewall that protects the payment terminals
• Restricting user access and implementing appropriate identification and authentication processes for accessing the payment terminals and/or firewalls that protect them
• Physical security in the facility that contains the payment terminals
• Internal penetration testing to confirm isolation of payment terminals and external vulnerability scanning

A merchant that does not qualify for SAQ P2PE or SAQ B-IP would need to use SAQ D Merchant which contains all 234 PCI DSS requirements that are potentially applicable to merchants, more than 15 times the number of requirements in SAQ P2PE. While many of these requirements may not apply to a simple payment terminal environment, each non-applicable requirement would need to be individually documented and justified in Appendix C of the SAQ. Additionally, while isolating the payment terminals is not required to use SAQ D Merchant, any devices within the merchant environment that are not isolated from the payment terminals are also in scope for PCI DSS compliance.

Eliminating Validation and Reporting Requirements

Another advantage to using a P2PE solution is the possibility of qualifying for programs that eliminate PCI DSS validation obligations. Merchants that qualify would still need to comply with the PCI DSS requirements for P2PE solutions as described above (unless they exclusively accept Mastercard, in which case PCI DSS compliance is not required either), but would no longer be required to complete an annual SAQ or ROC.

Each card brand has its own slightly different program, but a common theme is that at least 75% of transactions must be via a validated and listed P2PE solution to qualify. More information on each program can be found at the following links:

• Visa Technology Innovation Program (TIP)
• Mastercard Compliance and Validation Exemption Program (C-VEP)
• American Express Security Technology Enhancement Program (STEP)

Qualifying to use SAQ P2PE

Merchants that use a P2PE validated solution will need to confirm that they meet the eligibility criteria on page iii of SAQ P2PE. Note that service providers can never use SAQ P2PE (or any SAQ other than D Service Provider) and SAQ P2PE cannot be used for eCommerce payment channels. The SAQ P2PE eligibility criteria at the time of this post are as follows:

• All payment processing is via a validated PCI-listed P2PE solution;
• The only systems in the merchant environment that store, process or transmit account data are the payment terminals from a validated PCI-listed P2PE solution;
• The merchant does not otherwise receive, transmit, or store account data electronically.
• Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically; and
• The merchant has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.

Common challenges merchants face with these criteria include:

• Merchants try to use SAQ P2PE while using a solution that is not P2PE validated and listed, usually:
  • An E2EE branded solution
  • A P2PE solution with an expired validation which is no longer considered validated as per PCI FAQ 1483
• Receiving, transmitting, or storing account data electronically outside the P2PE terminal solution:
  • VoIP traffic is in scope for PCI DSS just as any other IP network traffic containing card account data would be as per PCI FAQ 1153, so merchants using P2PE terminals as part of a call center that receives payment card account data via VoIP calls are electronically receiving account data outside the P2PE solution.
  • At least 1 major processor is known to have sent CVV codes from the processor environment back into the merchant environment, resulting in additional merchant systems electronically receiving account data outside the P2PE solution.
• Many merchants don’t seem to be aware of the PIM and are not following it.

Getting a P2PE Solution

Merchants that are interested in the scope and requirement applicability reduction benefits of SAQ P2PE should reach out to their processor to see if a P2PE solution is available (and if they are already using it). A P2PE solution often costs extra, but this cost will likely be offset many times over by the reduction in effort required to maintain and assess compliance relative to other longer SAQs.

Merchants can also search for their processor on the list of validated P2PE solutions, but the presence of the processor on this list does not mean that the payment solution the merchant is using is the validated solution, even if the payment terminals the merchant is using are supported as part of that solution. Merchants still need to confirm that the solution they are using is the P2PE validated solution.

Many processors that do not offer P2PE solutions will refer to their E2EE solution instead, and may state that "P2PE is not required”. While it is true that P2PE is not required by PCI DSS, E2EE solutions almost always result in a higher PCI DSS compliance burden for the merchant than a P2PE solution as explained below.  Merchants that believe they are using a P2PE solution should always request the P2PE reference number to confirm they are using a validated P2PE solution. This number is assigned to all legitimate validated P2PE solutions and can be looked up on the list of validated P2PE solutions.

If the merchant’s processor does not have a P2PE solution available, the merchant will need to change processors to get a P2PE solution. Unfortunately, this will likely require replacing the payment terminals because a key part of the P2PE solution is the process of setting up and loading the encryption keys before the terminals are sent to the merchant.

The Challenges of E2EE

Relationship with P2PE

E2EE is not an official PCI term and the similarity between the E2EE branding and the official PCI P2PE program branding has led to much confusion among merchants. E2EE is a term that many processors seem to use when they have a solution that does not meet the P2PE standard, or they have a solution that they think meets the standard but do not want to go through the P2PE validation process. Either way, this lack of validation has negative consequences for the PCI DSS compliance program of merchants using E2EE solutions.

As shown above and in PCI FAQ 1247, merchants may only use the shorter SAQ P2PE if they meet the eligibility criteria, which includes the use of a validated P2PE solution. As E2EE solutions are not validated, merchants that use them are not eligible to use SAQ P2PE and must use one of the longer SAQs that contains more requirements that a merchant may not have been expecting. This applies no matter how enthusiastic the processor is about their amazing encryption: because the solution has not been validated against the P2PE standard, a QSA has no way of knowing if the solution is doing what it should and, as per PCI FAQ 1246, QSAs cannot evaluate the solution against the P2PE standard.

E2EE Scope and Requirement Applicability

Many merchants think that the use of encryption should reduce the PCI DSS scope or the number of applicable requirements, but encryption of the payment terminal’s transmission of payment card account data is in fact a requirement for devices that are in scope (PCI DSS v4.0.1 requirement 4.2.1), not an automatic way to reduce scope (as per PCI FAQ 1086 and the Encrypted Cardholder Data and Impact on PCI DSS Scope subsection of PCI DSS Requirements and Testing Procedures section 4). P2PE validation is a special case where scope can be reduced because the encryption process (including key management) has been validated to meet a defined standard.

A merchant that uses an E2EE solution may qualify for SAQ B-IP (doubling the applicable requirements relative to a P2PE solution) if they meet the eligibility criteria which includes isolating the payment terminals from other systems within the merchant environment (usually via network segmentation). Merchants that choose not to isolate their payment terminals or otherwise cannot meet the SAQ B-IP eligibility criteria will be faced with the full 234 requirements of SAQ D Merchant, applicable to all devices that are not isolated from the payment terminals. This is described in more detail above under Benefits of Validated P2PE Solutions.

Special Exceptions

There is also an alternative path for potential scope and requirement applicability reductions with E2EE: As per PCI FAQ 1162, merchants using encryption solutions that have not been validated and listed on the PCI SSC website can reach out to their acquiring bank(s) (for Visa and Mastercard) and/or the relevant card brand(s) (for other payment cards they accept) to determine what set of requirements they will allow. Some acquirers will allow merchants using a specific E2EE solution to use SAQ P2PE. More commonly, merchants are required to follow a version of SAQ B-IP that has some requirements pre-marked Not Applicable.

There are caveats to getting acquirer and card brand permission to use a reduced set of requirements compared to the officially applicable PCI DSS requirements:

• All relevant acquirers and card brands will need to agree on the applicable requirements. Acquirers (for Visa and Mastercard) are often more lenient in this regard than card brands, especially if the acquirer also provides the E2EE solution, so merchants that only accept Visa and Mastercard may have better results with this approach while merchants that accept other cards may find that they are stuck with SAQ B-IP or D.
• Acquirers and card brands may introduce extra prerequisites above and beyond PCI DSS before a merchant can use a reduced set of PCI DSS requirements, which increases the compliance burden. Acquirers and card brands may change these prerequisites at any time, leading to unexpected disruption in the compliance program.
• Acquirers and card brands may revoke their authorization to use a reduced set of PCI DSS requirements at any time, leaving a merchant scrambling to implement additional PCI DSS controls that they had been exempted from.

Managing an E2EE Solution

The unfortunate reality is that E2EE branding isn’t much more than marketing hype and E2EE branded solutions often do not reduce PCI DSS compliance effort in any meaningful way.

Merchants using E2EE solutions should be prepared to meet the eligibility criteria for and requirements in SAQ B-IP, or the requirements in SAQ D Merchant if they are unable to meet the SAQ B-IP eligibility criteria. This includes merchants that have received permission from acquirers and card brands to implement a reduced set of requirements due to the risk of this permission being revoked in the future.

TrustedSec can help merchants struggling with their E2EE solutions, both to find the best compliance option or to help map a path to move to a P2PE solution that will reduce compliance effort.