What to Expect in the PCI 3.2 Update

Shawn Shifflett, CISSP, QSA, Senior Practice Director, PCI

A preview of new requirements and guidance expected later this month from the Payment Card Industry Security Standards Council was announced Thursday. The PCI DSS 3.2 version represents the first update to the standard that the Council has released since 3.1 in April 2015 and 3.0 in November of 2013.

The Council is making more incremental changes in the PCI standard due to the need to stay abreast of both hackers’ fast-changing attack vectors, and the evolving payments security technology space. The Council stated that because the standards are considered mature, they are likely to maintain 1-2 incremental updates a year, versus the previous updates of once every three years.

A brief summary of changes included in the 3.2 update from the Council are:

  • Two new appendices:
    • Appendix A2 – Additional PCI DSS Requirements for Entities using SSL/Early TLS
    • Appendix A3 – Designated Entities Supplemental Validation (DESV)
  • Support for display of PAN great than first six/last four for specific required business needs
  • Expand multi-factor authentication requirements (see below)
  • Additional requirements for Service Providers only:
    • Documentation of cryptographic architecture
    • Detect/report on failures of critical control systems
    • Penetration testing on segmentation controls every six months
    • Establish a formal PCI DSS compliance program
    • Confirm at least quarterly that personnel are following security policies and procedures

Multi-Factor Authentication Requirements
The council has decided to change their previous terminology from “two-factor authentication” to the “more modern term” of “multi-factor authentication” (MFA), however, the council’s definition and expectation does not change.  The biggest news from the council was that they intend to expand multi-factor authentication requirements to all non-console based remote access to the cardholder data environment (CDE).

From our experience, the implementation of this control will be impactful to most organizations.  With few exceptions, most organizations do not require MFA for administrative access to every system within the CDE.  Many of our customers have started to include MFA for access to a bastion host.   However, based on the information provided, MFA will need to be used for administrative access to every system in the CDE, including network devices, workstations and server infrastructure.  We anticipate that this will take some time and investment from our customers to fully implement.

The need for multi-factor authentication was cited because of the continued and expanding attacks on password authentication, as well as the continued use of weak passwords.

Establish a formal PCI DSS compliance program
In PCI DSS 3.2, the council is starting to embed some of their “Business As Usual” controls into specific requirements for service providers.  Although limited details were provided during the announcement to the QSA community, Coalfire is anticipating that this will be an area that will require some time, effort and investment for continuous monitoring and improvement.  Regardless of the details, organizations should begin to evaluate their management programs and look to improve their security and compliance maturity to focus on ensuring controls are not point in time solutions but sustainable and managed processes.  Many breaches these days are caused by controls that were neglected between assessments and not managed on a continuous basis.

Extending the SSL/Early TLS Requirement
The deadline for moving from SSL/early TLS 1.0 to TLS 1.2 has been extended to June 30, 2018 for all service providers, as communicated in the blog post in December 2015. Prior to June 30, 2018, existing implementations must have a formal Risk Mitigation and Migration Plan in place.

Secure Sockets Layer (SSL) and early Transport Layer Security (TLS) protocols have held known vulnerabilities for many years. The extended dates should not be an excuse to delay, but the Council indicated that they understand that service providers also need more time to complete complex migrations.

You can read more about this issue in an earlier blog post: https://www.coalfire.com/The-Coalfire-Blog/January-2016/PCI-Council-Gives-Merchants-Reprieve-on-PCI-3-1

Sunset Dates for PCI DSS 3.1
The new 3.2 standard is expected to be released near the end of April. At that time, service providers and merchants will have six months before the 3.1 standard sunset date.

If you’ve considered starting a PCI compliance project and you know you will not meet the 3.2 standard now, it’s important to contact your QSA to make sure you begin work on the PCI 3.1 standard so it can be completed in the next few months.

PCI 3.2 Updates For ASVs
Another major change to the PCI DSS 3.1 standard was related to SSL/early TLS detection.

ASVs should be focused on detection and reporting vulnerabilities. The council was clear in stating that ASVs are not responsible for evaluation of the merchant’s remediation plan. They only need to validate that one exists.

This leaves most scan customers a little in the dark as to whether or not their remediation plans are adequate to meet the new standard. Coalfire can help you write or evaluate a remediation plan to make sure your company’s security posture is progressing and would meet the expectations of a QSA for a remediation plan.

The new update also states that detection of SSL/early TLS should result in a failed scan, with exceptions handled according to the ASV Program Guide. ASVs may issue a passing scan where the exception process is met.  This can be a complex concept to understand, if additional guidance is required, please contact Coalfire for additional guidance in using SSL and early TLS in a compliant manner.

PA-DSS v3.2 Update
The PA-DSS update is much more limited than PCI 3.2 and aligns with the PCI 3.2 changes. A full PA-DSS v3.2 release is expected in May and will include an adequate transition time to complete v3.1 validations.

These updates demonstrate how the council is moving toward making more incremental updates, versus the wholesale update every three years. We’ll keep you informed here about updates as we receive information.

Shawn Shifflett


Shawn Shifflett — CISSP, QSA, Senior Practice Director, PCI

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