Forward secrecy means each TLS session uses its own temporary keys, so stealing the server's long term private key later does not let an attacker decrypt traffic they recorded earlier. TLS 1.3 makes it mandatory. In TLS 1.2 you have to choose the right cipher suites.
The problem it solves
Imagine an attacker records encrypted traffic for a year. They cannot read it. Then they steal your server's private key. Without forward secrecy, that one key could unlock the whole archive, because the session keys were wrapped with it. This is called a record now, decrypt later attack, and it applies to any stolen or compelled key.
How it works
With ephemeral key exchange, client and server each generate a fresh key pair for the session and combine them to agree on a secret. The server's long term certificate key is used to sign the handshake and prove identity, not to protect the session secret. When the session ends, the ephemeral keys are discarded. There is nothing left to steal that could unlock the past.
What the standards say
RFC 8446 states that static RSA and Diffie-Hellman cipher suites were removed from TLS 1.3 and that all public key based key exchange mechanisms now provide forward secrecy. RFC 9325 says implementations must support and prefer cipher suites that provide forward secrecy, and says you should not negotiate static RSA key transport or static DH and ECDH suites in TLS 1.2.
Where it can still leak
- Session tickets. RFC 9325 says ticket keys must be rotated regularly, for example weekly, and old keys destroyed. If a ticket key lives for months on a fleet of servers, anyone who gets it can decrypt sessions that used those tickets.
- 0-RTT data. RFC 8446 says early data is not forward secret, because it is encrypted solely under keys derived from the offered pre-shared key.
- TLS terminated early. If a proxy decrypts traffic and forwards it in cleartext or with static keys inside your network, the forward secrecy of the outer connection does not protect the inner leg.
- Endpoint compromise. If an attacker owns the server while sessions are live, forward secrecy does not help. It protects past sessions, not current ones.
Checklist
- Disable static RSA key exchange suites in TLS 1.2.
- Prefer ECDHE suites with AES-GCM or ChaCha20 if you still serve TLS 1.2.
- Turn on TLS 1.3.
- Rotate session ticket keys on a schedule and on every fleet node together.
- Avoid enabling 0-RTT unless you have reviewed the replay risk.
- Check internal hops between load balancer and application.
Quick check
Does forward secrecy protect me if my certificate private key is stolen?
It protects recorded past sessions that used ephemeral key exchange. An attacker holding the key can still impersonate your server until the certificate is revoked or expires, so replace the key and certificate promptly.
Is forward secrecy the same as end to end encryption?
No. Forward secrecy is a property of how session keys are derived. TLS still ends at the server or proxy that terminates it.
Sources
Last reviewed: 19 October 2026.
