FIPS 203 defines three ML-KEM parameter sets. NIST's draft transition report maps ML-KEM-512 to 128 bits of security strength (category 1), ML-KEM-768 to 192 bits (category 3) and ML-KEM-1024 to 256 bits (category 5). Higher strength costs performance. Pick the one your protocol or policy names, and otherwise pick deliberately.
What the standard says
FIPS 203, published 13 August 2024, specifies ML-KEM with three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. NIST states they offer increasing security strength, with lower performance as strength rises.
NIST IR 8547 (initial public draft) lists them in a table with security strength and security category. Its table labels contain typos in the draft, but the values are consistent: 128 bits and category 1, 192 bits and category 3, 256 bits and category 5.
How to choose
Do not choose in a vacuum. Start with what constrains you.
- Protocol or profile. A protocol specification or a regulator may name a set. Follow it.
- Policy target. If your policy says you need roughly AES-192 or AES-256 equivalent strength, map to 768 or 1024.
- Performance and size budget. Larger parameter sets mean larger keys and ciphertexts, which matters on constrained devices and in packet-limited protocols. Measure with your own library.
- Interoperability. What your peers and libraries support matters more than a small strength difference.
If none of these decide it, many teams default to the middle option as a balance, but check what your protocol stack already expects before deciding. I did not confirm a vendor-neutral recommendation from the NIST pages I fetched, so treat this as a decision method, not an official rule.
What not to do
- Do not hard-code sizes. Keys and ciphertexts differ by parameter set. Use library constants.
- Do not mix a high-strength KEM with a weak symmetric cipher. The data cipher also sets your overall strength. NIST's FAQ says AES with 128, 192 or 256 bit keys can continue to be used.
- Do not roll your own implementation. Use a maintained library and check the version for known issues.
Testing checklist
- Round-trip test with each parameter set you plan to support.
- Negative tests with corrupted ciphertexts. A KEM implementation should not reveal the failure through different behavior.
- Handshake size tests through proxies and load balancers.
- Version pinning and a plan to update the library, since NIST's FIPS 203 page notes an issue will be corrected in a future revision.
Make it configurable
Keep the parameter set in configuration. If your policy changes or a better option appears, you want a config change and a rollout, not a rewrite.
Quick check
Which ML-KEM parameter set is the strongest?
ML-KEM-1024, mapped by NIST's draft to 256 bits of security strength and category 5.
Does a higher parameter set make the whole system stronger?
Only the key establishment part. The symmetric cipher, signatures and implementation quality also set the real strength.
Sources
Last reviewed: 19 October 2026.
