I have been encountering a lot of organizations that are confused about the difference between the PCI SSC’s point-to-point encryption (P2PE) certified solutions and end-to-end encryption (E2EE). This is understandable as even those in the PCI community are confused as well.
E2EE is the generic terminology used by the IT industry to describe any solution that encrypts communications from one endpoint to another endpoint. Key management of the encryption can be done by any party that has an endpoint such as a merchant or a service provider. Examples of E2EE include IPSec, SSL and TLS.
One of the most common E2EE solutions used by merchants is derived unique key per transaction (DUKPT) also known as “duck putt”. DUKPT is commonly used in the convenience store and gas station industries to encrypt sensitive authentication data (SAD) from the gas pump to the merchant or processor. DUKPT uses the 56-bit data encryption standard (DES) encryption or triple DES (3DES) algorithms. While DES and 3DES 56-bit and 112-bit are no longer considered secure, because DUKPT uses a unique key for every transaction, it means that every transaction has to be individually broken to gain access to the data. While using the cloud could be leveraged to perform this rapidly, it would be too costly an effort for the data retrieved. As a result, DUKPT is still considered a secure method of encryption.
P2PE is a subset of E2EE. This is because the major difference between P2PE and E2EE is that P2PE does not allow the merchant to be a manager of the encryption keys. Under the P2PE standard, only the transaction processor or other third party is allowed to perform key management. The merchant is never allowed to perform encryption key management under the P2PE standard. As a result, DUKPT can be used by both P2PE and E2EE solutions. However, under P2PE, the key management must be done by a third party, not the merchant.
While third party key management is typically acceptable for small merchants, this does not work for merchants that switch their own transactions to various processors as do mid-sized and large merchants. That does not mean that E2EE solutions are not acceptable for reducing PCI scope. As with PA-DSS certified applications, P2PE certified solutions can be accepted by a QSA as long as they are implemented according to the P2PE implementation guide which can reduce the amount of testing a QSA is required to perform. In my experience, P2PE versus E2EE testing efforts are typically negligible, so any so-called savings are limited at best.
The huge downside to P2PE for merchants is that once you decide on a given P2PE solution, you are pretty much stuck with it and the processor providing it. That is because most processors offering P2PE are only offering one P2PE solution. As a result, if a better deal comes along for processing your transactions, you will likely have to replace your terminals and possibly other equipment to switch to the new processor. For some merchants, that could be a costly proposition and make any switch not worth the effort.
So if your organization is looking at P2PE versus E2EE, I would not necessarily give an advantage to P2PE over E2EE. Just because an E2EE solution is not P2PE certified does not mean it is not secure. It only means that the vendor did not believe that the P2PE certification was worth the effort.
PCI Guru 
I wonder about UPT (Unattended payment terminal) and P2PE (Point2Point Encryption). If one would use a solution that is both UPT and P2PE certified, I suspect that most parts of the SAQ P2PE can be answered with either N/A or CCW. (CCW could be that the device’s own tamper-resistance is sufficently strong to compensate for the lack of employees monitoring the payment terminal past start of day).
That would mean employees would also not need to receive any training except for identifying tampering, and a very simple security policy could be in place, that any service requests by vendor is to be handled by manager only (so employees does not need to receive any training on identifying service personell, instead a “reject all” policy is enforced), only manager has key to UPT CAB, and if any tampering is spotted on start of day, the employee could simply be asked to put the terminal out of service (with a special fob that would only disable the terminal, it can never enable it) until manager has a look on it. (which means that incident response personell = the manager, does not need to be available/reachable 24/7 as otherwise required by the SAQ, as a compensating control is that any damage that can be arised of lack of 24/7 incident response resulting in prolonged exposure to a attached skimmer, can be relieved by locking the tampered payment terminal – with the fob – so it displays “OUT OF ORDER” until manager has a look on it)
Thus combining the security of UPT with P2PE, results in the lowest PCI DSS scope ever possible right?
While I agree with your logic, you would still have to convince your acquiring bank that the risk is low based on the security measures you cite. They may want additional testing performed to confirm those security features, but once that was done I would like to believe that they would sign off on reduced scope. But there are no guarantees.
Does an application on a tablet, using a SCRA device (for example an iDynamo on an ipad) with a qualified P2PE provider (other than the one already qualified under PA-DSS) still require a PA-DSS Qualified assessor to review the application or can it be done with an ISA as part of a normal PCI DSS assessment.
The Council will tell you that there is no way that an application on a tablet can comply with the requirements in the PA-DSS.
That said, use of a tablet (or any mobile device) is not allowed by the card brands as they require that the mobile device be PTS validated when used as a point of interaction (POI). See Visa’s and MasterCard’s Web sites for their specific POI compliance requirements. This is the problem right now with mobile POI in that the card brands do not endorse their use as a POI.
I have two questions as we are level 2 and have two types of POS systems in our each stores.
1. One type of POS uses SecureMag CC swipes (encrypted solution, from PCI PTS certified IDTech) integrated into/with NEtePay / dsiPDCX (from PA-DSS certified DataCap). So, is this POS system out of scope?
If positive, I will be very surprised that this solution is much easier that P2PE. (Be noted – both IDTech and DataCap are NOT PCI certified P2PE providers.)
2. Another type POS is Micros POS system with other app running on the POS terminals. So we have to go SAQ-D. I just have a weird question, if in case the first type falls into P2PE category, do I have submit both SAQ-P2PE and SAQ-D ? (This still could be a real question for someone do having this issue.)
Thanks.
In your first example, you have an end-to-end encryption (E2EE) solution. While not P2PE, you can leverage it to reduce scope to P2PE. To do that, you must document that you have implemented it to the E2EE vendor’s implementation guide, you must document that it encrypts at the swipe/dip with data captures, if the terminals connect to the POS, you need to document that the POS never has access to the cardhodler data (CHD) or sensitive authentication data (SAD). All this evidence must be submitted to your acquiring bank and your acquiring bank must formally grant you the ability to use only those requirements in SAQ P2PE-HW (if you need to do any other SAQ or a ROC, you use the SAQ P2PE-HW as a guide to those requirements that are relevant for testing).
With two POS solutions, you would only submit one SAQ and that would be an SAQ D.
Along the lines of previous questions related to P2PE and scope reduction, does the PCI SSC consider an encrypted PAN (encrypted within a secure payment terminal) in which the merchant does not have keys to decrypt to be CHD or not to be CHD? If not, and after sufficient proof through inspection and validation, can a merchant’s retail store environment’s CDE be reduced to the payment terminal alone? Once the PAN is transformed into an Encrypted PAN through a validated in-terminal P2PE solution I’m hearing from some merchants that the Encrypted PAN is no longer in scope and therefore it can be transmitted, processed, and stored without regard to PCI requirements. The merchant’s own data security policies still apply of course. My concern is that other CHD typically accompanies the Encrypted PAN such as the expiration date and cardholder name. Plus a database of Encrypted PANs, even without decryption keys, could still be vulnerable to an encryption algorithm attack. How are QSA’s advising merchants about the security of their cardholder data post P2PE implementations?
The scenario you describe would be considered end-to-end encryption (E2EE). As such you are required to validate that the point of interaction (POI) also known as a card terminal or wedge is in fact encrypting the sensitive authentication data (SAD) or cardholder data (CHD) upon swipe/dip/entry into the POI. Once that has been validated, then you need to go to your acquiring bank and provide them with your evidence and get their approval on your scope reduction. Once you have that approval for scope reduction, you can then assess your environment to that reduced scope.
In regards to P2PE, the assessment is handled similar to a PA-DSS application assessment. The implementation of the P2PE validated solution must be assessed to ensure it was implemented exactly as specified in the vendor’s P2PE Implementation Guide. Once that is proven, then a merchant can reduce their scope based on the P2PE implementation.
Thanks for the response. Assuming a P2PE solution is accepted by the QSA and acquirer, for tier-1 merchants that then retain the Encrypted PAN for other purposes (e.g. tokenization exception scenarios, loss prevention analysis, tender analytics, etc) what recommendations should be considered for the continued storage of Encrypted PAN and other associated cardholder data? For example, would it be a good practice to only store from this point on a truncated PAN (first six, last four)?
Your question is drifting into P2PE v2 territory as under P2PE v1, the merchant had no way to keep any part of the PAN because they had no access to the PAN with P2PE v1 solutions.
Under P2PE v2, there is a modular approach to P2PE solutions. So the answer to your question would depend on which modules you were using. That said, the most common situation is going to be where the merchant is doing their own transaction switching. The transaction switch would be the application that would be the P2PE endpoint rather than a transaction processor. As a result, the transaction switching software would have access to the PAN and would be the encryption point for the PAN for storage if it is being stored. This situation would be no different than any other situation where the PAN is stored encrypted.
As to loss prevention, analytics and other situations, I have always recommended the use of a hashing algorithm with a SALT that will result in consistent value for each individual PAN when it is hashed. That way such analytics can be performed on the hashed value without any concern for accidentally disclosing a PAN. If the actual PAN is needed, you would have transaction date/time and transaction number to go back to the transaction switch application to get the PAN with management approval.
In regards to your response below, yes I’m talking about a P2PE v2 solution in which the processor is providing the P2PE solution. The keys are injected into the PED and after the customer swipes/dips/taps their bankcard all the merchant gets is an Encrypted PAN (and after the authorization the merchant gets a Payment Token as well). In this case there is no internal payment switch nor decryption in the merchant environment at all. So can the merchant treat the Encrypted PAN as non CHD and do with it as they please or are there some best practices for Encrypted PANs that linger in a merchant’s environment after the authorization?
Interesting solution as all the P2PE solutions I have ever encountered encrypt the entire data stream to the processor, not just certain fields. As a result, the merchant would be hard pressed to find just the PAN in that data stream. The only option the merchant has is to get the token, last four of the PAN, etc. back from the processor after the completion of the transaction.
Hi PCI Guru, thanks for your informative posts and replies to comments, which leads to my post below.
I am new to PCI and Data Security and trying to get up to speed as to identify the benefits of putting an E2EE vs P2PE solution for a Tier 1 US merchant that manages it’s own payment switch to acquirers.
With PCI P2PE v2 out, my understanding is that they have introduced Domain 4: Merchant Managed Solution.. and my questions are:
In the scenario where you internally host your HSM and manage the encryption keys, does this still result in an E2EE solution? therefore negating benefits of a P2PE solution, such as being able to classify data as ‘non-card data’ at site.
If yes, then in attempting to gain the benefits of becoming a P2PE solution, if we were to continue to host the HSM but negotiate for a 3rd party to manage the keys, would this result in being able to become a P2PE solution?
As far as I am aware, the Council has not yet approved of a Domain 4 P2PE solution. As a result, you would be unable to implement such a solution, therefore all you have left is E2EE.
The only benefit of P2PE is that you get to rely on the P2PE implementation guide and must assess that you followed that guide to the letter. With E2EE, you must also assess that the POI or endpoint is truly encrypting at the swipe/dip, your key management procedures are effective (should be if you have implemented your HSM properly) and you get approval from your acquiring bank for the scope reduction for E2EE (i.e., you share your documentation and evidence with the bank and get formal approval from them).
Unless your HSM implementation is garbage (which I seriously doubt, but stranger things have happened), I don’t see the benefit for outsourcing your key management as most HSMs do key management very securely.
For level 1 merchants requiring a RoC, and assuming that the acceptance channel using P2PE is the only acceptance channel, the reduction in the CDE and the related connected systems can be significant, especially for a retailer with a high volume of stores/endpoints.
Can a PCI QSA justify a reduction in scope for a merchant using a non-validated P2PE solution that is provided by the merchant’s processor? What do you test and/or document in order to justify the use of that solution to reduce scope? Has the release of P2PE v2 changed your perspective on this?
Funny you should bring this up as I was just discussing this very situation today. A non-P2PE solution (i.e., end-to-end encryption or E2EE) can be assessed similar to a P2PE solution. However, unlike the P2PE solution, you need to be able to prove that the E2EE solution is encrypting from the swipe/dip to the processor (Wireshark captures of network traffic). You need to assess that the E2EE solution was implemented per the Implementation Guide (IG) supplied by the vendor (in your case, your processor). You need to prove that your organization does not have the ability to decrypt the datastream, i.e., your organization does not manage the encryption keys.
In the event that you are managing the encryption keys (typical in large merchants), then you would have to meet all of the requirements in 3.5 and 3.6 and prove that you have proper key management in place and that the datastream cannot be decrypted between the POI and your transaction processing endpoint (typically a transaction processing switch such as ACI).
Finally, you need to present all of this evidence to your acquiring bank and get them to formally approve your reduction in scope based on the evidence presented. If they do not approve, then you do not get scope reduction due to E2EE.
Hi! I don’t even know if this is still an active blog, but I have a question that no one can seem to answer for me.. After the EMV shift, merchants will still be required to be PCI Compliant, which means running quarterly “scans” on their systems. However, IF their POS system (for example NCR Silver) is P2P Encrypted, scans will not be necessary.. Or well, that’s my question – will ASV scans be necessary after the “shift” if they have a P2P Encrypted POS System?
Thank you!
Yes, they will still have to be vulnerability scanned and penetration tested. The reason is that a POS with an integrated swipe/dip is still in scope as it is the endpoint that comes into contact with the card (magnetic stripe or EMV). This is also true for card terminals as well as they are also an endpoint. Point-to-point encryption (P2PE) just takes everything but the terminal and the processing endpoint out of scope, but it does not remove the terminal endpoint at the merchant from scope.
That said, card terminals (aka POI or point of interaction) such as those from Verifone and Ingenico, while they need to be scanned and penetration tested, getting them patched will be challenging given past history. POI vendors have been notorious for not patching card terminals. There is a tendency for those vendors to move on to new models and leave the old models “as is”. We shall see if this practice continues.
I would like to hear your opinion on our company’s PCI compliance strategy. We supply billing/accounting software that includes e-payment solutions to a large number of electric utilities and telecoms in the US. We are in the process of implementing the following and would like to know what SAQ would apply and what hardware would be in scope for our merchant utilities:
*Using VeriFone MX925 card terminals with First Data’s TransArmor E2EE solution.
*VeriFone terminals are connected to the corporate LAN, and our Cash Register software communicates to the VeriFone unit by IP address on the same corporate LAN.
*Our Cash Register software only “sees” the encrypted value of the PAN, and displays only the last 4 digits that remain the same as the original card number.
*Our Cash Register software communicates to the Payment Gateway with the encrypted value, which First Data then decrypts and authorizes.
*Our Cash Register software is part of our Billing/CIS suite, which is not PCI compliant (nor ever will be) due to various reason in how we support our clients (ie. Our vendor common login, VPN tunnel up 100% of the time, etc). We need to keep our software out of PCI scope for this reason.
So because the VeriFone unit is on the corporate LAN (not network isolated), and has to be to communicate with the Cash Register solution, they cannot qualify for SAQ B, B-IP, or C. So does that mean our merchants would currently complete SAQ D since the solution is not P2PE-HW certified? What would be in scope under SAQ D (ie. can we avoid putting the corporate network and our solutions in scope since we use TransArmor)? I’m concerned about SAQ D due to putting the entire corporate network in scope due to the issues mentioned above.
First and foremost, only an organization’s acquiring bank can officially answer questions such as which self-assessment questionnaire (SAQ) should the organization use or do I need to do a Report On Compliance (ROC)?
In your case, you are a service provider based on your description. Service providers that process under 300,000 transactions can do an SAQ D. 300K and up must do a Report On Compliance (ROC). Since your organization does not appear to process any transactions, you should be assessed under SAQ D. Since your organization provides a payment solution, I hope you have built and certified it to the PA-DSS standard. But that is a different and more complicated discussion. Just because your payment application does not touch cardholder or sensitive authentication data, you still must prove that fact with some sort of official assessment.
That said, I think your question is regarding what SAQ your solution would likely fit for your customers. TransArmor is an E2EE solution as you point out, not P2PE certified. That said, knowing how TransArmor works, I would think that your solution could go under the SAQ B-IP for your customers. However, to do that, your organization is going to need to produce a white paper with a qualified security assessor (QSA) describing how this solution works, how the security works and the rationale for using SAQ B-IP. That way your customers can then approach their acquiring banks with documentation that supports SAQ B-IP.
Thanks for the response. A little more info and another question for you…
We have our own Payment Gateway integrated with our merchant payment solutions, and process well over 6 million card transactions annually so we undergo a level 1 PCI audit and receive a ROC. I intend to discuss our solutions with our auditor, but appreciate getting other opinions from experts like yourself.
I’m curious if SAQ B-IP really qualifies for our configuration (it would be great if so), considering it requires network segmentation. Our Cash Register system, part of our overall solution running on the same server as CIS, accounting, etc, must be connected to the same corporate network as the VeriFone unit. Does this limit us to either SAQ D, or P2PE-HW (if we certify it), or is SAQ B-IP possible since we use TransArmor and if we provide a white paper to our QSA? I’m thinking the connection knocks out B-IP, but wanted to follow up on your comments. It sounds like there is hope for this. Thank you.
Glad to hear that your payment gateway is assessed.
I do not believe that your POS application needs to be PA-DSS certified because of the use of TransArmor and how you describe its functioning. However, it is another question mark that could be easily answered with a white paper developed as the result of a QSA assessment of the application that would confirm the facts of how it operates.
SAQ P2PE-HW is not a possibility because TransArmor is not P2PE certified. Unless things change with P2PE v2 due this month, I seriously doubt that you will get First Data to certify TransArmor as P2PE compliant.
Regarding the use of SAQ B-IP by your customers. This is where things get sticky and QSAs’ opinions will vary all over the place even within QSACs. In my opinion, a case can be made as follows based on where I see the risk. And the risk is with the point of interaction (POI) or card terminal. Even though there is a service on the PC for the POI to communicate back to you, if someone were to tamper with that service (and the tampering actually worked), they still would not have access to any data because of the use of TransArmor. TransArmor also keeps the networks out of scope between the two encryption endpoints. So the risk becomes someone putting software on the POI (not easy but also not impossible) and intercepting the sensitive authentication data (SAD) and PIN at input/swipe/dip before TransArmor gets it. The reason that I see B-IP as the fit is that its work program allows the assessment of all of these facts to prove that only the POI is in scope and that the rest is out of scope.
All of this said, the risk at your end is protecting all of your customers’ POI from some sort of POI malware injection because that is the only way your customers’ POI can be compromised. That of course implies that you require your customers to properly secure and monitor their POI so that they cannot be physically tampered with.
Thanks. This really helps. I will discuss this with our QSA.
Great Article..My understanding is, in P2PE- While a card is swiped card data gets encrypted at POS and gets decrypted at the Acquirer side(the bank which gave POS). Again gets encrypted and is passed to the Network where again encryption and decryption occurs and finally data reaches the issuer.At each point encryption and decryption occurs.
In E2EE: Till the Acquirer side it follows the same process as P2PE and then the encrypted data travels to the issuer via network and data gets decrypted only at the issuer.
Is my understanding correct? If not please provide the correct sequence.
Close, but not quite.
With P2PE, the sensitive authentication data (SAD) is encrypted at the time of entry at the point of interaction (POI) or card terminal and not decrypted until it is received at the transaction processor. P2PE certified solutions are always from the POI to the transaction processor so that only the merchant’s POI is in-scope for PCI compliance.
What you describe with the POS is how Target and Home Depot (among others) got in trouble. The link from the POS to the POI was NOT encrypted as the encryption was performed by a service running on the POS. As a result, the communication link between the POI and the service was in clear text and could be easily retrieved from the memory of the POS.
Unlike P2PE, E2EE does not have to be between the absolute endpoints of the communication link. As such, SSL and IPsec are also E2EE solutions. E2EE solutions that operate similar to P2PE include Verifone’s VeriShield and First Data’s TransArmor solutions.
I have to ask a basic question about E2EE. A representative from my merchant bank is telling me that using their E2EE equipment – which is connected to an un-segmented computer via USB – keeps that computer out of scope for PCI. This information seems to conflict with what I have read in the PCI DSS, the SAQs, and your website.
Can you clarify if you think a E2EE connected to a networked computer keeps that computer out of scope?
This is where E2EE diverges from P2PE.
First off, if you acquiring bank is telling you this, then they are willing to accept the risk regardless of how it works. That is the beauty of the PCI standards. No matter what the PCI standards say, if your acquiring bank will put that statement into writing about this solution, you can use it whether their representations are accurate or not.
That said, I would want to confirm your acquiring bank’s statements before moving forward. Devices such as those from MagTek and IDTech work by using the host PC for network communications. These devices install a driver for the terminal on the PC, but the cardholder data is encrypted, usually using derived unique key per transaction (DUKPT), upon data entry through the device’s keyboard, swipe, dip (EMV) or tap (NFC). As such, the PC never can come into contact with the CHD.
This does not however take the PC totally out of scope though. You should be using a good security hardening standard to build these PCs as well as implement anti-virus/anti-malware and regularly patch them to keep them secure. However, that would be all that you would need to do to those PCs which should be similar to all of your other PCs.
These solutions are usually paired with tokenization or PAN truncation or masking so that any applications never have CHD stored.
Thanks for this article and this site. One statement I want to make is that my understanding is that p2pe encrypt s from the entry point (card swipe) all the way to the processor, removing the Risk of in memory malware. Other solutions encrypt from the pos allow memory scraping Trojan to capture cc data. Also want to mention that I have put together a web discussion/forumn site for qsa to ask/answer questions about how they do things in a non commercial way. The site, http://www.pciqsatalk.com is brand new and I’m still tweeting it, but welcome participation and feedback now.
P2PE can remove the POS memory attack issue, but so can E2EE if implemented in the same way. That said, P2PE and E2EE make the endpoints the targets for compromise. Remember, points or interaction (POI) are just computers like smartphones and still get occasional updates. Those updates could contain malware that could compromise the POI and the data entry of PINs. So, just because you have secured the POS, does not mean you have necessaryily removed all of the risk.
Excellent article. I agree that this is causing a lot of confusion. Isn’t one of the differcnes between P2PE and E2EE that in P2PE the data itself is encrypted whereas in an E2EE solution which as you say could include SSL, IPSec, TLS it may just be the channel that is encrypted. What would you say are the implications for scope if it’s just an encrtpted channel and not the data first encrypted in the card reader and then transmitted over an encrypted channel?
E2EE can be just the same as P2PE and, as you say, just an encryption channel. Verifone’s VeriShield is just such an example. VeriShield encrypts at the swipe/dip/data entry on the point of interaction (POI) or terminal. However, VeriShield is not P2PE certified and, according to Verifone, never will be P2PE certified. AS a result, VeriShield is considered an E2EE solution.
According to the P2PE-HW SAQ (https://www.pcisecuritystandards.org/documents/PCI_SAQ_P2PE-HW_v2.docx), you do not need to do any vulnerability scanning, penetration testing, etc. The only requirements listed are: 3.1, 3.1.1(a-e), 3.2(c), 3.2.2, 3.3, 4.2(b), 9.6, 12.1, 12.1.3, 12.4, 12.5, 12.5.3, 12.6, 12.8, 12.8.1, 12.8.2, 12.9, 12.9.1(a), 12.9.2(b).
For example, requirement 11.3 (penetration testing) is not even present or referenced in the questionnaire.
It’s definitely possible I am missing something here, this is just how I’ve understood it based on my research.
For now, that is true, you do not need to vulnerability scan or penetration test. However, the minute one of these devices is compromised, that will immediately change. This is one of the short sided ideas from the Council that some of us do not agree. These P2PE terminals are just as powerful as a smartphone and they believe, because the device is P2PE certified, that it is somehow more invincible than a non-P2PE certified device. I don’t buy it. While I do not think you need to vulnerability scan it quarterly, I would at least scan it when it gets a software/firmware update. Penetration testing could be done by the vendor on software/firmware updates.
Great article! I was under the impression that the difference between P2PE and E2EE is simply that a P2PE solution must be validated by a P2PE assessor. To my understanding, this can be a major issue for solution providers, and has prevented a number of them from going through the process, as the requirements are fairly rigorous from a hardware standpoint, particularly the use of an HSM for key management. From the perspective of a merchant, how do you choose whether to go with E2EE, which won’t allow you to complete the much smaller in scope P2PE-SAQ, versus a P2PE solution, which is generally much more expensive due to logging, monitoring, scanning, testing, etc.? Or am I mis-interpreting it? I would be very interested in hearing your opinion on how an E2EE implementation with the processor performing key management affects a company’s obligations under the broader SAQ-C. In your opinion, does it eliminate everything from scope except requirements 9 and 12, like the P2PE-SAQ? Or do you still have to perform annual penetration testing, for example? Thanks again for the great write-up.
It is not a question of prevention, it is a question of why do I need to certify? As far as we have been able to tell, there is very little reason to do P2PE certification unless you like paying for a P2PE QSA and paying to register your solution. As far as scope reduction because you are using a P2PE solution, that is minimal at bast as a QSA still has to verify a number of items and those still have to be verified using an E2EE solution. The only thing that really changes is verification of key management, and that is usually done by an HSM with E2EE, so big deal.
E2EE for a small merchant is not significantly different from P2PE for a small merchant. Either way, key management is done by a third party, so really other than marking a lot of requirements ‘Not Applicable’ on an SAQ D, there really isn’t a whole lot more work involved.
Even with P2PE you are still obligated to do vulnerability scanning and penetration testing, definitely internally and potentially externally depending on how the network is configured. Granted, the scope is much smaller, but you still need to make sure that the terminal and infrastructure are secure.
I tend to disagree with you on the scope reduction. Currently, if a company is using LAN based POI (Ethernet or WiFi), it brings into the scope every single network segments and devices between the POI and the internet, regardless of using E2EE or not, and regardless of who manages the E2EE keys. The QSA will have to assess every switch and router in between, and consider everything as part of the CDE.
On the other hand, a P2PE certified *solution* completely removes any underlying network elements from the scope, which allows POI to be anywhere in the network with traffic going all the way through the WAN up to the internet exit point, without bringing anything in the middle into CDE, and therefore disregarded by the QSA.
This is, in my opinion, a major incentive towards adoption of P2PE solutions even if the implementation might be complex and a little pricy. Over the long term, scope reduction is the key to solve the PCI DSS burden.
P2PE, like PA-DSS applications, still must be assessed to ensure that the solution has been implemented according to their Implementation Guide from the vendor.
Yes, you need to worry about intermediate devices. If the encryption keys are managed by a processor or a bank, the intermediate network devices at the merchant would not have access to the keys, but as you point out that must be proven. However, once proven and approved by the merchant’s acquiring bank, then E2EE can be treated the same as P2PE.
Although the previous version of ANSI X9.24 did specify only single DES for DUKPT, the newer version (still out for a while, published in 2009) does use TDES only. Most DUKPT implementations these days will support either single or Triple DES.
Thanks for the update. While 3DES is allowed, most implementations I have encountered are still DES. I have updated the post to reflect 3DES.