Q&A from P2PE-NESA Webinar for Merchants

Tim Winston, Principal, P2PE/Payment Processors

The selection of a PCI-listed P2PE solution and determination of expected benefits can be challenging for even the most sophisticated merchants. The introduction of the NESA program can make decisions more difficult. To help guide merchants, Coalfire and FreedomPay held a webinar “P2PE & NESA for Merchants: How PCI P2PE and NESA Can Reduce Your Compliance Burden and Risk”. You may access the archive of this webinar here.

Based on the active participation of our audience and length of our discussion, we were unable to answer all the questions submitted during the webinar. Below, we provide the answers to the complete set of questions from the event.


  1. Q: Can POS be moved out of scope with a Non-Listed Solution? (In the very first picture it wasn't crossed out as opposed to a P2PE picture.)

    A: Coalfire’s assertion is that solutions that fully qualify for NESA per PCI’s guidance, have sufficiently secured the encrypted data and decryption keys such as to remove POS assets from scope. Thus, truly NESA-compliant solutions should not require the POS itself to have any remaining applicable DSS controls. However, there may be other controls related to the merchant environment and POI devices that remain in scope.

  2. Q: How do you know which controls are reduced when you say “Scope Reduction” for a NESA solution?

    A: The P2PE QSA that performs the NESA evaluation would select a subset of PCI DSS controls that address remaining risks from using a solution that does not meet the P2PE standard. These controls are detailed in the NESA Summary Documentation, which would be issued to the Merchant from the NESA provider. The NESA Summary Documentation should be discussed with the acquirer to confirm reduction of scope.

  3. Q: For Service Providers considering NESA, would this get them to the point where they do not have to take their service through a PCI DSS assessment annually?

    A: There are two types of service providers – those that deliver the encryption solution (e.g., called a solution provider) and those that pass through encrypted card data to a solution provider (e.g., a WebPOS provider), but is not the actual encryption solution provider. For service providers that are providing the P2PE or non-listed encryption solution, they must continue to be assessed for PCI DSS compliance, because once the card data is decrypted, it is vulnerable. For service providers that are using a third-party NESA or P2PE solution provider, there is an opportunity to be out of scope, but only if they can demonstrate that they no longer encounter card data by virtue of the third-party NESA or P2PE solution provider providing encryption for all transactions within their control.

    Merchants are required by PCI DSS requirement 12.8 to monitor compliance status at least annually for all service providers, including encryption solution providers. This control is always applicable for merchants that accept credit card payments, regardless of using encrypting solutions or any other services. Service Providers using encryption solution providers will need to similarly monitor the compliance of those solution providers to demonstrate their continued compliance status. To help in confirming and communicating that PCI DSS requirements no longer apply, Coalfire has performed “out-of-scope” assessments and white papers for software and service providers that have fully eliminated all cardholder data from their realm of control.

  4. Q: How long is the typical NESA evaluation (how many months)? Is it a snapshot in time, similar to other assessments?

    A: The Non-Listed Encryption Solution Assessment is a snapshot in time, so three months is a reasonable time period for assessment and minor remediation. However, there is a good degree of complexity in the decryption environment which, if being implemented from a standing start, may add to the project timescales significantly. Entities who have not already performed a gap assessment for Domains 5 and 6 may require more time for remediation to fully meet NESA requirements.

  5. Q: How many NESA evaluations have been completed since it was first introduced 4 months ago?

    A: It’s not possible to determine, as the NESA solutions are not listed anywhere.


  6. Q: Is it necessary to put POS devices in VLANs if you utilize P2PE?

    A: No. VLANs in and of themselves have never been considered strong segmentation from a PCI scoping perspective, unless they were accompanied by strong access control lists or inter VLAN traffic controlled via firewall rules.

    The deployment of a listed P2PE solution means that the payment devices can stand alone on an otherwise un-trusted, un-validated environment.

  7. Q: Can you have P2PE points of sale using the same network as non P2PE points of sale?

    A: Yes. However, any scope reduction from P2PE will be negated due to having to implement PCI DSS for the whole network due to the non-P2PE points of sale.

  8. Q: How does the PTS requirement apply to POIs that are swipe only? Can a swipe-only reader be P2PE validated?

    A: Yes, swipe-only can go through the PTS requirements that apply for P2PE. Consult the PTS listing on the PCI website, select the Device Type of “SCR” for PTS-approved swipe-only devices, and review devices with the “Function Provided” including “SRED.”

  9. Q: Can SDKs be certified for P2PE, given that the POI being used is certified and all other P2PE requirements are met. In other words, are the payment SDKs or mobile apps out of scope for a P2PE solution?

    A: There is no need to P2PE-certify a mobile device SDK that interfaces with a separate PTS device. While the application on the PTS device that provides the API may go through PA-P2PE validation, the SDK that resides on the mobile device does not go through this certification. For merchants implementing a P2PE solution with mobile devices, the mobile device (including the mobile SDK) is out of scope for PCI DSS.

  10. Q: Is antivirus and anti-malware eliminated from requirements with P2PE? Also, who manages patching?

    A: For eligible merchants deploying a PCI-listed P2PE solution, the remaining controls can be found in the SAQ P2PE. The controls do not include antivirus or patching of the POS or other systems that may otherwise be in scope. The P2PE solution provider is responsible for maintaining the security of the application on the PTS device, and updates to the PTS device configuration.


  11. Q: Are computers used to access pay.gov in scope?

    A: Pay.gov is treated as any other ecommerce site. Merchant systems that store, process, or transmit cardholder data are in scope for PCI DSS. In this case, if a merchant provides a computer system to facilitate access to a site like pay.gov, the merchant system and network are most likely in scope. Please contact your Coalfire account representative for more assistance with this question.

  12. Q: If the encrypted transaction is not considered CHD, but the encrypted transaction is found to have been accessed (e.g., by a memory scraper on the POS Terminal) and transmitted out of the network, would this be considered a breach in terms of needing to implement the Incident Response Plan and notify the Acquirer and/or brands?

    A: This would probably be defined as a security breach but may not be considered a cardholder data breach.

    Incident response should always be executed if you find any malware attempting to manipulate your point of sale – even if it is just to protect you from fraud. When encrypted card data is compromised, it is important to assess whether the encryption keys might also be at risk. For this reason, it would be wise to discuss the breach with the acquirer and/or the NESA solution provider in order to ensure they have not been targeted and their keys not compromised.

To learn more about our PCI services and listed P2PE solutions, please visit our solutions page.

Tim Winston


Tim Winston — Principal, P2PE/Payment Processors

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS