Category: Network Security

TLS 1.3

Also known as: TLS 1.3, Transport Layer Security version 1.3, Transport Layer Security 1.3, RFC 8446

Simply put

TLS 1.3 is the 2018 version of Transport Layer Security, a widely used protocol that encrypts data as it travels between applications over the internet, such as between a browser and a website. It is designed to be faster and to offer stronger security than the earlier TLS 1.2 version, in part through a streamlined connection setup and improved handling of encryption keys. Like any protocol, its real-world security also depends on how it is implemented and configured.

Formal definition

TLS 1.3, specified in IETF RFC 8446 and defined in August 2018, is version 1.3 of the Transport Layer Security protocol enabling encrypted client/server communication over untrusted networks. Relative to TLS 1.2, it revises the handshake to reduce round trips, removes a number of legacy and weaker cryptographic options, and is designed to provide forward secrecy for its key exchange, so that compromise of a long-term key does not retroactively expose previously recorded session traffic. In a payment security context, TLS commonly protects cardholder data in transit; note that the protocol version itself is distinct from correct deployment, cipher configuration, certificate management, and endpoint controls, and that specific PCI DSS requirements addressing transmission encryption differ by version and should be confirmed against the current published standard. As with any protocol, TLS 1.3 security is subject to implementation-specific vulnerabilities and evolving disclosures over time.

Why it matters

In payment environments, cardholder data frequently moves across untrusted networks, and TLS is the most widely used method of encrypting that data in transit. TLS 1.3, defined in August 2018 in IETF RFC 8446, is intended to improve on TLS 1.2 by streamlining the connection handshake and removing a number of legacy and weaker cryptographic options. This matters to security and compliance teams because the protocol version negotiated between endpoints directly affects the strength of transmission encryption protecting data such as the primary account number as it travels between systems.

A key property of TLS 1.3 is its design for forward secrecy in key exchange, which is intended to ensure that compromise of a long-term key does not retroactively expose previously recorded session traffic. This helps reduce the risk that captured, encrypted traffic could later be decrypted if a server key is compromised. However, the protocol version alone does not determine real-world security: correct deployment, cipher configuration, certificate management, and endpoint controls all shape the actual protection achieved.

Teams should also recognize that TLS 1.3, like any protocol, is subject to implementation-specific vulnerabilities and evolving disclosures over time. Selecting a modern protocol version is one input to secure transmission of cardholder data, but it does not by itself satisfy compliance obligations or eliminate risk. Specific PCI DSS requirements addressing transmission encryption differ by version and should be confirmed against the current published standard rather than assumed.

Who it's relevant to

Security engineers

Engineers responsible for configuring servers, load balancers, and application endpoints use TLS 1.3 to encrypt data in transit. They must attend not only to enabling the protocol version but also to cipher configuration, certificate management, and monitoring for implementation-specific vulnerabilities, since the protocol version alone does not determine the security actually achieved.

Compliance officers

Those overseeing PCI DSS compliance care about transmission encryption for cardholder data. TLS is commonly used to protect such data in transit, but the specific requirements addressing transmission encryption differ by PCI DSS version and should be confirmed against the current published standard rather than assumed from the protocol version alone.

Payment processors and acquirers

Organizations handling large volumes of transactions rely on encrypted channels to protect cardholder data as it moves between systems and partners. TLS 1.3's design for forward secrecy and its streamlined handshake are relevant to both the security and performance of these connections, though correct deployment and endpoint controls remain essential.

Application and infrastructure architects

Teams designing how services communicate over untrusted networks weigh TLS 1.3's reduced handshake round trips and removal of legacy cryptographic options when planning encrypted communication. They should treat the protocol version as one input among certificate management, cipher configuration, and endpoint security rather than a standalone control.

Inside TLS 1.3

Protocol version

TLS 1.3 is the version of the Transport Layer Security protocol succeeding TLS 1.2. It defines how a client and server negotiate a secure channel to protect data in transit, including during the transmission of cardholder data across open, public networks.

Reduced handshake

TLS 1.3 streamlines the connection handshake compared to earlier versions, reducing the number of round trips required to establish a session. This can lower connection latency while still negotiating encryption parameters.

Pruned cipher suites

TLS 1.3 removes support for a number of older cryptographic algorithms and modes associated with weaknesses in prior TLS versions, retaining a smaller set of authenticated-encryption cipher suites.

Forward secrecy by default

TLS 1.3 uses ephemeral key exchange so that compromise of a long-term key does not, on its own, allow decryption of previously recorded sessions. This property is often described as perfect forward secrecy.

Relationship to PCI DSS scope

TLS is one mechanism for protecting cardholder data during transmission over open, public networks. Whether a given TLS configuration satisfies applicable PCI DSS requirements depends on implementation, cipher selection, certificate management, and validation against the current published standard, not on the protocol version label alone. Confirm requirement wording and numbering against the current PCI DSS version rather than assuming a fixed reference.

