Services
Services
SOC & Attestations
SOC & Attestations
Payment Card Assessments
Payment Card Assessments
ISO Certifications
ISO Certifications
Privacy Assessments
Privacy Assessments
Federal Assessments
Federal Assessments
Healthcare Assessments
Healthcare Assessments
Penetration Testing
Penetration Testing
Cybersecurity Assessments
Cybersecurity Assessments
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
ESG & Sustainability
ESG & Sustainability
AI Services
AI Services
Industry Solutions
Industry Solutions
Cloud Computing & Data Centers
Cloud Computing & Data Centers
Financial Services & Fintech
Financial Services & Fintech
Healthcare
Healthcare
Payment Card Processing
Payment Card Processing
US Government
US Government
Higher Education & Research Laboratories
Higher Education & Research Laboratories
About Us
About Us
Leadership Team
Leadership Team
Careers
Careers
Corporate Social Responsibility
Corporate Social Responsibility
Strategic Partnerships
Strategic Partnerships

Point-to-Point Encryption (P2PE) FAQ

Payment Card Assessments

In the classic film Twister, Bill Paxton and Helen Hunt are faced with life or death at the very end. As an F5 tornado bears down on them, they use leather belts to anchor themselves to the ground, keeping themselves from getting swallowed up in the maelstrom.

We can debate how realistic that particular scenario is later. The fact of the matter is, sometimes it really does help to have a few anchor points to steady us amidst the chaos.

Which is why we’re going to give you some, only instead of saving you from a terrifying tornado, we’re going to simplify point-to-point encryption (P2PE) for those of you accepting credit card payments or processing payments.

Even if you’re just on the fringe of this sector, you should know about this security solution that can help protect data against bad actors. It’s about customer trust, so why not use one of the best tools that can help you do that?

But we get it, payment card security is complicated, and even as a subset, encryption is the same. We’ve been assessing P2PE Solutions since 2015, so we understand the security standard in its entirety because we must. Let us pass some of that knowledge to you through our answers to a few frequently asked and important questions on the subject.

We’ve already discussed what P2PE is, along with how exactly it’s assessed. Now we want to address some of the terms you saw in that article more specifically, along with more concepts you might see as you navigate the P2PE possibilities. The tornado may seem to still swirl around you as you continue your journey in this area, but after this, you’ll be solidly anchored to the ground with knowledge–not a movie-magic leather belt.

(As we get going, be forewarned–there are a lot of acronyms.)

1. What is a Point of Interaction (POI) Device?

 

  • A POI device is the name given by the Payment Card Industry Security Standards Council (PCI SSC) to devices that interact directly with a cardholder’s payment card to process payments. These are the physical terminals you use, and they come in many forms—you’ve probably seen them before at grocery store checkouts, gas stations, and brought tableside by waitstaff.
  • How is this particularly relevant to P2PE? P2PE requires the use of PCI PIN Transaction Security (PTS)-approved POI devices, meaning it requires that the hardware and firmware of POI devices be reviewed against this standard and approved for use within P2PE Solutions. If these devices are approved, and thereby listed under the PTS POI Standard, you can be sure that these POI devices are capable of protecting card data, are configured to do so, and that tampering with the device will render it unusable.
  • If you’re providing a P2PE solution, you must use approved POI devices listed under the PCI SSC’s PIN PTS POI devices program. They must also both include and use Secure Reading and Exchange of Data (SRED) functionality for the encryption of card account data to be P2PE compliant.
    • It’s important to ensure that you’re using the actual PTS-approved device, since manufacturers may sell many variations of a device with the same name / model number.
      • The PCI PTS POI program calls these variations in physical materials “Hardware Versions”—each device has a sticker showing what it contains. In addition, these devices have software or “firmware” installed on it (i.e., the operating system or other applications)—only devices whose hardware and firmware version numbers match the listing are actually covered by the PTS POI approval.
    • (In the interest of full disclosure, to be fully P2PE compliant, you also must ensure that any communications using Open Protocols (such as Bluetooth, WiFi, or other network protocols) use the “OP” functionality built into the POI device (that is validated as part of its PTS POI device approval).) 

2. If My Terminals State That Their Software Encrypts Data, Is That P2PE?

 

Maybe? In order for a solution to be a PCI-listed P2PE Solution, card account data must be encrypted by the “SRED firmware,” so you’ll need to verify that before you can be sure.

“Applications” and other software versions that are included in the PTS POI listings are specifically referred to as “firmware” to avoid confusion. So, if your terminal’s documentation states that “software” encrypts the data, then it’s non-P2PE-compliant, as P2PE requires that the encryption be done by the “SRED Firmware.”

3. What’s the Difference Between E2EE and P2PE?

 

