I have found Are You Ready for 30 June 2018? Saying Goodbye to SSL/early TLS article that says TLS 1.0 should be disabled:

30 June 2018 is the deadline for disabling SSL/early TLS and implementing a more secure encryption protocol – TLS 1.1 or higher (TLS v1.2 is strongly encouraged) in order to meet the PCI Data Security Standard (PCI DSS) for safeguarding payment data.

Is PCI DSS standard requirements regarding TLS applicable only to customer facing webs or to whole even internal networks?

  • Another question on PCI was deemed of-topic, so in case this goes the same way... the main question I'd ask is if SSL/TLS (whatever the version) is already required by PCI for internal networks (I've no idea if it is or not) then a requirement to disable unsafe versions externally really ought to apply internally as well. (And if PCI doesn't demand TLS internally, it probably should).
    – TripeHound
    Jun 12, 2019 at 13:08

4 Answers 4


There is no requirement in PCI DSS to encrypt cardholder data in transit over private (ie not the internet and not wifi) networks. Therefore if you are using early TLS or SSL on an internal wired network it is fine (according to the standard) to continue to use it. See requirements

4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks


4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission

You may of course take a different view in respect of security rather than compliance with DSS. The basic rule is that where encryption in transit is used as a security control mandated by DSS (ie requirements 4.1 & 2.3) the it must be strong (not SSL, not early TLS). Where it is not used as a security control mandated by DSS, but as a security control of your own choosing, DSS has no requirement.


As far as I know internal SSL is also required. CC data needs to be encrypted in transit, and that includes both public and private networks. Depending what your apps connect to it it also means connections from applications to the DB/messaging systems/you name it... and also if you use an CDN/SSL accelerator like Akamai, the SSL accelerator shouldn't see the plain CC details, unless they are PCI Certified themselves on the services you use AND you need to have evidence they are certified (aka a signed document, which usually costs a pile of money, saying they are certified).

Reference: Talks with a QSAs.

  • 1
    There is actually no PCI DSS requirement to encrypt cardholder data in transit on internal wired networks. You may think there should be, I would agree, however it is not currently (v3.2.1) a requirement in the standard. Jun 15, 2019 at 15:20
  • Thanks @withoutfire. I'm not a PCI expert, but I remember the QSAs I spoke to were quite clear about having as little places as possible with clear text access to in-transit CC data (e.g. firewalls, SSL terminators, intermediate apps). Probably was more a safeguard.
    – Augusto
    Jun 15, 2019 at 15:31
  • It's definitely good practice. It is also common to use encrypted links on internal networks to remove network segments from scope - and if this is the case then the SSL/TLS is being used as a security control and so would need to be upgraded to (ideally) 1.2 Jun 17, 2019 at 18:44

Payment data should be encrypted in transit and at rest for every step in the process. SSL and TLS 1.0 are now depreciated, e.g. disabled on payment gateways to force merchants to properly encrypt upsteam connections, but for internal processing you have more choices than what is supported by browsers but you will have to dig into technical docs to work out what you will need to configure in your own process flows.

My own direct experience with (now former) customers is that internal encryption is often ignored. Also note that the standards are changing again with enhanced authentication becoming mandatory later this year which I suspect is going to affect a lot of merchants who have not kept up to date particularly hard.


Is PCI DSS standard requirements regarding TLS applicable only to customer facing webs or to whole even internal networks?

"It depends" is going to be the answer.

If you have administration channels for you're devices (RDP, HTTPS, etc) and they use TLS, then requirements 'Strong Cryptography' will apply for them as well.

They aren't directly 'SSL/TLS' requirements, but amount to the same thing. They are also not dealing with credit card data, but administration traffic and credentials for administrators.

As others have pointed out, there are also the internet public facing network channels which are transmitting credit card data.

The list of requirements is included here

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .