ASD ISM 1372 Ephemeral DH or ECDH key establishment for TLS connections
What it says
The ephemeral variant of DH or ECDH is used for key establishment of TLS connections.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishTLS sessions must agree their keys with ephemeral Diffie-Hellman or elliptic curve Diffie-Hellman, so each connection gets a fresh key that a stolen server key cannot unlock later.
When a browser, API client or server opens a TLS connection, the two ends have to agree on a secret session key before any encrypted data flows. There are two broad ways to do this. The older way (RSA key transport) has the client encrypt the session key with the server's long-term certificate key. The way this control requires is a Diffie-Hellman exchange, either finite-field DH or elliptic curve ECDH, in its ephemeral form (DHE or ECDHE), where both sides generate a brand-new, throwaway key pair for that one connection and derive the session key from it. The reason this matters is forward secrecy. With RSA key transport, anyone who records your encrypted traffic today and later obtains the server's private key (through a breach, a misconfigured backup, a court order or a future cryptographic advance) can go back and decrypt every session that key ever protected. With ephemeral DH or ECDH, the session key is never sent over the wire and the temporary key pairs are discarded once the handshake finishes, so a compromised long-term key does not expose past sessions. The control covers every TLS connection the organisation is responsible for, not just public web sites: internal services, APIs, mail transport, VPN tunnels running over TLS and administrative interfaces all count.
Free. Save your status, tasks and notes.
Why it matters
If TLS connections are established with static key exchange instead of ephemeral DH or ECDH, every recorded session remains decryptable for as long as the server's private key survives. A single certificate key compromise, whether by intrusion, insider theft or a lost backup, retrospectively exposes potentially years of captured traffic including credentials, session tokens and sensitive data. The organisation also fails ASD ISM expectations for TLS configuration, which weighs on IRAP assessments and on any security classification argument that relies on TLS to protect data in transit.
How to implement
Platform or infrastructure engineers inventory every TLS endpoint the organisation operates (web servers, load balancers, reverse proxies, API gateways, mail servers, VPN concentrators, database listeners, management interfaces and cloud listener policies) using asset records and network or certificate discovery scans, so nothing is missed.
Security architects publish a TLS configuration standard that mandates ephemeral key exchange: TLS 1.3 enabled, and for TLS 1.2 an explicit allow-list of ECDHE and DHE cipher suites with all RSA key transport and static DH or ECDH suites removed, plus approved curves (for example P-256 or P-384) and DHE group sizes.
System administrators apply the standard through managed configuration (Ansible or Puppet roles, hardened container base images, cloud security policies such as load balancer TLS policies, and group policy for Windows Schannel) rather than per-host edits, so every new endpoint inherits the ephemeral-only cipher list automatically.
Application and DevOps teams add an automated TLS check to their deployment pipeline, for example running testssl.sh or sslyze against the new endpoint and failing the release if any non-ephemeral key exchange suite is negotiable.
The security operations team schedules a recurring external and internal TLS scan of all endpoints, raises a ticket for any endpoint that offers non-ephemeral key exchange, and tracks remediation to closure with an exception process for legacy systems that genuinely cannot comply.
Keep it running
In practice this control is met through cipher suite and protocol configuration on every TLS endpoint. TLS 1.3 uses ephemeral (EC)DHE for all full handshakes, and PSK-only resumption should be disabled so resumed sessions also perform an (EC)DHE exchange, so enabling TLS 1.3 and disabling older protocols is the simplest route. Where TLS 1.2 must remain for compatibility, restrict the cipher suite list to suites whose key exchange component is ECDHE or DHE and remove all suites that use RSA key transport, static DH or static ECDH key exchange.
Day to day, the work is keeping that configuration consistent across a sprawl of endpoints: web servers, reverse proxies, load balancers, API gateways, mail servers, database listeners, message brokers, container ingress controllers, cloud load balancer policies and appliance management pages. Vendor defaults and product upgrades can silently re-enable non-ephemeral suites, so configuration should be baselined in templates or policy objects rather than set by hand on each host. Regular scanning with a TLS assessment tool catches drift, and new services should be checked before they go live. Also pay attention to the strength of the ephemeral parameters (curve selection for ECDHE and group size for DHE), since weak DH parameters undermine the benefit of using the ephemeral variant.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the organisation's TLS configuration standard or hardening baseline.
Look at
Check whether it explicitly requires ephemeral DH or ECDH (DHE or ECDHE) key exchange for all TLS connections and lists the permitted cipher suites.
Good evidence
The standard names ECDHE and DHE as the only permitted key exchange methods, excludes RSA key transport and static DH or ECDH suites, and applies to all TLS endpoints rather than only public web sites.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the inventory of TLS endpoints in scope.
Look at
Compare the inventory against asset registers, DNS records and recent certificate issuance to see whether internal services, APIs, mail and management interfaces are included.
Good evidence
The inventory is current, covers internal and external endpoints, and each entry maps to a configuration owner and a last-scan date.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the most recent TLS scan results (for example testssl.sh, sslyze or an external scanning service report) for a sample of endpoints.
Look at
Review the list of negotiable cipher suites and the key exchange method reported for each protocol version.
Good evidence
Every negotiable suite uses ECDHE or DHE key exchange, the scan reports forward secrecy as supported for all clients, and TLS 1.3 is offered where supported.
- Check 4 of 5What an auditor asks for
Ask for
Ask to see the live configuration of a sampled web server, load balancer or proxy, or the configuration management template that generates it.
Look at
Read the cipher suite string, protocol settings and DH parameter or curve settings.
Good evidence
The configuration matches the published standard, contains no RSA key transport or static DH suites, and is applied from a managed template rather than edited by hand.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence of how configuration drift is detected and handled, such as recurring scan schedules, tickets raised for non-compliant endpoints and any approved exceptions.
Look at
Trace a recent finding from detection through remediation, and read the justification and compensating measures on any exception.
Good evidence
Non-ephemeral key exchange findings are detected within the scan cycle, remediated within a defined timeframe, and exceptions are rare, time-limited, risk-accepted by an appropriate owner and reviewed periodically.
Mappings
Closest match in ISO/IEC 27001: A.8.24, Effective use of cryptography and key management, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.24.
ISM-1372 requires TLS connections to use ephemeral DH or ECDH for key establishment to provide forward secrecy. This maps to Annex A 8.24 because selecting and enforcing appropriate cryptographic mechanisms and managing their use (including protocol and key-exchange choices) is part of effective cryptography governance. Annex A 8.24 is broader and policy/programmatic, while ISM-1372 is a specific technical requirement for TLS key exchange.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.