Choose X25519MLKEM768 unless a requirement points elsewhere. It is the only one of the three IETF hybrid groups marked recommended. Pick SecP256r1MLKEM768 when you need FIPS-approved mechanisms, and SecP384r1MLKEM1024 for high-security environments.
The three groups
The IETF TLS working group document on ECDHE and ML-KEM hybrids, which the datatracker page we fetched lists as a Proposed Standard dated August 2026, defines three groups for TLS 1.3.
- X25519MLKEM768, code point 4588: X25519 with ML-KEM-768. The only one marked as recommended.
- SecP256r1MLKEM768, code point 4587: NIST P-256 with ML-KEM-768. Intended for cases that need FIPS-approved mechanisms.
- SecP384r1MLKEM1024, code point 4589: NIST P-384 with ML-KEM-1024. Intended for high-security environments.
The document also obsoletes the earlier experimental Kyber768 code points. If a config still names those, update it.
How to decide
Start from your constraints, not from preference.
- Is there a compliance or procurement requirement to use only FIPS-approved mechanisms? Then use a NIST curve group, which the document says is intended for that case. Confirm against your actual validation requirements.
- Is there a high-security profile, such as a customer or agency mandate that names a higher strength? Use the P-384 and ML-KEM-1024 group.
- Otherwise use X25519MLKEM768, which is widely implemented and is the recommended default.
If your requirements are unclear, ask the people who own them in writing. Choosing the wrong group because of a guess costs more later than asking now.
Support and negotiation
Servers can offer several groups and clients choose among those they both support. A sensible configuration lists the preferred hybrid first, then others, then classical groups for older clients. Check how your TLS library orders preferences, because defaults vary.
OpenSSL 3.5, an LTS release from April 2025, added ML-KEM along with better support for multiple TLS key shares and group configuration. Other stacks have their own timelines, so verify each component in your path, including CDNs and load balancers.
What to measure after enabling
- Share of handshakes using each group.
- Handshake failure rate by client type.
- Latency at the 95th and 99th percentile for the first connection.
- Any middlebox complaints, as the larger key share makes handshake messages bigger.
When to review
Re-read the standards status when you plan changes. A document dated August 2026 may be revised, and NIST's own guidance continues to evolve. Put a review on the calendar instead of relying on memory.
Quick check
Why not use only the strongest group everywhere?
Higher strength costs performance and support is narrower. Match the choice to the requirement rather than defaulting to the largest.
Do I need to keep classical groups enabled?
For compatibility with clients that have not updated, usually yes during the transition. Retire them on a schedule once usage data supports it.
Safeguard's SBOM and dependency scanning lists the TLS libraries and versions in your projects, and the free scan at gold.safeguard.sh/scan is a quick first look.
Sources
Last reviewed: 19 October 2026.
