NIST finalised three post-quantum cryptographic standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). A fourth algorithm, FN-DSA (FALCON-based, lattice signature scheme), is in development and expected to receive a FIPS designation, though no number had been assigned as of the August 2025 knowledge baseline, confirm current status before referencing it in procurement documentation. For a security architect implementing PQC migration, the question is not "which standard is best", it is "which algorithm is appropriate for this specific use case, with these specific performance and security requirements?" The selector answers that question. Find the right algorithm for your use case

What the NIST PQC Algorithm Selector Does

The selector is a use-case-based tool that maps your performance constraints, security requirements, and implementation context to the appropriate NIST-standardised post-quantum algorithm. Its input structure covers the decisions that actually drive algorithm selection in practice.

You identify your primary use case. The three categories the selector covers:

  • Key encapsulation (replacement for RSA and ECDH key exchange) maps to ML-KEM (FIPS 203)
  • Digital signatures with high performance requirements maps to ML-DSA (FIPS 204)
  • Digital signatures where stateless operation and conservative security assumptions are the priority maps to SLH-DSA (FIPS 205)

Beyond use case, the selector evaluates: key size and bandwidth constraints, signature size tolerances, computational performance requirements, implementation environment (server, embedded/IoT, HSM), and NIST security level (Level 1, Level 3, or Level 5, the three parameter sets offered across the PQC algorithm suite, not all five levels).

The output is a recommendation identifying the most appropriate algorithm with rationale and the relevant FIPS standard reference. This is an algorithm selection within the NIST PQC suite. It does not replace a full cryptographic architecture review. Algorithm selection is one step in a migration programme.

For background on FIPS 203, 204, and 205 and what they standardise, the linked article covers the full picture.

NIST PQC Algorithm Selection Matrix: use case mapping for ML-KEM, ML-DSA, and SLH-DSA ALGORITHM FIPS STANDARD NIST LEVELS USE CASES ML-KEM 768 / 1024 Key Encapsulation FIPS 203 from CRYSTALS-Kyber L1 L3 L5 L3 = ML-KEM-768 (recommended) TLS 1.3 key exchange VPN / IPsec SSH key agreement Encrypted messaging ML-DSA 44 / 65 / 87 Digital Signatures FIPS 204 from CRYSTALS-Dilithium L2 L3 L5 L3 = ML-DSA-65 (most deployments) Code signing Certificate signing (CA) Authentication tokens Document signing SLH-DSA Hash-based Stateless Signatures FIPS 205 Hash-function security only L1 L3 L5 Sig size 8-50 KB. Conservative use cases only. Firmware signing (long-lived) IoT device authentication High-assurance root CA Post-lattice fallback Highlighted level = recommended starting point for most enterprise deployments
NIST PQC algorithm selection matrix. ML-KEM (FIPS 203) for key encapsulation; ML-DSA (FIPS 204) for most digital signature use cases; SLH-DSA (FIPS 205) where conservative hash-only security assumptions are required or signatures are long-lived. Highlighted security level pills indicate the recommended starting point for most enterprise environments.

Understanding the NIST PQC Algorithm Landscape

ML-KEM (FIPS 203) is the key encapsulation mechanism standardised from CRYSTALS-Kyber. It replaces RSA and ECDH in key exchange. The recommended algorithm for TLS, VPN, and any protocol requiring a key establishment mechanism. Performance is strong across server and constrained environments.

ML-DSA (FIPS 204) is the digital signature algorithm standardised from CRYSTALS-Dilithium. High performance, suitable for most code signing, certificate signing, and authentication use cases. The default choice for signature migration in most enterprise environments.

SLH-DSA (FIPS 205) is the hash-based digital signature algorithm. It is substantially larger and generally slower than ML-DSA: SLH-DSA signatures range from approximately 8 KB (fastest parameter set) to approximately 50 KB (largest), compared with roughly 2 to 5 KB for ML-DSA. The algorithm's security rests only on the security of its underlying hash function (SHAKE or SHA-2), without any dependence on lattice problem hardness. This makes SLH-DSA the appropriate choice where the most conservative security assumptions are required and the deployment context can accommodate larger signatures and slower signing.