Common questions

Answers to the questions practitioners most commonly ask about TLS 1.3.

Does using TLS 1.3 mean my connections have no known vulnerabilities?

No. TLS 1.3 removed several weak features present in earlier versions and is generally considered a stronger protocol, but that is not the same as being free of vulnerabilities. Vulnerabilities are regularly disclosed against specific TLS implementations and libraries rather than the protocol design alone, and configuration errors can also introduce weaknesses. Treat TLS 1.3 as one control that helps reduce certain risks, and keep libraries patched and configurations reviewed against current guidance.

Does deploying TLS 1.3 by itself make my environment PCI DSS compliant for protecting data in transit?

No. Using a strong transport protocol is intended to help protect cardholder data during transmission over open, public networks, but PCI DSS compliance depends on how the protocol is implemented, configured, and validated, not on the version label alone. Requirement wording and numbering for protecting data in transit differ between PCI DSS versions, so confirm the specific applicable requirements against the current published standard. Transport encryption is also only one part of a broader set of controls and does not by itself address data at rest, storage of sensitive authentication data, or other requirements.

How should I approach cipher suite and configuration choices when enabling TLS 1.3?

Follow current, authoritative configuration guidance for your platform and libraries rather than relying on defaults alone. Review supported cipher suites, key exchange settings, and forward secrecy behavior, and align choices with your organization's security policy. Because acceptable configurations evolve as new weaknesses are found, revisit these settings periodically and confirm them against the current guidance in effect at the time of deployment.

How do I keep TLS 1.3 secure over time after it is deployed?

Maintain a patching and update process for the TLS libraries and the servers and applications that use them, since many disclosed issues affect implementations rather than the protocol design. Monitor vendor advisories and vulnerability sources relevant to your stack, track configuration drift, and re-test after changes. Ongoing maintenance is intended to reduce exposure but does not eliminate risk on its own.

What should I consider for backward compatibility when moving to TLS 1.3?

Assess whether clients, intermediaries, and downstream systems in your environment support TLS 1.3, and plan for negotiation behavior where mixed versions exist. Where older protocol versions must be phased out, coordinate the change to avoid unexpected connection failures, and confirm that any allowed fallback does not weaken your intended security posture. Validate the end-to-end path, including load balancers and proxies, rather than testing only the endpoint.

How can I verify that TLS 1.3 is actually being used and functioning as intended?

Test the negotiated protocol version and configuration using tools appropriate to your platform, and confirm results across the relevant network paths, including any terminating devices such as load balancers or proxies. Include this verification in your change and testing processes so that intended settings are confirmed after deployment and after any subsequent updates. Keep evidence of testing where it supports your validation obligations under the applicable standard.

Common misconceptions

Deploying TLS 1.3 makes the connection immune to vulnerabilities and eliminates the need for ongoing patching.

The protocol design addresses several weaknesses found in earlier versions, but implementations of TLS 1.3 in libraries and products can still be affected by disclosed vulnerabilities over time. Practitioners must track advisories and apply updates rather than treating any version as permanently free of defects.

Using TLS 1.3 alone satisfies PCI DSS requirements for protecting cardholder data.

TLS helps protect cardholder data in transit, but PCI DSS compliance depends on how the protocol is configured, how certificates and keys are managed, which cipher suites are enabled, and how the control is validated. It is intended to reduce exposure of data in transit and does not by itself address storage, authentication, or other requirement areas.

TLS 1.3 encryption is a form of tokenization and therefore removes systems from PCI DSS scope.

TLS provides encryption of data in transit and is distinct from tokenization, truncation, masking, and hashing, which transform stored data differently. The effect of any of these on PCI DSS scope depends on implementation and validation, not on the label. Encryption in transit does not remove endpoints that transmit, process, or store cardholder data from scope.

Best practices

Enable TLS 1.3 where supported while confirming that your configuration and cipher selections are validated against the current published PCI DSS version rather than assuming a fixed requirement number.

Track security advisories and CVEs affecting the specific TLS libraries and products you deploy, and apply vendor patches promptly, since TLS 1.3 implementations can still be subject to disclosed vulnerabilities.

Manage certificates and ephemeral key exchange configurations carefully so that the forward secrecy properties intended by the protocol are actually realized in production.

Disable legacy protocol versions and weak cipher suites where feasible, and document exceptions, so that fallback to weaker negotiation is limited.

Treat TLS as one layer that helps reduce exposure of cardholder data in transit, and combine it with controls addressing storage, authentication, and monitoring rather than relying on it in isolation.

Validate that sensitive authentication data is not retained after authorization regardless of transport encryption, since protecting data in transit does not authorize storage of prohibited elements.