PCI Compliance and P2P or E2E Encryption Solutions Risk

There’s a difference between the terms “end-to-end encryption” and “point-to-point encryption” in the world of PCI compliance standards.

But what is it? In a point-to-point encryption solution, the solution has been validated to demonstrate that the entire lifecycle, from the PTS (pin transaction security) devices to the processing of a transaction, are secure. It’s a lengthy and very costly assessment. The net result is that the PTS device encrypts the cardholder data at the exact point it’s swiped – the merchant has no ability to decrypt the data. Only the processor can decrypt the data. Thus it removes about 95% of the controls required to protect the data because, i.e. even if the network was compromised, all they would get is encrypted CHD, which they couldn’t decrypt anyway.

If you would like to have a look at the remaining controls that this type of deployment leaves, read this.

Rolling a point-to-point encryption solution automatically entitles you to a reprieve of numerous controls, but it has to have been assessed under that standard and listed as such on the Council’s website. See below.
PCI Council approved P2PE Solutions.

Processors in the industry started selling a solution that provides encryption but has not been validated under the point to point assessment (p2pe) generally because of the costs involved. However, because there had not been an assessment done against that solution, there was a lot of confusion in the industry about what reprieve, if any, was warranted. So what was settled on was an assessment of just the merchant-facing technologies and a recommendation for a reduced scope. This assessment is documented in a document called a NESA (non-listed encryption solution assessment). You can read a little about the document and processes in this blog.

However, the reprieve of controls are just a recommendation. In the merchant world it is still up to the acquiring bank to agree to any reprieve of controls, even though the solution implemented may have a NESA associated with it. If you are using a NESA solution, it is imperative that you receive, in writing, clearance from the acquiring bank that the NESA solution being utilized is acceptable to them.

Lastly, if you have implemented an encryption solution, and it has neither a NESA or a P2PE assessment associated with it, it’s unlikely that you will qualify (or your bank would agree to) any reprieve of controls. But once again, it is up to your acquiring bank.

Wrapping it all up

If the solution you’ve implemented is a p2pe validated solution…

You would not have to implement FIM or a SEIM and you are relieved of most, but not all, of your PCI compliance controls.

If the solution you’ve implemented is an E2EE solution, which has an associated NESA…

We would caution you in making that decision not to implement FIM/SIM without first consulting with their acquiring bank. Chances are they’ll be fine with it, but you’ll still need to validate that the bank will accept the reprieve in the first place. If the acquiring bank approves of the NESA, then you are relieved of most, but not all, of your PCI compliance controls.

If the solution you have implemented is a E2EE solution, without an associated NESA…

You’ll need to implement all applicable PCI controls, however, you can always plead your case to your acquiring bank and see if they will accept you reducing your PCI compliance controls with the E2EE solution. This is something that you will want to do prior to suffering a breach.

Was that a lot of information? Probably. If the thought of figuring out any of your PCI compliance seems daunting, we’re here to help. Contact Logic Shield today for a free demo of our fully-managed, transparent security solution.

Wrapping it all up

Related Posts