Most organisations default to ML-DSA for all signature use cases without examining whether their specific environment calls for SLH-DSA's harder security assumptions, that default is usually fine for enterprise IT infrastructure, but it is the wrong call for long-lived firmware signing or high-assurance code authentication.

For more on the NIST FIPS standards underlying these algorithms, the full standards article provides context.

Our tools are designed as directional tools only. Advice and standards are changing rapidly and although we update tools as new information is periodically released they are not designed as a replacement for expert advice. If your organisation results show high-priority exposure the next step is to contact our team or speak to a qualified expert member.

How to Use the NIST PQC Algorithm Selector

Step 1. Open the selector. No registration required.

Step 2. Select your primary use case. The decision point is key encapsulation, digital signatures, or both. If you are migrating TLS or VPN infrastructure, key encapsulation is your starting point. If you are migrating code signing or certificate infrastructure, you are in the signatures branch.

Step 3. If signatures: specify whether performance or conservative security assumptions are the priority. This is the ML-DSA versus SLH-DSA decision. For most enterprise signature use cases, certificate signing, authentication tokens, code signing on modern infrastructure. ML-DSA is the right answer. For long-lived firmware signing, on-board software authentication for embedded systems, or environments where the security guarantee needs to hold independent of lattice problem assumptions, SLH-DSA warrants evaluation despite the size cost.

Step 4. Set your implementation environment. Server (high compute available), embedded or IoT (constrained compute and memory), or HSM (hardware security module, which may have specific algorithm support constraints). Not all HSM vendors support all NIST PQC algorithms yet, the selector accounts for this constraint.

Step 5. Set your key size and bandwidth tolerance. Some environments have hard constraints on key or signature sizes. A network protocol with message size limits, for example, may not tolerate the upper range of SLH-DSA signatures. State the constraint and the selector will factor it in.

Step 6. Set your required NIST security level. The PQC algorithms offer parameter sets at Level 1 (security at least as hard to break as AES-128 in classical terms), Level 3 (at least as hard as AES-192), and Level 5 (at least as hard as AES-256). Levels 2 and 4 are not offered. For most enterprise use cases, Level 3 is the standard starting point; Level 5 is appropriate where the highest available security margin is required.

Step 7. Review the recommendation. The selector returns the appropriate algorithm with the specific FIPS standard reference and a note on the rationale. This output is suitable for attaching to a technical specification or compliance document.

How to Use Your Algorithm Recommendation

The selector produces a starting recommendation. Three practical steps to apply it:

Confirm vendor support. Not all cryptographic libraries and HSM vendors have shipped support for all NIST PQC algorithms. Before specifying an algorithm in a technical design, check your library vendor's release notes and your HSM vendor's roadmap. This is the step that most often delays implementation, discovering the gap after design is expensive.

Implement in hybrid mode during the transition period. NIST SP 800-227 (Recommendations for Key-Encapsulation Mechanisms, September 2025) describes hybrid key establishment approaches combining classical and quantum-safe algorithms, the selector recommendation should be implemented as the PQC component of a hybrid scheme during the transition period, not as an immediate standalone replacement. For National Security Systems, NSA's CNSA 2.0 guidance acknowledges hybrid schemes as appropriate during the transition period, with the direction of travel being full migration to CNSA 2.0 algorithms. NSA's posture is eventual full replacement, not indefinite hybrid operation.

Run the selector once per infrastructure layer. Key encapsulation and digital signatures produce different recommendations, and different layers of your environment (cloud services, on-premises servers, OT systems, HSM-protected key stores) may produce different results. The Algorithm Sunset Timer connects each recommendation to the deprecation timeline for your current algorithm, which is the paired question: when does the algorithm you are migrating from expire?

Discuss your results with a QSECDEF expert member. A directional assessment is the starting point, not the programme. If your results show high-priority exposure, the next step is a discussion about a structured migration programme with defined milestones. Request a consultation with our team or find a qualified expert member.