A post-quantum program should not begin by ordering teams to deploy all three NIST algorithms everywhere. ML-KEM, ML-DSA, and SLH-DSA perform different functions, have different object and signature sizes, and depend on different protocol and product ecosystems. A useful PQC migration sequence starts with what cryptography does in each system, how long the protected data or signed object must remain trustworthy, and which counterparties must interoperate. It then pilots standardized constructions through controlled paths before retiring quantum-vulnerable mechanisms.
The urgency is asymmetric. An adversary can collect encrypted traffic today and attempt decryption later, so long-lived confidentiality may require early key-establishment changes. Signature migration protects future authenticity and integrity, but long-lived firmware, roots, archives, and evidence also demand lead time because verifiers may remain deployed for decades. Sequence by exposure and dependency, not by whichever library first adds a convenient algorithm name.
Anchor the program in the current standards baseline
NIST finalized the principal standards in August 2024: FIPS 203 specifies ML-KEM for establishing shared secrets; FIPS 204 specifies ML-DSA digital signatures; and FIPS 205 specifies stateless hash-based SLH-DSA signatures. Use the standardized names and parameter sets. Pre-standardization Kyber or Dilithium implementations and identifiers are not automatically interoperable with final ML-KEM and ML-DSA.
For U.S. federal civilian agencies, OMB M-26-15 now directs execution of prioritized PQC migration under the Quantum Computing Cybersecurity Preparedness Act and June 2026 executive direction. Other organizations are not governed by that memorandum, but suppliers serving government should expect concrete inventory and migration demands. Always reconcile NIST standards with national, sector, contractual, and validated-module requirements that apply to the deployment.
Assign each algorithm to the right cryptographic job
ML-KEM is a key-encapsulation mechanism, not a general encryption algorithm and not a signature. Two parties use it within a protocol to establish shared secret keying material, which then feeds approved symmetric cryptography. NIST SP 800-227 provides recommendations for securely implementing and using KEMs, including key types, protocol context, authentication, and hybrid considerations. Migrating a TLS exchange, message-encryption envelope, or VPN requires a standardized protocol construction, not a raw call to ML-KEM followed by improvised key derivation.
ML-DSA and SLH-DSA authenticate and protect integrity through digital signatures. ML-DSA is expected to serve many general signature uses, with three parameter sets. SLH-DSA provides a stateless hash-based design based on different assumptions, but its signatures are substantially larger and performance characteristics differ by parameter set. Treat SLH-DSA as an algorithm with specific resilience and diversity benefits, not a universal backup to enable without measuring bandwidth, storage, verification, and device constraints.
| Standard | Function | Candidate uses | Migration constraint |
|---|---|---|---|
| ML-KEM / FIPS 203 | Establish shared secrets | TLS, VPN, secure messaging, key wrapping protocols | Needs protocol integration, authentication and counterparty support |
| ML-DSA / FIPS 204 | Digital signatures | Certificates, code, documents, services and artifacts | Larger keys and signatures; verifier and format support |
| SLH-DSA / FIPS 205 | Stateless hash-based signatures | Selected long-lived or diversity-sensitive signing uses | Very large signatures and distinct performance profile |
| Symmetric cryptography | Encrypt and authenticate data | Data at rest and session protection | Usually remains, while public-key establishment changes |
| Classical public key | Current key agreement and signatures | Legacy interoperability during transition | Quantum-vulnerable and eventually retired |
Turn the cryptographic inventory into migration waves
Inventory cryptographic functions in protocols, applications, libraries, certificates, HSMs, KMS services, devices, firmware, data formats, backups, supplier products, and partner interfaces. Record algorithm and parameter, purpose, key lifetime, protected-data lifetime, signature-validation lifetime, endpoint and verifier population, owner, supplier, upgrade path, and applicable validation. Link each occurrence to business service and information class. Edilec's cryptographic inventory guide provides a foundation; this sequence adds algorithm-specific destinations and readiness gates.
Group occurrences into use-case families: interactive transport, store-and-forward confidentiality, internal service authentication, public web PKI, code and firmware signing, document signing, machine identity, remote access, and long-lived roots. Rank each family by confidentiality or authenticity lifetime, collection exposure, external dependencies, replacement lead time, scale, and recovery consequence. Unknown cryptography should become an owned discovery item, not be scored as low priority.
| Wave | Selection logic | Typical work | Exit evidence |
|---|---|---|---|
| 0: Discover | Unknown use or ownership | Inventory, data lifetime, protocol and supplier mapping | Owned use-case record with destination |
| 1: Enable | Shared libraries and platforms block all later work | Upgrade crypto libraries, APIs, observability and test labs | Approved algorithms selectable without production default |
| 2: Protect early | Long-lived confidentiality or closed managed ecosystem | Hybrid key establishment pilots and controlled messaging | Interoperability, performance and downgrade evidence |
| 3: Migrate signatures | Long-lived releases, firmware or internal trust | Dual signing, verifier rollout and trust-store changes | New verification path works across lifecycle |
| 4: Scale | Ecosystem standards and products are ready | Fleet rollout by cohort and supplier | Coverage, reliability and incident readiness |
| 5: Retire | Counterparties and recovery paths support new state | Disable issuance and negotiation of legacy algorithms | No unauthorized fallback or stranded object |
Sequence ML-KEM around protocol readiness
Start ML-KEM pilots where both endpoints are managed and the protocol construction is specified. Measure handshake or envelope size, latency, CPU, memory, entropy, error behavior, key lifecycle, network fragmentation, middleboxes, logs, and fallback. Hybrid key establishment can preserve a classical component while adding post-quantum protection, but only a reviewed combiner and negotiated protocol deliver the intended property. Inventory what the system actually negotiated, not merely what configuration allowed.
Prioritize channels carrying data whose secrecy lifetime extends beyond the expected migration horizon, especially when traffic is readily collectible. Do not overlook stored encrypted objects whose content-encryption keys are wrapped with quantum-vulnerable public-key mechanisms. Plan rewrapping or re-encryption, backup handling, and key escrow where applicable. Key establishment migration does not require replacing strong symmetric encryption wholesale; it changes how symmetric keys are established or protected.
Sequence ML-DSA and SLH-DSA around verifier populations
For signatures, deploy verification capability before depending on new signatures. Inventory every verifier: boot ROMs, firmware, agents, package managers, CI systems, browsers, proxies, HSM clients, mobile apps, partners, archives, and offline recovery tools. Establish algorithm identifiers, certificate and key formats, signature containers, timestamps, revocation, and long-term-validation behavior. An issuer that can generate ML-DSA while half the fleet cannot verify it has created an outage path, not migration.
Use dual artifacts, multiple signatures, composite structures, or parallel trust chains only where formats and relying parties define their semantics. Decide whether acceptance requires both signatures or either one, how partial validation is reported, and what an attacker can strip. Evaluate SLH-DSA for cases where hash-based diversity justifies its size and operational cost. Do not label it automatically safer for every application; parameter choice, implementation, key protection, and complete protocol behavior still matter.
Prepare platforms, vendors, and operational controls
Upgrade shared cryptographic libraries, HSM and KMS interfaces, certificate services, secrets distribution, observability, policy engines, and test infrastructure before application deadlines. Require algorithm and parameter agility through configuration and typed interfaces rather than scattered constants. Preserve algorithm identifiers in telemetry. Key generation, backup, import, export, rotation, destruction, signing throughput, and failure handling must work under realistic concurrency and recovery, not just a command-line demonstration.
Vendor roadmaps should name final standards, products, versions, interfaces, supported parameter sets, validated configurations, interoperability targets, preview and general-availability dates, upgrade requirements, and support lifetimes. Distinguish experimental implementation from production support and production support from validated use. Put test access, change notice, data export, migration assistance, and end-of-support obligations into procurement rather than relying on quantum-ready marketing.
Use production gates and rehearse rollback
Define gates for standards correctness, known-answer and negative tests, protocol interoperability, performance budgets, security review, validated-module needs, monitoring, incident response, backup, and rollback. Roll out by endpoint cohort and observe negotiated algorithms, failures, latency, retries, and fallback. A rollback may restore availability but also restore quantum-vulnerable protection; authorize it as a time-bound risk action, record affected data or signatures, and preserve a route back to the post-quantum state.
Test malformed keys and ciphertexts, signature failures, unsupported identifiers, oversized messages, fragmentation, certificate-chain growth, partial upgrades, expired roots, restored backups, and disaster-recovery systems. Practice emergency algorithm disablement. Crypto agility is demonstrated when an algorithm can be changed safely under pressure while operations and evidence remain coherent, not when a configuration file contains multiple names.
Key takeaways
- Sequence by cryptographic function, data or signature lifetime, dependency lead time, and ecosystem readiness.
- Use ML-KEM only through specified key-establishment protocols and deploy signature verification before issuance.
- Pilot final standards and parameter sets; do not assume pre-standardization implementations interoperate.
- Treat hybrid and dual-signature designs as explicit protocol choices with downgrade and stripping analysis.
- Gate production on interoperability, platform lifecycle, observability, rollback, and validated-use requirements.
Frequently asked questions
Which algorithm should migrate first?
There is no universal first algorithm. Long-lived confidentiality may prioritize ML-KEM protocol work, while a device maker with decades-long firmware verification may prioritize signature architecture. Shared platform enablement often precedes both.
Should every deployment use SLH-DSA as a backup?
No. Its hash-based design provides useful assumption diversity, but signature size and performance can be significant. Select it for justified use cases after format, device, network, storage, and operational testing.
Does PQC replace AES or hashing?
The immediate migration primarily targets quantum-vulnerable public-key algorithms. Approved symmetric cryptography and hashing remain central, though security-strength, key-size, and policy choices must still follow applicable guidance.
Conclusion
ML-KEM, ML-DSA, and SLH-DSA provide standardized destinations, not an automatic migration plan. The plan emerges from cryptographic purpose, protected lifetime, verifier and counterparty dependencies, platform readiness, and controlled retirement. Enable common infrastructure, protect the highest-time-horizon risks, prove interoperability, then scale by use-case family. That sequence converts quantum readiness from an inventory exercise into observable production change without confusing algorithm availability with system security.