Point-to-Point Encryption (P2PE): How It Cuts Your PCI Scope

Point-to-point encryption (P2PE) encrypts card data inside a secure payment terminal at the moment the card is read. The data is decrypted only in the solution provider's protected environment, so your point-of-sale systems and network never see cleartext card data, and you never hold the keys. With a PCI-listed P2PE solution, followed as the provider instructs, most of your card-present environment drops out of PCI DSS scope. Eligible merchants can then validate with SAQ P2PE, which has 21 requirements in its PCI DSS v4.0 version.

That's a big reduction, but it comes with conditions. Here's what P2PE covers, what stays with you, and where the benefit is easiest to lose.

What is point-to-point encryption?

P2PE is a PCI Security Standards Council (PCI SSC) standard and validation program for encryption solutions used at the point of sale. A validated solution brings together several elements:

• Approved payment terminals. Point-of-interaction (POI) devices approved under the PCI PIN Transaction Security (PTS) program, which encrypt account data as soon as it's captured.
• Secure key management. Keys are generated and injected into devices under tightly controlled conditions, and the merchant never has access to them.
• A secure decryption environment. Decryption happens only at the solution provider, in an environment assessed against the P2PE standard.
• Device management. Controlled processes for shipping, deploying, tracking and retiring terminals.

Each solution is assessed by a P2PE Qualified Security Assessor and, once validated, appears on the PCI SSC's list of P2PE solutions. The current version of the standard is P2PE v3.1, published in September 2021.

How does P2PE reduce PCI scope?

PCI DSS scope follows cardholder data. If a system can't see cleartext card data and can't decrypt it, there's much less for an attacker to take from it and much less for PCI DSS to cover.

With a PCI-listed solution, the terminal is the only place in your environment where account data exists in a usable form, and it's encrypted before it leaves the device. The register, the store network, the back-office server and the connection to your processor carry only data you can't decrypt. That's why those systems can fall out of scope for that payment channel.

What remains in scope is narrow: the terminals themselves, any paper records containing card data, and the policies and processes that support them.

What is SAQ P2PE and who qualifies?

SAQ P2PE is the self-assessment questionnaire for merchants whose card-present payments run entirely through a PCI-listed P2PE solution. The PCI DSS v4.0 version of SAQ P2PE, published in April 2022, sets out these eligibility criteria for the payment channel:

• 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 that solution.
• The merchant doesn't otherwise receive, transmit or store account data electronically.
• Any account data the merchant retains is on paper, such as printed reports or receipts, and isn't received electronically.
• The merchant has implemented all controls in the P2PE Instruction Manual (PIM) from the solution provider.

If you meet them, the v4.0 SAQ P2PE covers 21 requirements:

PCI DSS v3.2.1 remains active until March 31, 2024, so merchants can still validate using the v3.2.1 version of the SAQ for now. Planning the switch to the v4.0 version this year avoids a scramble later.

Larger merchants that validate with a Report on Compliance don't use SAQs, but P2PE still reduces what that assessment has to cover. Your acquirer decides which validation route applies to you.

What is the P2PE Instruction Manual (PIM)?

The PIM is the document your solution provider gives you that explains how to run the solution securely. Implementing everything in it is a condition of SAQ P2PE eligibility, so treat it as part of your compliance evidence rather than a setup guide you read once.

A PIM typically tells you:

• Which terminal models and applications are approved for the solution.
• How to receive, verify and install devices.
• How to physically protect and inspect devices.
• What to do if you suspect tampering or an encryption failure.
• How to return, repair or retire devices.
• How to contact the provider for support and incident reporting.

Keep the current version where store managers and IT staff can find it. When the provider updates it, review what's changed and update your procedures to match.

Why don't non-listed encryption solutions get the same scope reduction?

Many providers sell encryption at the terminal under labels like "end-to-end encryption." Some are well engineered. But unless the solution has been validated against the P2PE standard and appears on the PCI SSC list, it doesn't make you eligible for SAQ P2PE.

