Encryption finding · Edge

No Forward Secrecy (SSL Labs Grade Capped at B): Fix It or Document It

Your scanner flagged no forward secrecy, or SSL Labs capped your grade at B. What it means, how to enable ECDHE, and how to document what can't change.

What the scanner said

No forward secrecyGrade capped to BForward secrecy not supported

Your server negotiates key exchange that depends on its long-term private key, such as static RSA. If that key is ever stolen, anyone who recorded your past traffic can decrypt it. Forward secrecy uses a fresh temporary key for each session (ECDHE or DHE) so past sessions stay protected.

Why it matters

Since March 2018, the SSL Labs server test caps the grade at B when a server does not support forward secrecy with the reference browsers. The report says so directly: This server does not support Forward Secrecy with the reference browsers. Grade capped to B.

Beyond the grade, forward secrecy limits the damage from a compromised key or a subpoenaed one, which is why assessors ask about it.

The fix

Offer ECDHE suites and prefer them, or offer nothing else. Every full TLS 1.3 handshake uses ephemeral key exchange, so enabling TLS 1.3 covers every client that supports it.

# nginx: TLS 1.2 suites limited to ECDHE, plus TLS 1.3
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

# Apache (mod_ssl); if you keep any RSA suite for old clients, add SSLHonorCipherOrder on
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384

# Other OpenSSL-based services: allow only ephemeral key exchange, then restart
CipherString = ECDHE+AESGCM:ECDHE+CHACHA20

# Windows Server (IIS, RDP): remove the TLS_RSA_WITH_* suites, then reboot
Get-TlsCipherSuite | Where-Object Name -like 'TLS_RSA_WITH_*' | ForEach-Object { Disable-TlsCipherSuite -Name $_.Name }

The ECDSA suites apply only if the server has an ECDSA certificate, and they do no harm otherwise. On Windows you can instead remove the TLS_RSA_WITH suites from the SSL Cipher Suite Order group policy. Static session-ticket keys weaken forward secrecy in practice, so rotate them or turn tickets off (ssl_session_tickets off; in nginx). SSL Labs doesn't grade this, but it is part of the protection. On a managed load balancer or CDN, choose a security policy that lists ECDHE suites first.

Verify. Enumerate what each listener offers.

nmap -sT -Pn --script ssl-enum-ciphers -p 443 <host>

A fixed host lists only ECDHE suites (names starting TLS_ECDHE_) under TLS 1.2, plus the TLS 1.3 suites. A host that still lists a suite starting TLS_RSA_WITH_ offers key exchange without forward secrecy. A quick openssl s_client test only shows the one suite your client negotiated, so it can miss RSA suites the server still offers. Rerun SSL Labs too (clear its cache), and keep the before and after output as the evidence that the finding is closed.

When you can't fix it

Some clients cannot negotiate ECDHE: very old embedded devices, legacy Windows clients, and older Java. Your named owner chooses one treatment.

Remediate by upgrading or replacing the client, with a dated plan.
Mitigate by keeping the non-forward-secret suites only on a separate, segmented listener for those clients, and offering ECDHE first everywhere else. Generate a new server key at every certificate renewal, which limits the traffic one stolen key exposes, and protect the key in an HSM or a managed key service so a theft is harder.
Accept with documented compensating controls: the clients that need it, why they can't change, the controls above, the owner, a review date, and a replacement date. Because forward secrecy is often a grade and assessor-preference item, this is the case where acceptance is most commonly reasonable.

The post Compensating Controls for Legacy Systems covers which controls carry weight and how to write the record an assessor accepts.

Where it lands in the Risk Register

Finding	Treatment	Owner	Evidence
Non-forward-secret key exchange negotiated on a named listener	Remediate, mitigate, or accept (the owner decides)	Named by you	Before and after scan output. Maps to PCI DSS 4.2.1 and NIST 800-53 SC-8, SC-12, and SC-13.

Common questions

What is forward secrecy in one sentence?

Each connection uses a fresh, temporary key exchange, so stealing the server's long-term private key later does not let anyone decrypt traffic that was recorded earlier.

Do I have to remove every non-forward-secret suite to lift the SSL Labs cap?

Not necessarily. Qualys said in its 2018 grading update that it applies no penalty if a server keeps suites without forward secrecy but never negotiates them with clients that can do better. Listing only ECDHE suites is the surest way to meet that, and every full TLS 1.3 handshake uses ephemeral key exchange.

I enabled ECDHE and the grade is still B. Why?

SSL Labs caps at B for several reasons and names the one that applies in the report. TLS 1.0 or 1.1 still enabled and no AEAD (GCM or ChaCha20) suites are the other common caps. Since 2025, a server without TLS 1.3 tops out at A-.

Is forward secrecy a hard compliance requirement?

NIST treats it as a strong preference. SP 800-52 Rev. 2 (section 3.3.1.1) tells servers to prefer ephemeral keys over static keys because they provide forward secrecy, and PCI DSS 4.2.1 asks for strong cryptography without naming it. Confirm with your assessor whether it is a named requirement or a finding you can accept.