What is Perfect Forward Secrecy (PFS)?

Perfect Forward Secrecy (PFS) is a property of a key-exchange protocol that generates each session’s encryption keys through a fresh Diffie-Hellman exchange, independent of any long-term private key. If an attacker later compromises that long-term key, they still cannot decrypt traffic captured earlier – each session’s keys die with the session.

Key takeaways

• PFS derives a fresh session key each time via Diffie-Hellman exchange.
• A compromised long-term key cannot decrypt past captured sessions.
• Configurable separately for IKE and IPsec security associations.
• Higher-numbered DH groups trade more compute for stronger secrecy.
• Versa lets you select a PFS group per tunnel, or disable it entirely.

On this page: Why it matters · How it works · Types · PFS & Versa · FAQ

Why is PFS important?

Without PFS, all session keys trace back to one long-term key – a certificate’s private key or a static preshared key. If that key is stolen, an attacker who has been quietly recording encrypted traffic can decrypt every session that used it, retroactively. This is the “harvest now, decrypt later” threat: capture ciphertext today, wait for the key to become available.

PFS closes that window. Because each session negotiates its own ephemeral key, recovering the long-term key achieves nothing against traffic already captured. For VPNs, SD-WAN overlays, and SASE tunnels carrying years of sensitive traffic, that limits a key compromise to the sessions still active – not a retroactive breach of everything ever sent.

What is PFS?

PFS works by generating a fresh Diffie-Hellman key pair for every key-exchange round, instead of deriving keys from a static secret. Both peers exchange DH public values, each combines its own private exponent with the peer’s public value to compute a shared secret, and that secret seeds the session’s encryption keys. The private exponents are ephemeral – generated in memory, used once, and discarded – never written to disk, never derived from the long-term identity key.

Because the shared secret depends on two independently generated ephemeral values, knowledge of the long-term key does not help recover it later. In IKE this happens at initial SA establishment and at every rekey, so a compromise partway through a long-lived tunnel exposes only the current key interval, not the tunnel’s whole history. Strength scales with the group selected: larger modulus or higher-order elliptic-curve groups resist future attacks. Selecting “No PFS” skips the exchange, trading retroactive-decryption protection for a faster handshake.

Types of PFS

PFS is implemented through Diffie-Hellman groups, which fall into two families. Classic (MODP) groups exchange over a finite field defined by a large prime modulus – Groups 1, 2, 5, 14, 15, and 16 use modulus sizes from 768 to 4096 bits, with larger moduli costing more CPU per handshake. Elliptic-curve (ECP) groups – Groups 19, 20, 21, 25, and 26 – achieve equivalent or stronger security with smaller keys and faster computation, which is why newer deployments favor them.

A second axis is where PFS applies. IKE PFS protects the control-channel rekey; IPsec PFS protects the data-channel rekey, the keys that encrypt traffic. A deployment can enable one, both, or neither, and the two need not use the same DH group. “No PFS” is a configurable option, used when a lightweight handshake matters more than retroactive-decryption resistance – appropriate only for low-sensitivity traffic.

PFS & Versa

On VOS devices, PFS is a configurable field within the IKE and IPsec settings for Versa SASE Client tunnels, set independently for the IKE and IPsec security associations. Administrators select a Diffie-Hellman group – Group 1 through Group 26, spanning modulus-based and elliptic-curve groups – or choose “No PFS” to skip the exchange.

The same configuration surface appears whether the secure access service is deployed for Secure SD-WAN or NGFW use cases, so the setting is consistent across product lines. Because the two groups are set separately, an administrator can require a strong elliptic-curve group for the control-channel rekey while relaxing it for the data channel. Reserve “No PFS” for legacy scenarios where the exchange’s CPU cost is unacceptable.

Frequently asked questions

What is Perfect Forward Secrecy, in simple terms?

PFS means every encrypted session gets its own one-time key, generated fresh rather than derived from a long-term secret. If that secret is ever exposed, past sessions stay unreadable, because their keys were never stored anywhere and cannot be reproduced from it.

What is the difference between Diffie-Hellman and PFS?

Diffie-Hellman (DH) is the key-exchange algorithm itself. PFS is a property achieved by using DH ephemerally – a new key pair per session or rekey instead of a static one. DH without ephemeral keys does not, by itself, provide PFS.

Does enabling PFS slow down connections?

Yes, slightly. Each PFS exchange requires generating a fresh DH key pair and computing a new shared secret, adding CPU overhead versus reusing keys. Elliptic-curve groups minimize this cost; on modern hardware the overhead is rarely noticeable outside very high-volume rekeying.

Should I enable PFS on IPsec tunnels?

In almost all cases, yes. The retroactive-decryption protection PFS provides is a security best practice for VPN and SD-WAN tunnels, and modern hardware absorbs the extra computation easily. Disable it only for constrained legacy devices where the handshake cost is genuinely prohibitive.

Which Diffie-Hellman group should I choose for PFS?

Prefer elliptic-curve groups, such as Group 19, 20, or 21, over classic modulus groups – they deliver equal or stronger security with less computation. Avoid Group 1 and Group 2, whose small moduli are considered weak by current cryptographic standards.

More on PFS

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about PFS, these are worth looking at next.