P2PE vs E2EE: Common Pitfalls and Deployments

What is P2PE?  

Point-to-Point Encryption (P2PE) in the payment card industry involves deploying a recognized solution by the PCI council, where hardware, processes, and technology undergo rigorous testing against the current P2PE Standard v3.1 or earlier versions. 

The P2PE standard combines a recognized and certified PTS device with software and encryption methods to allow cardholder data to be encrypted upon swipe and transmitted encrypted throughout the merchant environment until decrypted within a decryption environment, inaccessible to the merchant.  

Leveraging P2PE allows merchants to reduce scope by eliminating the encrypted credit card data passing through the P2PE solution within the merchant’s environment, including networks, workstations, and server infrastructure. P2PE must combine a specific set of factors together to adhere to the solution deployment including leveraging appropriate PTS devices, encryption algorithms, and software/firmware constraints. Note that while P2PE reduces scope of an assessment for PCI DSS compliance, it does not eliminate all duties of the merchant.  

For additional information on PCI DSS requirements that remain applicable to the merchant, consult an SAQ-P2PE document or speak with a QSA. MegaplanIT can assist in evaluating the right P2PE solutions for your business, ensuring compliance and best practices. 

What is E2EE? 

End-to-End Encryption (E2EE) in the payment card industry is the deployment of certain technologies that may reduce the scope of a merchant’s environment; however, it is not a recognized and validated solution by the PCI SSC, nor can it automatically benefit from scope reduction per the P2PE standard.  

This solution is attractive to merchants as E2EE relies on a wider array of technologies to attempt scope reduction. The issue with this technology is that E2EE deployments are not subject to the same rigorous testing and validation as P2PE validated solutions and are not endorsed by the PCI SSC for any type of scope reduction.  

Additionally, E2EE solution deployments do not have a set cadence for re-testing or re-validation from the solution provider to ensure that the product maintains its working purpose. Additional effort must be made for an E2EE deployment via a Non-listed Encryption Solution. E2EE solutions may also leverage intermediate nodes to perform encryption functions which may further expand the scope of the solution and introduce additional attack surface area.  

Being Part of the Solution 

Auditing the elements of a P2PE solution is low effort for the merchant, as this deployment affords simple device metrics to be observed and collected.  

The P2PE Instruction Manual (PIM) provides auditors with specific configurations and hardware required for the successful deployment of the P2PE solution. Validating these elements will guarantee that the deployment is valid and within the criteria for a PCI SSC P2PE solution.  

A list of P2PE Solutions may be found on the council website which outlines companies and products that may be used within this program. Note that the website does not provide a PIM, as this would come from the solution provider. From the Council:  
 

P2PE Solutions and the PIM – Each PCI-listed P2PE Solution has an associated P2PE Instruction Manual (PIM) that is provided by the Solution Provider. The PIM provides merchants pertinent guidance to effectively and securely manage their encryption environments and devices within their purview: e.g., the secure installation of POI devices, details of all P2PE Applications and other software on the POI devices, monitoring POI devices for signs of tampering, and appropriate incident response procedures for security incidents.
 

If your P2PE solution has an expired validation, the payment brands and/or acquirers must be contacted to continue to leverage the solution.  

The Issue with Leveraging a NESA Document 

Deploying a NESA based solution introduces some, but not all scope reductions into the environment as a validated P2PE solution would achieve. The NESA per the PCI SCC guidance was a document to identify gaps between a standard P2PE deployment of a solution and a solution that does not meet all criteria of P2PE.  

This causes the solution to be under scrutiny of all data elements found in PCI DSS unless proven otherwise by a certified PCI P2PE assessor. This guidance predates the P2PE standard and was introduced before formal P2PE assessments were implemented.  

From an auditing perspective, a QSA evaluating an entity using a NESA documented solution will determine the viability of the deployment, validity of the solution as deployed, and if scope reduction is possible via the NESA scope reduction document.  

The deployment of the solution would need to be supported by NESA documentation, PIM documentation, whitepapers, and other supporting factors to attribute to the security of the deployment. Payment processors would also need to acknowledge and accept the risk that per the NESA deployment they are accepting cardholder data over the deployed solution.  

It is not recommended by the PCI Council to leverage a Non-Listed Encryption Solution as even with a NESA does not fully meet the intent and requirement of the P2PE program.  

Using the Correct PTS Device 

Aging POI devices may play a role in issues with the deployment of the system. Payment card terminals or PTS devices (PIN Transaction Security) have cryptographic standards and configurations within the hardware of the device. The deployment of NESA solutions may leverage out-of-date Approved PTS devices, which cannot be validated to be secure in their hardware security modules. If observing a P2PE encryption solution, the solution must be verified every three years where dated technology is less of a concern; The most up-to-date software and applicable hardware are leveraged during the assessment as providers of the solution wish to remain relevant and compliant to PCI P2PE standards.  

Regardless of deploying a NESA or P2PE solution, appropriate diligence for using an approved PTS device is required for validation. Validation of such PIN Transaction Security devices is listed on the council website as recognized POI terminals. From an auditing perspective, appropriate documentation including central management console outputs, physical inspection of POI devices, and configuration observation are required to validate any POI device deployed within the production network.  

  Why Can’t the QSA Treat the NESA as a P2PE?  

The QSA cannot treat the NESA as a P2PE solution because it does not meet the rigors of the P2PE standard as outlined by the PCI Council. Further, the PCI QSA is not qualified to perform the same P2PE assessment tests on the deployed NESA solution, as these would be required to be handled by a qualified P2PE Assessor. The cryptographic modules, deployments, key injection, and payment application would need to be investigated by the Manufacturer of the NESA solution rather than the entity to which it is deployed.  

Asking the QSA to audit a single deployment of a NESA environment is not possible, as all the factors that facilitate the scope reduction cannot be observed or investigated within the entity’s environment.  

The published NESA document is also not a crutch to facilitate a solution to be P2PE but only guidance from the council to implement a non-standard encryption solution. IT must be agreed upon by all concerned parties including processor, merchant, and payment brand that a non-PCI SSC approved medium is receiving credit cards in a compliant way.  

Common Uses of P2PE vs E2EE 

Marketing jargon aside, point-to-point encryption solutions per PCI SSC are solutions where the sensitive data like Track is encrypted at the moment of swipe within the POI device. This ensures that transmission between that POI device and its intended endpoint is secure as the data captured is indecipherable without those with keys. Transmission layer security, system patching, and access management for elements between these two points are irrelevant as the data package traversing is encrypted and not of viable use to an attacker. Point-to-Point encryption is typically found only in payment card industry deployments for acceptance of credit cards where the keys to the solution are not held, manipulated, or loaded by the entity leveraging the solution.  

The use of End-to-End encryption has no guarantee of supporting all elements of a certified P2PE solution and must be taken into consideration by the assessor, processor, and other stakeholders to be validated or supported. Remember that an E2EE solution with a NESA does not meet all the PCI SSC requirements for P2PE and therefore cannot benefit from all the scope reduction it provides. Typically, deployments of E2EE solutions include email servers, file sharing, video calling, or text messaging services. 

Conclusion 

Choosing the right encryption solution for your payment processing environment is crucial for PCI DSS compliance and overall security. Whether you opt for a validated P2PE solution or an E2EE implementation, understanding the associated risks and deployment requirements is key to protecting your business and customers. 

If you’re unsure about which encryption solution is best for your needs or need assistance with compliance, MegaplanIT can provide the expertise and services necessary to ensure your deployment is secure, compliant, and optimized. Contact us today to learn how we can help streamline your security efforts and safeguard your payment processing infrastructure.