PCI Council deadline – Are Your Customers Ready for 30 June 2018? 

PCI Council deadline - Are Your Customers Ready for 30 June 2018? 
By Natasja Bolton, Senior Acquirer Support QSA

Back in January 2016, we highlighted the PCI Council’s extension of the migration completion date for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher).  Now, with just 8 months to go until the migration date deadline, we’re here to ask: Are Your Customers Ready for 30th June 2018?


What is the deadline?

By 30th June 2018, organisations must have moved away from using SSL or early TLS as a security control and instead be using only secure versions of the protocol.


PCI DSS Appendix A2 sets out details of the migration deadline, which is further explained in the Migrating from SSL and Early TLS Information Supplement.


Note that the exception allowing for continued use of SSL/early TLS within a Point of Interaction (POI) terminal and its termination point, that has been verified as not being susceptible to all known exploits for SSL and early TLS, beyond end June 2018 is still in place.


What requirements are impacted?

SSL and early TLS cannot be used as a security control to meet these requirements:


Requirement Control
2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
2.3 Encrypt all non-console administrative access using strong cryptography.
4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.



Webpage URL

Find out more about our PCI DSS compliance services by clicking the button below


What do organisations need to do?

Any entity still using SSL or early TLS as a security control must have a ‘Risk Mitigation and Migration Plan’ with a planned completion date no later than 30th June 2018.  Now is the time to confirm with your customers whether their migration plans are still on track for completion before the deadline.


As the Migrating from SSL and Early TLS Information Supplement outlines, organisations have a number of options available to them that will fulfil the requirement to make sure that SSL/early TLS is not being relied upon as a security control:


1.Upgrade to a current, secure version of TLS – implemented securely and configured to not accept fallback to SSL or early TLS.

2.Encrypt the data with strong cryptography before it is sent over SSL/early TLS


  • Set up a strongly-encrypted session or tunnel prior to sending data over SSL within the secure tunnel (e.g. IPsec encrypted tunnel).


Are post-migration customers still secure?

Your customers may have already confirmed to you their successful migration to secure versions of TLS.  For those customers, it is still worth reminding them that communications security is not just dependent on the protocol used but also on its maintenance and configuration.  Aspects of TLS security that should be checked include:


  • Software updates and patching – has an update to the customer’s TLS software been released since their migration to TLS was completed? If so, your customer needs to make sure those patches have been applied.


For example, bug and security fix updates for the OpenSSL encryption toolkit, which is commonly used in internet ecommerce web servers, are released every few months.


  • Secure Configuration – is the TLS implementation securely configured? Even TLS v1.2 has known weaknesses and your customers should follow industry good practice and vendor recommendations to make sure their implementation is securely configured.


For example:



Do all instances of SSL/early TLS need to be removed from customer environments?

For those of your customers that may be struggling to remove all uses of SSL or early TLS in their environment; it is worth remembering that SSL and early TLS protocols can remain in use if they are not being used as a security control.  That is why options II and III, shown above, are available as ways to meet the migration deadline.


However, those customers that do continue to use SSL and early TLS in those circumstances, need to be aware that, after the June deadline, they will need to work with their Approved Scanning Vendor (ASV) to make sure they can achieve passing ASV external vulnerability scan reports.  The customer will need to follow the ‘Addressing Vulnerabilities with Compensating Controls’ process with their ASV to verify that ‘the affected system is not susceptible to the particular vulnerabilities’ (see the ASV Program Guide section 7.8), confirming that the SSL or early TLS usage detected by the ASV is not being used as a security control.


Like this Article?

Subscribe to receive more tips & news about Cyber Security, Compliance and a lot more!

  • Sysnet Global Solutions will use the information you provide on this form to be in touch with you regarding non-promotional as well as promotional material by email and phone. If you agree to same, then please select the ‘I consent’ box after reading the terms and conditions listed below in relation to consent. You can change your mind at any time by clicking the unsubscribe link in the footer of any email you receive from us, update your preferences for communications, content etc. by clicking on the update my preferences button in any email we send you or by contacting us at marketing@sysnetgs.com We will treat your information with respect. For more information about our privacy practices please visit our website. By clicking below, you agree that we may process your information in accordance with these terms. We use Pardot as our marketing automation platform. By clicking below to submit this form, you acknowledge or agree that the information you provide will be transferred to Pardot for processing in accordance with their Privacy Policy and Terms