Transport Layer Security (TLS)

Applies to. TLS is the usual way an entity meets Requirement 4, which asks for strong cryptography and secure protocols whenever PAN is sent over open, public networks: the internet, wireless technologies, and cellular or satellite links. That covers a shopper's browser session with a payment page, the merchant's connection to its gateway or acquirer, and any API that carries PAN between organisations. Which TLS versions and cipher suites count as strong is set by the industry standards the Council points to, not by a version number in the requirement text.

Example. A ticketing company runs its own checkout and sends the PAN to its acquirer over the internet. It configures both the customer-facing web server and the outbound acquirer connection to negotiate TLS 1.2 or 1.3 only, with a documented cipher list and certificates from a trusted authority, and keeps a record of the configuration so an assessor can compare it with what the servers actually negotiate.

Limits. TLS protects data in motion only; once the session ends the PAN sits in the clear on the receiving system, and Requirement 3 takes over. It is only as strong as its configuration: a server that accepts TLS 1.0 or SSL alongside TLS 1.2 is not using strong cryptography, and an expired or self-signed certificate that clients are told to ignore removes the authentication the protocol is meant to provide. Requirement 4 is about open, public networks; encrypting PAN on an internal, segmented network is good practice but is not what that requirement tests. TLS between a browser and a page also says nothing about the page itself: script and payment page controls sit in Requirements 6 and 11.