With a non-listed solution, any scope reduction is up to your acquirer or the payment brands, usually with input from your assessor. The PCI SSC has published guidance to help assessors evaluate non-listed solutions consistently, and some providers commission a P2PE assessor's review of their solution against the standard. The Council has been clear that this kind of review isn't a validation and doesn't lead to a PCI listing.

If you're using or considering a non-listed solution, ask your provider:

• Is the solution validated and listed by the PCI SSC? If not, is that planned?
• Who manages the keys, and where does decryption happen?
• What independent assessment evidence can you share?
• What has our acquirer said about scope for merchants using it?

Then confirm the answer with your acquirer before you pick an SAQ.

How should you handle and inspect P2PE devices?

Once card data is encrypted at the terminal, the terminal itself is where the security of the channel is decided. A tampered or substituted device undermines everything the solution is built on. That's why device handling features so heavily in both the PIM and SAQ P2PE.

Keep an accurate inventory

Requirement 9.5.1.1 calls for an up-to-date list of POI devices, including make, model, location and serial number or another unique identifier. Reconcile it against what's actually on the counter. A device that isn't on the list, or one missing from its expected location, is a problem to investigate.

Receive and install devices carefully

Follow the PIM for accepting shipments. Check that serial numbers match what the provider sent, packaging hasn't been tampered with, and only authorized staff install or move devices. Requirement 9.5.1.3 expects procedures that stop devices being installed, replaced or returned without verification.

Inspect devices regularly

Requirement 9.5.1.2 requires periodic inspection of device surfaces to detect tampering and unauthorized substitution. A useful inspection checks:

• Serial numbers and security labels against the inventory.
• Seals, screws and casing for signs of opening or damage.
• The card reader slot and keypad for overlays or anything attached.
• Cables and connections for unexpected devices in between.
• The device's overall appearance against reference photos or a known-good unit.

The PIM should tell you what to look for on your specific models. Under the full PCI DSS v4.0 standard, a new Requirement 9.5.1.2.1 will expect the inspection frequency to be based on a targeted risk analysis. It's a best practice until March 31, 2025.

Train the people who use them

Requirement 9.5.1.3 also covers training. Staff who work with terminals should know how devices are supposed to look, the procedures for installing or swapping them, and how to report signs of tampering. If they suspect a problem, they should stop using the device and follow the PIM's escalation steps.

What stays your responsibility with P2PE?

P2PE reduces scope. It doesn't hand your compliance to the provider. You still need to:

• Protect and securely dispose of any paper records containing card data.
• Maintain security policies and run security awareness for relevant staff.
• Manage your service providers, including keeping a list, having written agreements, monitoring their compliance status and knowing which requirements each one covers.
• Have an incident response plan that covers your payment environment.
• Keep card data out of other paths. Keying card numbers into a PC-based virtual terminal, or accepting card details by email, sits outside the P2PE solution and can break SAQ P2PE eligibility.

That last point deserves the most attention. A single workaround process can bring a whole network back into scope.

Frequently asked questions

Does P2PE make us PCI compliant automatically?

No. It reduces scope and the number of requirements that apply, but you still have to meet those requirements and validate compliance each year in the way your acquirer requires.

Can we use SAQ P2PE if we also take online payments?

SAQ P2PE covers the channel that runs through the P2PE solution. Other channels, such as e-commerce, need their own assessment. Check with your acquirer how they want multiple channels reported.

Is EMV chip the same as P2PE?

No. EMV chip technology protects the transaction by authenticating the card. It doesn't encrypt the card data as it moves through your systems. P2PE does, which is why it has a much larger effect on scope.

What if our terminal model isn't listed in our P2PE solution?

Then it isn't part of the validated solution. Only the devices and applications listed for the solution qualify, so check the listing and the PIM before buying or deploying new hardware.

Next steps

• Confirm your solution appears on the PCI SSC list of validated P2PE solutions and that every deployed terminal model is included.
• Get the current PIM, and map each instruction to an owner and a documented procedure.
• Build or reconcile your device inventory, then set an inspection schedule and checklist.
• Train store and support staff on device handling and tamper reporting.
• Hunt down any card data paths that bypass the P2PE solution and close them.
• Plan your move to the v4.0 version of SAQ P2PE before v3.2.1 retires on March 31, 2024.