Forward secrecy (PFS): the cipher property that protects past traffic
The scenario PFS is built for
Imagine an attacker quietly records your encrypted traffic for months, unable to read any of it. Then, one day, they get hold of your server's private key. Without forward secrecy, that single key unlocks everything they captured — every login, every session, retroactively. With forward secrecy, the recorded traffic stays unreadable. The stolen key is simply the wrong key for old conversations.
That is the entire point of PFS: it limits the blast radius of a key compromise to the future, not the past.
How it works, briefly
In an older key exchange, the same long-term private key was used to protect the session secret. Steal that key once and you can derive the secret for any session you recorded.
Forward secrecy breaks that link. Each connection performs an ephemeral key exchange — ECDHE, elliptic-curve Diffie-Hellman ephemeral — that generates a fresh, temporary key pair just for that session. The session secret is derived from those throwaway keys, not from your long-term private key, which is only used to prove your identity. The temporary keys are discarded when the connection ends and were never written to disk anywhere. There is nothing left to steal later, so a captured session cannot be reopened — even by someone holding your private key.
TLS 1.3 makes it the default
If your site speaks TLS 1.3, you already have forward secrecy: the protocol removed the non-PFS key exchanges entirely, so every TLS 1.3 connection is forward-secret by design.
On TLS 1.2, PFS is available but optional. You get it when your server prefers ECDHE cipher suites. You lose it if the server still allows old RSA key-exchange suites and a client negotiates one. So on 1.2 it comes down to your cipher ordering and which suites you have left enabled.
What to actually configure
- Enable TLS 1.3 and let it be preferred. This is the cleanest path to universal PFS.
- On TLS 1.2, prefer ECDHE suites and remove static
RSAkey-exchange suites from the list. - Drop legacy protocols — TLS 1.0 and 1.1 are deprecated and pull in weak options.
- Do not hand-tune ciphers blindly. Most modern web servers and managed platforms ship sane defaults; the failure mode is usually an old config that was never revisited.
If you are on a managed host, a CDN, or a platform like Vercel, Netlify or a typical PaaS, forward secrecy is almost certainly on already. The sites that miss it tend to be self-managed servers running a config copied from a tutorial years ago.
Confirm it rather than assume it
Forward secrecy is invisible from the browser — the padlock looks identical whether you have it or not. The only way to know is to inspect the negotiated cipher suites your server actually offers. An automated scan checks your TLS configuration end to end, including whether your connections are forward-secret, so scan your site and confirm a stolen key could never reopen your past traffic.