If your solution is not listed—meaning it has not been tested and approved—you may be instead using end-to-end encryption (E2EE). E2EE describes any solution that encrypts data from one endpoint to another endpoint, and there are key differences between it and P2PE:

  • The Difference in Method: A P2PE solution sends encrypted data from a POI device to a decryption environment before being sent on to the acquirer. E2EE can perform similarly but this is not always defined and is not formally reviewed against security controls to include the environment that decrypts the card data.
  • The Difference in Scope (especially if the E2EE solution does not use SRED): The nature of a PCI-listed P2PE Solution is that the use of SRED not only ensures that cardholder data (CHD) is encrypted, but also that the secure environment inside the device used to store the encryption keys, read the card data, and encrypt it using the SRED firmware is logically isolated from the general purpose/communications processing environment in the device.
  • The Difference in Security Rules: The validation process for a P2PE solution includes the specific details of terminals, the encryption used, the strength of the encryption, the process to get keys onto terminals, the environment where encrypted CHD is decrypted for processing, and many other parts. The third party reviewing the P2PE Solution needs to be qualified personnel who are specifically trained and knowledgeable in encryption. An E2EE offering does not need to be reviewed by anyone.
    • Only a merchant using terminals that are a part of a P2PE solution is eligible to complete the SAQ P2PE to satisfy compliance requirements. Note: Some acquirers offer terminals using E2EE for their merchants and permit the merchants to complete an SAQ P2PE to demonstrate merchant compliance. This depends upon that acquirer but other considerations are key here, see this FAQ from the PCI SSC.
  • The Differences in Key Management: PCI-listed P2PE Solutions ensure that no one—including the merchant—actually has access to the encryption keys. That cannot be said of any other solution.

4. P2PE Solution Provider vs. P2PE Component Provider: What are These?

 

  • A P2PE Solution provider is a vendor that maintains, designs, implements, and manages a P2PE solution. They are ultimately responsible for this encryption process.
  • A P2PE Component provider is an organization that provides one or more of the services that support a P2PE Solution. Available Component listings include:
    • Encryption Management Services (EMS)
      • Encryption Management Component Provider (EMCP)
      • POI Deployment Component Provider (PDCP)
      • POI Management Component Provider (PMCP)
    • Decryption Management Services (DMS)
      • Decryption Management Component Provider (DMCP)
    • Key Management Services (KMS)
      • Key Injection Facility (KIF)
      • Key Management Component Provider (KMCP)
      • Key Loading Component Provider (KLCP)
      • Certification Authority/Registration Authority (CA/RA)

Whether you provide one or the other—or both, as that’s possible as well—Components and Solutions will all need to be formally assessed, either as part of a P2PE Solution assessment, or previously assessed and listed as part of a P2PE Component assessment.

5. What is a P2PE Application?

 

Short answer? Any additional software that is installed on a POI device that has access to clear-text cardholder data. (NOTE: P2PE Applications do not and are not allowed to do the encryption).

  • Not all POI devices require additional applications beyond the firmware that is already installed on them, but the P2PE standard accounts for these additions if they are included.
  • P2PE Applications are created and sold by vendors to support additional functionality that goes beyond what is included with the POI device firmware—e., beyond the intake of card data to facilitate a transaction. For example, a P2PE Application can be installed to support loyalty card programs as part of the larger solution.
  • P2PE Applications need to be reviewed by a P2PE Application Assessor who will provide a P2PE Application Report on Validation that, upon completed review by the PCI SSC, will result in the software being listed* as an approved P2PE Application on their website.

An important note on P2PE Applications:

  • If you use a P2PE Application that is used solely within your solution, it will be assessed as a part of the solution and it will receive that P2PE Application Report, but it will not be listed by the PCI SSC.
  • That distinction matters because an application not listed by the PCI SSC cannot be used within other Solutions. To be able to market a P2PE Application for use by others, it must be assessed and then listed.

* Not all P2PE Applications get their own listing. If the developer wants to sell it for use by multiple Solutions, then it would be listed. But those only intended for use with one Solution would merely appear in that Solution’s listing details section.

6. Do Parts of a P2PE Solution Need to Be Assessed Against the PCI DSS?

 

Yes. Because the decryption environment receives encrypted data from P2PE devices taking card data and then decrypts that data for processing, the environment will have access to clear-text card data. As the PCI DSS applies to systems that store, process, transmit, or can impact the security of cardholder data, the decryption environment must be secured and assessed against the PCI DSS. 

7. Does a P2PE Application Have Access to Clear-Text Cardholder Data?

 

Yes. A P2PE Application is one that has access to clear-text CHD on a POI device that is part of a P2PE Solution in order to accomplish something such as implementing whitelisting functionality for non-PCI payment brand cards.

Need More Information on P2PE?

 

P2PE may be very specialized, but with a solid method of data protection, it bears a look from anyone involved in the market. Its complexities may appear daunting, but at least now you have a good grasp of the basics as you delve deeper into whether it’s right for your payment security as a merchant—or, if it’s a market you’d like to get into as a provider.

To get even more well-versed on the topic, read our articles so that if you choose to equip this tool, you’ll understand how it all works with compliance:

About Sully Perella

Sully Perella is a Senior Manager at Schellman who leads the PIN and P2PE service lines. His focus also includes the Software Security Framework and 3-Domain Secure services. Having previously served as a networking, switching, computer systems, and cryptological operations technician in the Air Force, Sully now maintains multiple certifications within the payments space. Active within the payments community, he helps draft new payments standards and speaks globally on payment security.