The lingering ambiguity that has prevented enterprises from acting on quantum security for several years should no longer be an excuse. In August 2024, NIST finalized its three major post-quantum cryptography standards. Each of these has a different role within the cryptographic stack. The question is no longer which standards to bid time for. This is how to map every standard with the appropriate systems and deploy in an optimal order.
Why it matters is that these three standards are not interchangeable. Each solves a different problem, resides in a different part of the infrastructure, and has a different performance & compatibility impact.
The 3 Standards and What Each Does
FIPS 203, FIPS 204, and FIPS 205 split the post-quantum cryptography problem functionally, similar to the approach classical cryptography takes. It places the quantum safe encryption standards for enterprises in the context of how these standards will work with a transition away from quantum-vulnerable infrastructure. Before we can apply a standard, we must first understand what each covers and where one ends and the next begins.
- FIPS 203 (ML-KEM): Specifies the ML-KEM standard for key encapsulation. It provides a means for two parties to mutually establish a shared secret key across an insecure channel. This is currently the role played by RSA (and elliptic curve) Diffie-Hellman in TLS handshakes, IPsec IKE negotiations and other key agreement protocols. The ML-KEM scheme has three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, which provides increasing security with increasing computational cost. ML-KEM-768 is generally the balanced default for most enterprise deployments, with ML-KEM-1024 reserved for connections requiring the highest level of assurance.
- FIPS 204 (ML-DSA): Specifies digital signatures. ML-KEM is for shared secrets, while ML-DSA is for signing and verifying data; thus all of these use cases are actually the relevant standards when it comes to certificate issuance (like X.509), code signing, document signing, firmware authentication, identity assertion. ML-DSA also has three parameter sets which trade performance for security strength, named ML-DSA-44, ML-DSA-65 and ML-DSA-87.
- FIPS 205 (SLH-DSA): The second signature algorithm, based on hash functions rather than lattices, is specified in the FIPS 205 SLH-DSA standard. Finally, it provides a structure-independent backup for ML-DSA, so that organizations using SLH-DSA would remain secure should lattice-based signatures be affected by a cryptanalytic result. The tradeoff is the higher size of signatures. Most organizations will use ML-DSA as their primary signature algorithm and SLH-DSA for certain high-assurance signing scenarios where SLH-DSA’s conservatism is worth the size overhead.
Mapping Standards to Systems
The most common mistake in planning is treating the three standards as one big package deployed everywhere at once. In reality, each standard directs to an independent systems, and those systems differ in the urgency of migration from them.
Everything that does key exchange is an ML-KEM – TLS endpoints, VPN gateways, IPsec tunnels, HTTPS connections, and also every application that negotiates session keys over the network. These systems are the most vulnerable to harvest-now-decrypt-later attacks, and will be prioritized for early deployment. Hybrid ML-KEM deployments are already in browsers, and leading VPN & TLS libraries vendors are adding support.
ML-DSA thus maps to certificate authorities, code signing infrastructure, identity providers and any system that issues or verifies digital signatures. However, the urgency of signature migrations is slightly less severe than that of key exchange because captured signatures cannot be used retroactively in the same way harvested session keys can. Even so, root CA key lifetimes are long enough that planning for signature migration is not far off.
However, as you note, SLH-DSA maps to a more restricted set of use cases: firmware signing in hardware that will have very long operational lifetimes; document signing in tight contexts where regulatory requirements place the maximum level of cryptographic conservatism as priority one (e.g. Court Systems); and any signing workflow for which my organization has cause to consider hash-based security to be preferred over lattice-base security.
Practical Aspects of A Hybrid Deployment
In a hybrid, a post-quantum algorithm is executed in parallel with the classic algorithm during the same cryptographic operation so that communication remains secure as long as either of the two algorithms remain secure. So for key exchange, this often means running ML-KEM together with X25519 elliptic curve Diffie-Hellman. In the case of signatures, this means issuing certificates or signing artifacts under both ML-DSA and a classical signature scheme.
The ISACA enterprise PQC playbook identifies hybrid deployment as the practical starting point for any enterprise migration: adopt hybrid schemes for TLS and PKI first, establish PQC-ready developer trust chains, then scale progressively toward pure post-quantum configurations as the broader vendor and protocol ecosystem matures.
The hybrid deployment provides two-way zero risk. Given the presence of ML-KEM, an organization is safe against quantum adversaries. In fact, it is secure even against unforeseen future vulnerabilities of ML-KEM since the classical algorithm still exists as a backup. This means that hybrid is the prudent default for the transition period, regardless of how confident the organization is in the new algorithms.
The Sequence of Deployments That Make Sense
The adoption sequence that typically appears to mirror the different urgency levels combined with three standards, generally looks like: Hybrid ML-KEM is best suited for key exchange in TLS and VPN, as it matures earlier on vendor support than other schemes, plus has less exposure to harvesting today. As new certificate authority tooling is created to support this, code signing and certificate issuance with ML-DSA will follow. Cases for SLH-DSA: specific firmware and document signing use cases are the last ones because they benefit only when an organization has developed familiarity with the larger post-quantum algorithm family through experience with ML-DSA.
This sequence is not universal. Some organizations with set regulatory requirements, high-assurance government deployments, or long-lived OT and IoT systems may have a need to prioritize other standards or treat all three at once. What the order reflects is the urgency of harvesting threats for key exchange to signature use cases.
Vendor and Library Readiness
The first practical bottleneck that most organizations encounter is not optimal algorithm selection but rather the availability of code libraries. To use ML-KEM over a TLS connection, it is necessary to have a TLS library that supports overloading C (in order for the upper layers of the communication stack to be able to reach these with changes at lower layers). In order to deploy ML-DSA in a certificate, we must have one certificate authority that issues it and another validation chain that verifies its ownership.
The state of library readiness has made significant progress since 2024. 2025 OpenSSL releases post-quantum algorithm support, with ML-KEM, ML-DSA, and SLH-DSA now shipping as native TLS keyshares and defaults rather than experimental patches. Even hybrid key exchange implementations have been shipped in production by browser vendors. Cloud providers have already started enriching their key management and certificate services with post-quantum options. The key evaluation for each organization is which of its existing vendors and TLS, VPN, certificate and signing libraries have shipped FIPS-validated implementations or are still under development.
It is not only/just the question of algorithm selection; vendor assessment should happen in parallel, not after. The plan loss of an organization that selects ML-KEM-768 as its standard and subsequently finds that their TLS termination product has no implementation schedule is substantial time which could have been spent assessing alternatives or pressuring the vendor to produce a firm commitment.
Frequently Asked Questions
Which ML-KEM parameter set is best suited for most enterprise deployments?
For most use cases, ML-KEM-768 is your best bet as it provides security roughly equivalent to AES-192 at comfortably easy but reasonably efficient on commercial-off-the-shelf hardware in a typical server environment. MIL-KEM-1024 is well suited for high-assurance services where the additional security level justifies the performance overhead.
Does adopting FIPS 203 mean replacing TLS 1.3?
It is NOT a replacement of the TLS 1.3 protocol, it is simply deployed within it as a new key exchange mechanism. The rest of the handshake is then processed by TLS 1.3. Hybrid ML-KEM is not a successor or replacement of TLS 1.3; Integration requires only configuration changes and updating the TLS library to support hybrid ML-KEM.
How organizations select ML-DSA or SLH-DSA to use for signing.
Unless your app probably needs something different, ML-DSA is the right default: certificates, code signing, identity assertions. SLH-DSA is suitable for use when the separation from lattice-based mathematics needs to be at a structural level, which tends to be for firmware with long deployment lifetimes or extremely high-assurance signing contexts where metrics allow the larger signature size.