PCI Compliance: Early-TLS and Cloud Service Providers

Dan Stocker, Practice Director, Payments, Cloud & Tech

Organizations tracking their PCI compliance are likely aware of the impending June 30, 2018 deadline to disable SSLv3 and early-TLS. This blog post examines the special case of Cloud Service Providers (CSPs) and how their customers should proceed to achieve compliance.

In April 2015, in response to the POODLE and BEAST vulnerabilities, the PCI Security Standards Council (SSC) published guidance for merchants and service providers. That guidance set deadlines for both roles. Service providers were expected to offer a compliant service by June 30, 2016, with the goal of enabling their customers to use non-vulnerable ciphersuites under TLS 1.1 and TLS 1.2. Merchants were expected to opt into those compliant services, and to also disable early-TLS altogether, by June 30, 2018.

That deadline is approaching, and Coalfire has advised a number of clients on the implications and how to approach the effort. A common question has been about the role of CSPs in meeting the SSC guidance.

For CSPs, there is a key distinction that is helpful to keep in mind. Where a service provider deals directly in cardholder data (e.g., payment processors, e-commerce, etc.), the expectation to disable early-TLS is clear guidance from the SSC. Where the CSP does not directly deal with their customer's data, there is no mandate. Examples of the latter would be CSPs like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). These providers are deliberately abstracted from their customers implementations. Their services are building blocks, which enable customers to architect solutions.

This abstraction is important primarily because it means the cloud providers do not know which of their customers have PCI compliance obligations. Not all will, and thus there will be a mix of PCI and non-PCI customers. Those non-PCI customers will have business interests in maintaining use of early-TLS (SSLv3 has already been disabled). What this means is that cloud customers will have responsibility to ensure that early-TLS is disabled, using the CSP's customer-facing controls. This will allow customers to manage their own compliance obligation.

Coalfire recommends the following next steps:

  • Part of PCI compliance management is assessing risks to cardholder data. Use of SSLv3 or early-TLS represents both security and non-compliance risks. If you haven't already, get this issue on your radar.
  • Even if your annual assessment cycle ends before the June 30, 2018 deadline, you are still expected to comply. One of the conditions that officers agree to when they sign an AOC is to maintain PCI compliance.
  • Cloud customers should consult the Responsibility guidance published by their CSP and ensure they are using that guidance effectively.

Coalfire can help merchants on this journey as well as service providers looking for advice on how best to meet the SSC guidance.

Dan Stocker


Dan Stocker — Practice Director, Payments, Cloud & Tech

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