Transport Layer Security (TLS) is a cryptographic protocol that protects data sent between two systems over a network. It encrypts the traffic so eavesdroppers cannot read it, checks that it has not been altered, and lets the client confirm the identity of the server it is talking to. TLS is the "S" in HTTPS and secures online banking, card checkouts, mobile apps, email and the connections between financial institutions' systems.
TLS is the successor to Secure Sockets Layer, and many people still say "SSL" when they mean TLS; the older name is covered at Secure Sockets Layer (SSL). It is standardized by the Internet Engineering Task Force (IETF). TLS protects data in transit between two points; it differs from end-to-end encryption, where only the final recipient can decrypt, and from encryption of stored data.
TLS in plain terms
Picture phoning your bank. Before discussing your account you want to be sure you have reached the real bank and not an impostor, and you want the line to be private so nobody listening can follow the conversation. TLS does both for computers: the bank shows an identity card vouched for by a trusted issuer, and the two sides then agree a secret code that only they understand.
The padlock in a browser's address bar means that code is in use. It shows the conversation is private and that the website really owns its address. It does not prove the website is honest; a fraudster's site can have a padlock too.
From SSL to TLS 1.3
Netscape developed SSL in the mid-1990s to make online shopping possible. SSL 2.0 and SSL 3.0 had design flaws, and the IETF published TLS 1.0 in 1999 as an improved, standardized version. TLS 1.1 followed in 2006 and TLS 1.2 in 2008. TLS 1.3, published as RFC 8446 in August 2018, removed outdated algorithms, made forward secrecy mandatory and cut the handshake to a single round trip, making connections both faster and safer. SSL 3.0 was formally deprecated in 2015 after the POODLE attack, and TLS 1.0 and 1.1 were deprecated by RFC 8996 in March 2021. As of 2026, TLS 1.2 and 1.3 are the versions in normal use.
How a TLS connection works
A TLS session begins with a handshake:
- The client says hello. It lists the TLS versions and cipher suites it supports and, in TLS 1.3, sends its share of a key exchange.
- The server proves its identity. It returns a digital certificate containing its public key, signed by a certificate authority the client already trusts, and proves it holds the matching private key with a digital signature.
- Both sides derive session keys. Using an ephemeral Diffie-Hellman exchange, they compute the same secret without ever sending it, then derive fresh symmetric keys for the session.
- Encrypted traffic flows. Data is encrypted with a fast symmetric cipher such as AES, and each record carries an integrity check, so tampering or replay is detected.
Each step relies on standard cryptography: public-key methods for identity and key agreement, a hash function for integrity, and symmetric encryption and decryption for the data itself. Normally only the server is authenticated. In mutual TLS (mTLS), the client presents a certificate too, so each side knows exactly which machine it is connected to.
TLS in banking and payments
TLS sits underneath almost every digital financial service:
- Card payments. The Payment Card Industry Data Security Standard (PCI DSS) requires strong cryptography whenever cardholder data crosses public networks, and SSL and early TLS have not been acceptable for this since 30 June 2018. Checkout pages and the calls from a merchant to its payment gateway run over TLS.
- Online and mobile banking. Login pages, app traffic and the one-time codes used in strong customer authentication (SCA) travel over TLS.
- APIs and open banking. Every application programming interface (API) call between a fintech and a bank is encrypted with TLS. Open banking frameworks in the UK and elsewhere, building on PSD2, commonly require mutual TLS with registered certificates, so a bank API can identify the third-party provider at the connection level before any authorization decision is made.
- Back-office links. Connections to processors, card networks and payment systems usually add private networks or VPNs on top of, or instead of, public-internet TLS.
In the United States, NIST guidance for US federal systems (SP 800-52 Rev. 2) requires servers to support TLS 1.2 and, from 1 January 2024, TLS 1.3, and bank supervisors expect institutions to retire weak protocols as part of managing cybersecurity risk.
Limits and common failures
TLS protects data only while it travels. Once it arrives, it is decrypted and must be protected by other controls such as access control and encryption at rest. A TLS connection to a fake site is still a secure connection to the wrong party, which is why phishing pages routinely show a padlock. TLS also cannot help if a user's device is infected or if a customer is tricked into approving a payment.
Most real-world TLS failures come from configuration rather than the protocol: expired certificates that take services offline, servers still offering old versions or weak ciphers, mobile apps that fail to validate certificates properly, and stolen private keys. Good practice is to support only TLS 1.2 and 1.3, automate certificate renewal, monitor certificate transparency logs for certificates issued in the organization's name, and test configurations regularly as part of security hardening. TLS is necessary for almost all data security on networks, but it is never sufficient on its own; strong authentication of users is a separate layer.