Category: Network Security
Transport Layer Security
Also known as: TLS, TLS protocol
Simply put
Transport Layer Security (TLS) is a security protocol that protects information as it travels between two applications over a network such as the Internet. It is intended to keep that communication private and to help ensure the data is not altered in transit. It is widely used as a standard practice for securing Internet communications.
Formal definition
TLS is a cryptographic protocol that provides privacy (confidentiality) and data integrity between two communicating applications over a computer network. As described by NIST, the protocol is composed of two layers. It is designed to secure communications at the transport layer over otherwise unprotected networks. Note that the strength of protection depends on the negotiated protocol version and cipher suites, and the effect of TLS on any specific compliance scope depends on implementation and validation rather than the presence of the protocol alone.
Why it matters
Payment data in transit — including cardholder data such as the primary account number, and sensitive authentication data during authorization — is exposed to interception whenever it crosses open or untrusted networks like the Internet. TLS is intended to protect that traffic by providing confidentiality and integrity between two communicating applications, helping reduce the risk that data is read or altered while moving between systems. Without transport protection, an attacker positioned on the network path could potentially capture or tamper with sensitive information.
For compliance purposes, protecting cardholder data during transmission across open, public networks is a longstanding expectation, and TLS is the mechanism most organizations rely on to meet it. However, the presence of TLS alone does not establish adequate protection or determine compliance scope. Older protocol versions and weak cipher suites can be negotiated in ways that materially weaken the protection, so the security actually achieved depends on the negotiated version, the configured cipher suites, and correct implementation and validation rather than on the label 'TLS' by itself. Readers should confirm current requirement wording, numbering, and any version-related expectations against the current published PCI DSS standard rather than assuming a fixed requirement.
Who it's relevant to
Security Engineers
Security engineers configure and maintain TLS on systems that transmit cardholder data over networks. They are responsible for selecting supported protocol versions and cipher suites, disabling weak or deprecated options, and validating that endpoints negotiate protection strong enough for the data being carried, since the assurance provided depends on configuration rather than the protocol name alone.
Compliance Officers
Compliance officers evaluate whether transmission of cardholder data over open, public networks is protected in line with the current published PCI DSS standard. They should verify implementation and validation rather than treating the mere presence of TLS as sufficient, and confirm current requirement wording and numbering against the standard in force rather than assuming a fixed requirement.
Payment Processors and Acquirers
Processors and acquirers exchange sensitive transaction data with merchants and other parties across networks and rely on TLS to help keep those communications private and unaltered in transit. They have an interest in ensuring that negotiated versions and cipher suites across their connections meet agreed security expectations, given that protection strength varies by configuration.
Merchant Risk and Technical Teams
Merchant teams implementing e-commerce and network-connected payment systems use TLS as a standard practice for securing Internet communications carrying payment data. They should treat correct implementation and validation as part of their responsibility, recognizing that TLS protects data in transit but does not by itself address how data is stored or otherwise handled.
Inside TLS
Handshake protocol
The negotiation phase in which client and server agree on a protocol version and cipher suite, authenticate via certificates, and establish shared session keys before application data is exchanged.
Server (and optional client) certificate authentication
X.509 certificates presented during the handshake to verify the identity of the endpoint, typically validated against a trusted certificate authority chain. Client certificates may also be used for mutual authentication where required.
Cipher suites
The combination of key exchange, authentication, bulk encryption, and message integrity algorithms negotiated for a session. Suite selection determines the cryptographic strength of the connection.
Record protocol
The layer that applies the negotiated encryption and integrity protection to the actual data transmitted, providing confidentiality and tamper detection for data in transit.
Protocol versions
Distinct versions of the standard (for example, earlier TLS versions and later ones) that differ in supported algorithms and security properties. Older versions and predecessor protocols such as SSL are generally considered obsolete.
Relationship to PCI DSS
PCI DSS addresses protection of cardholder data transmitted over open, public networks and references the use of strong cryptography and secure protocols. Specific requirement numbering and wording differ between PCI DSS versions, so confirm against the current published standard.
Common questions
Answers to the questions practitioners most commonly ask about TLS.
Does using TLS mean my organization is PCI DSS compliant?
No. TLS is one control that helps protect cardholder data in transit over open, public networks, but PCI DSS compliance depends on many other requirements covering data storage, access control, monitoring, vulnerability management, and more. Encrypting a transmission channel does not by itself satisfy the standard, and it does nothing to protect data at rest or within your systems. Confirm the full set of applicable requirements against the current published version of PCI DSS rather than assuming that strong transport encryption alone is sufficient.
Does TLS encryption take my systems out of PCI DSS scope?
Not on its own. TLS protects data while it moves between endpoints, but the endpoints that transmit, process, or store cardholder data typically remain in scope. TLS is not the same as tokenization or point-to-point encryption (P2PE), which may reduce scope depending on how they are implemented and validated. Whether any encryption approach affects scope is determined by the specific implementation and validation, not by the label. Do not assume that terminating or originating a TLS connection removes a system from scope.
Which TLS versions and configurations should we use to help meet PCI DSS expectations?
PCI DSS calls for strong cryptography and secure protocols for transmitting cardholder data over open, public networks, and early SSL and early TLS versions have been treated as no longer providing strong cryptography. Organizations should generally use current, well-supported TLS versions with secure cipher suites and disable known-weak protocols and ciphers. Because acceptable versions and cipher guidance evolve, confirm current expectations against the applicable published PCI DSS version and supporting guidance rather than relying on a fixed list.
How does TLS relate to certificate and key management?
TLS relies on server (and sometimes client) certificates and the private keys behind them, so the strength of the protection depends heavily on how those keys and certificates are generated, protected, rotated, and revoked. Poor key management, expired or improperly validated certificates, or trust of weak certificate authorities can undermine the protection TLS is intended to provide. Certificate and key management practices are subject to their own PCI DSS controls, so treat them as part of your TLS deployment rather than an afterthought.
Do we need TLS for internal network segments that carry cardholder data?
PCI DSS specifically requires strong cryptography and secure protocols when cardholder data is transmitted over open, public networks. For internal or private networks, requirements depend on the current standard and your risk assessment, and many organizations apply encryption in transit internally as a defense-in-depth measure. Whether it is mandated in a given case depends on network characteristics and the applicable published requirements, so validate the specific expectation against the current standard rather than assuming a blanket rule.
How can we verify that TLS is configured correctly across our environment?
Verification typically combines configuration reviews, vulnerability scanning, and testing that confirms only approved protocol versions and cipher suites are negotiated and that certificates are valid and properly trusted. It is important to test all endpoints that handle cardholder data, since a single misconfigured service can weaken overall protection. Testing helps identify weak or deprecated settings, but it should be performed on an ongoing basis, because configurations drift and cryptographic guidance changes over time; confirm current testing expectations against the applicable published standard.
Common misconceptions
TLS encryption of a transmission means the data can be freely stored afterward because it is protected.
TLS protects data in transit; it does not authorize storage. Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks must not be stored after authorization even when encrypted, and stored cardholder data is subject to separate at-rest controls.
Using TLS is equivalent to tokenizing or encrypting stored data for the purpose of reducing PCI DSS scope.
TLS is a transport-layer protection distinct from tokenization, encryption at rest, truncation, masking, and hashing. Its effect on scope depends on implementation and validation, not on the label; TLS alone does not remove stored data protection obligations.
Any version labeled TLS is acceptable and provides equivalent security.
Protocol versions and cipher suites vary in strength, and older protocols including SSL and early TLS versions are generally considered obsolete. What qualifies as strong cryptography should be confirmed against the current published standard rather than assumed from the TLS label alone.
Best practices
Disable obsolete protocols and weak cipher suites, and configure endpoints to negotiate current, strong protocol versions and algorithms; confirm acceptable configurations against the current published PCI DSS guidance.
Validate certificates properly, including chain of trust, expiration, and hostname verification, and manage certificate lifecycle and private keys under defined controls.
Do not treat TLS in transit as authorization to store data; ensure sensitive authentication data is not retained after authorization and that any stored cardholder data is protected by separate at-rest controls.
Apply TLS consistently to cardholder data transmitted over open, public networks, and verify coverage across all relevant transmission paths rather than assuming a single endpoint is sufficient.
Combine TLS with the appropriate distinct controls for data at rest, such as encryption, tokenization, truncation, or masking, selecting each based on validated implementation rather than the label.
Periodically review protocol and cipher configurations as standards evolve, and confirm current requirement wording and version applicability against the current published standard rather than a fixed requirement number.