What is perfect forward secrecy?
Perfect forward secrecy, often shortened to forward secrecy or PFS, is a property of a key exchange: each session's encryption keys come from temporary values that are discarded when the session ends. Because those values are never stored and are never protected by the server's long-term private key, an attacker who later steals that private key still can't decrypt traffic they recorded earlier. Each session's keys would have to be broken separately.
The problem PFS solves
Picture an attacker who records a company's encrypted web traffic for a year and then steals the web server's private key, through a breach, a careless backup or a memory-leak bug such as Heartbleed in 2014.
- Without PFS: older TLS cipher suites used RSA key transport. Each client encrypted the session secret with the server's RSA public key, so the stolen private key unlocks every recorded session.
- With PFS: the session keys came from an ephemeral Diffie-Hellman exchange. The server's private key only signed that exchange to prove the server's identity, so stealing it reveals nothing about past sessions.
How it works: ephemeral Diffie-Hellman
In DHE, or ECDHE for the elliptic curve version, both sides generate a fresh Diffie-Hellman key pair for each session, exchange the public halves, compute the same shared secret and derive the session keys from it. Afterward they discard the ephemeral private values. The final E in DHE and ECDHE stands for ephemeral, and it is the detail that signals forward secrecy. RSA key transport and static Diffie-Hellman don't provide it.
You can read the key exchange in a TLS 1.2 cipher suite name. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 uses ECDHE, so it has forward secrecy; RSA here only authenticates the server. TLS_RSA_WITH_AES_128_CBC_SHA has no DHE or ECDHE, so it relies on RSA key transport and has no forward secrecy.
Running openssl s_client -connect portal.example.com:443 -brief against a server shows the ephemeral key for that session; many OpenSSL versions print it as a line such as Server Temp Key: X25519, 253 bits, though the label varies by version.
Where you find PFS
TLS 1.3 removed RSA key transport, so every certificate-based TLS 1.3 handshake uses ephemeral Diffie-Hellman and forward secrecy is no longer optional there. In TLS 1.2 it depends on configuration: servers should offer only ECDHE or DHE suites with AES-GCM or ChaCha20-Poly1305. SSH uses ephemeral key exchange by default. IPsec offers PFS as a setting that runs a fresh Diffie-Hellman exchange each time tunnel keys are renewed, and it should be enabled with a strong group.
What PFS doesn't protect
Forward secrecy protects past sessions only. A stolen private key still lets an attacker impersonate the server until the certificate is revoked, and PFS does nothing if an endpoint is compromised while a session is live. It also doesn't stop harvest now, decrypt later attacks by a future large quantum computer, which could break the Diffie-Hellman exchange itself; that is the job of post-quantum key establishment such as ML-KEM, which some browsers already combine with X25519.
Perfect forward secrecy on the CompTIA Security+ exam
PFS belongs to SY0-801 objective 1.3, with key exchange and encryption in transit. Wording such as an attacker who later obtains the private key must not be able to decrypt previously captured traffic, or compromising one session key must not expose other sessions, points to perfect forward secrecy, and the fix is to require ECDHE or DHE cipher suites or TLS 1.3. Distractors include longer RSA keys, which make the key harder to break but don't protect past traffic once the key is stolen; certificate revocation, which stops impersonation but not decryption of old recordings; and key escrow, which keeps a copy of keys and is close to the opposite idea.