Point-to-point encryption (P2PE) is a technology that promises to reduce a merchant's PCI scope significantly. Ideally, with an approved P2PE product, a merchant's only PCI scope will be the point-of-interaction (POI) device itself. But do merchants really need to wait for a P2PE-approved package to get the benefits?
The answer to that question, in some cases, might be: "No." Instead, based on the PCI Security Standards Council's revised guidance on when encrypted cardholder data may be considered out of scope, I have to wonder if it might be possible that existing vendor offerings could potentially bring some merchants the same benefits with less work and without waiting—and paying—for the first P2PE products to hit the market. Achieving this scope reduction won't be easy, and I don't have all the answers. However, I do have some questions that are worth considering.
Before merchants conclude that any product is for them, they need to address several issues.
Let's start with the encrypted data. The PCI Council clarified a long-standing frequently asked question (FAQ) response that addressed the conditions under which encrypted cardholder data may be considered out of PCI scope. That FAQ (number 10359) stated encrypted cardholder data was always in the merchant's or service provider's scope unless that merchant or service provider did not have the means to decrypt the data.
The PCI Council revised that FAQ in August, with many merchants and assessors seeing the new one for the first time at the recent PCI Community Meeting. (Yet another reason, if you are reading this column, you should become a Participating Organization and attend the annual PCI "Woodstock.") The revised FAQ still states that encrypted cardholder data is in scope with the following exception: "It is possible that encrypted data may be deemed out of scope for a particular entity if and only if [PCI Council's emphasis] it is validated that the entity in possession of the encrypted data does not have the ability to decrypt it."
The revised FAQ goes on to specify the three conditions that must now be met to conclude that the data is out of scope. The conditions are: The encrypted cardholder data must not be stored on the same system or media as the decryption key; the encrypted data must not be in the same environment as the decryption key; and the merchant must have no ability to access the decryption key. It is this third condition that is the most important.
On a side note, I noticed the new FAQ removes the requirement that the service provider managing the encrypted data must be PCI DSS compliant. The original FAQ declared that "service providers or vendors that provide encryption (products) to merchants who have administrative access and controls to Keys along with the management of termination points for encryption to process transactions, are required to demonstrate physical and logical controls to protect cryptographic keys in accordance with industry best practices (such as NIST referenced in PCI DSS requirement 3.6), along with full compliance with PCI DSS." The original FAQ reinforced this requirement in the next sentence: "Merchants should ensure their providers who provide key management services and/or act as the point of encryption/decryption are in compliance with PCI DSS." Speaking as a QSA, I must remind everyone that just because that requirement is no longer spelled out in the revised FAQ, merchants must not assume they do not need the same due diligence as before to confirm their encryption implementation will remove the data from scope.
The clarification is good news for merchants and assessors alike. It bases the scoping decision on who can access the decryption key and under what circumstances. The key word here is access.
Every Internal Security Assessor (ISA) and QSA knows to consider the intent, as well as the letter, of all PCI DSS requirements. To this QSA, the phrase "no ability to access" means exactly what it says. Therefore, to consider encrypted cardholder data out of scope, the merchant must never—and I mean never—be able to gain either possession of the decryption keys or access to the decryption environment.
For example, if the decryption key is in the merchant's datacenter, the data is in scope. If a third party manages the process and the encryption environment (hardware or software), but it is in the merchant's datacenter or the merchant can access that environment remotely, the data is in scope. And if the whole encryption process is outsourced but the vendor contract gives the merchant access to the decryption key in specified circumstances (e.g., if the vendor goes out of business), I would still assess the data to be in the merchant's scope.Let me be clear. A package that permits merchant access to the decryption key may very well be PCI compliant. My point is that the data is in scope if there is any circumstance whereby the merchant can gain access to the ability to decrypt the data. Therefore, an ISA or QSA must to look at the details of any contract or service-level agreement, which may be the most important element in determining whether the encrypted data is assessed to be in scope.
Yes, I know I might be a hard grader, but that is what I believe the PCI Council intended when it clarified the FAQ. As I started to explore the implications of this process, I wondered if this clarification could open the door for merchants, service providers and acquirers to get encrypted data out of scope without a P2PE-approved approach in some cases.
The P2PE requirements are extensive, and meeting them requires a significant investment by POI device manufacturers, software developers and the technology providers. For example, version 1.1 of the P2PE Program Guide runs to 210 pages, including six domains and detailed specifications for both product providers and merchants. The sales pitch for the merchant is significantly reducing their PCI scope, together with a new, shortened Self-Assessment Questionnaire (SAQ P2PE-HW).
But what happens to this sales pitch when the merchant can achieve virtually the same scope reduction with less work using an encryption product already on the market?
Merchants already can choose from a variety of encrypting card readers, some of which are offered by their acquirer. If the vendor implements these devices securely, and if the merchant performs appropriate due diligence on the software and the implementation (Note: this due diligence is critical!), the acquirer and the merchant's QSA may agree that the package reduces the merchant's PCI scope, perhaps as effectively as a P2PE-approved approach. That is, the encrypted data traversing the merchant's network and systems could be deemed out of PCI scope based on good research and a solid service-level agreement.
This approach will not work for all merchants—e.g., those using mobile devices or E-Commerce merchants. It could work, though, for many retailers and their card-present environments.
I do not want to underestimate one big advantage of a P2PE-approved approach: The PCI Council (and a P2PE QSA) has already performed the due diligence. I want to call everyone's attention the value of a P2PE label, because encryption and key management are complicated topics that call for a level of expertise most merchants do not have. As I noted above, even with a P2PE-approved approach, merchants still need to perform a host of actions. But they will be certain they have reduced their PCI scope effectively. Nevertheless, the question for merchants will be whether the additional cost of a P2PE approach (including implementation and maintenance of the approved software) delivers greater benefit than an encryption package already in the market.
Naturally, there are questions and some uncertainties. For example, the PCI Council just revised the FAQ addressing when encrypted cardholder data may be deemed out of scope. Could it go back and revise that FAQ again? Yes. Could the Council revise the FAQ to say that encrypted data is out of scope only with certain POI devices or only as part of a P2PE-approved approach? Yes, again, in both cases. Therefore, basing your scoping plans on a current FAQ entails a certain risk.
A wild card in this mix is the acquirer. An acquirer could tell a merchant it can reduce its PCI scope if it uses the acquirer's encrypting POS device. Some acquirers may be willing to take that risk. Based on my experience at several merchants, some acquirers already are making the case that their proprietary encrypting card readers reduce a merchant's scope. An acquirer could take this position not just to reduce risk but to build merchant loyalty.
Could we have the Law of Unintended Consequences (which holds that no good act, such as clarifying the FAQ, goes unpunished) at work with the revised FAQ? That is, by clarifying and tightening the guidelines for when encrypted data is out of scope, might the PCI Council have inadvertently provided an alternative that will reduce merchants' demand for P2PE-approved packages?
We will know more when the first P2PE applications are approved and merchants see the price tag (including internal resources for implementation). Until then, I'd like to hear what you think. Has your organization looked at either encrypting card readers or P2PE approaches? Did a sales person describe his or her company's encrypting POS device as "point-to-point" or "end-to-end" encryption? Either leave a comment or E-mail me.