Forward secrecy reduces the risk that a later compromise of a long-term private key could expose previously recorded sessions. SSLBoard uses observed TLS versions and evidence of a forward-secret cipher for pre-TLS-1.3 connections to classify hosts.
The five classifications
| Classification | What SSLBoard observed |
|---|---|
| TLS 1.3 and legacy PFS | TLS 1.3 support plus a forward-secret cipher for an older TLS version. |
| Legacy PFS only | A forward-secret cipher for older TLS, with no TLS 1.3 observed. |
| TLS 1.3 only, with older versions | TLS 1.3 exists, but older versions are also offered without observed legacy PFS. Older clients are the concern. |
| Strict TLS 1.3 only | TLS 1.3 is the only observed version. This is kept separate from the older-client gap. |
| No PFS | Older TLS versions were observed without a reported forward-secret cipher. |
If neither usable version data nor legacy PFS evidence is available, the classifier cannot establish a bucket. Unknown evidence should not be described as a confirmed lack of support.
Read the scope carefully
Host classifications combine observations from that host’s endpoint results. They are useful for inventory, but a positive host-level classification does not certify every address or every possible negotiation. Inspect the detailed endpoint evidence where consistency matters.
An RSA certificate does not automatically mean forward secrecy is missing. Certificate authentication and key exchange are different parts of the connection. See key analysis.
What to change
Investigate whether the affected TLS terminator supports appropriate ephemeral key exchange for the older clients you still need, or whether those older protocol paths can be removed. Check the actual server configuration rather than assuming that enabling TLS 1.3 covers all clients.
Run a fresh scan and review both the forward secrecy classification and the protocol and cipher details. Confirm intended clients still connect after the change.