The first post-quantum cryptography standards are finished, implementation guidance is maturing, and migration deadlines are taking shape. At the same time, NIST is still evaluating additional algorithms. That is not a contradiction. It is what a durable cryptographic portfolio looks like.
Organizations should not interpret continuing research as a reason to delay migration to the standards available now. Nor should they treat the first standards as a final algorithm set that can be embedded permanently into every product and protocol. The practical lesson is to move forward with an architecture that can change again.
The first standards are a foundation, not the end of the program
In August 2024, NIST finalized FIPS 203, FIPS 204, and FIPS 205. FIPS 203 specifies ML-KEM for key establishment. FIPS 204 specifies ML-DSA for digital signatures, while FIPS 205 specifies the hash-based SLH-DSA signature scheme.
Those standards provide concrete migration targets. They allow protocol designers, product vendors, agencies, and enterprises to stop treating PQC as a purely experimental topic. But standardizing algorithms is only one layer of adoption. Real systems also require safe implementations, validated modules, updated protocols, certificate and identity support, interoperability, performance testing, key-management changes, and operational evidence.
NIST’s National Cybersecurity Center of Excellence describes the migration as two connected workstreams: cryptographic discovery and interoperability testing. Its Migration to Post-Quantum Cryptography project emphasizes understanding where vulnerable public-key cryptography exists, then testing how standardized PQC implementations behave in commonly used technologies.
HQC adds diversity to the encryption portfolio
ML-KEM remains NIST’s recommended primary choice for general-purpose post-quantum key establishment. In March 2025, however, NIST selected HQC for future standardization as a backup. NIST’s HQC selection announcement explains the reason: HQC is based on error-correcting codes, while ML-KEM relies on structured-lattice mathematics.
That difference provides portfolio diversity. If future cryptanalysis were to weaken the mathematical foundation or implementation assumptions behind one family, a separately constructed alternative could provide another path. NIST explicitly says HQC is not intended to replace ML-KEM; it is meant to become a second line of defense.
The selection does not make HQC a finished federal standard today. NIST’s final IR 8545 documents its fourth-round evaluation and the decision to develop an HQC-based standard. Migration teams should track that work without substituting a selected candidate for an approved standard in policies that require FIPS algorithms.
Signature research is deliberately widening the field
NIST is also expanding the post-quantum signature portfolio. ML-DSA is intended for general use, and SLH-DSA provides a hash-based alternative. FN-DSA, derived from FALCON, remains under development as FIPS 206. Beyond those selections, NIST opened an additional signature process to explore different security assumptions and useful performance characteristics.
In May 2026, NIST advanced nine candidates—FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, and UOV—to the third evaluation round. The NIST announcement says this phase is expected to last approximately two years. The accompanying final IR 8610 explains that any eventual selections would augment—not invalidate—the standards already available.
This research is valuable because application requirements differ. Some environments prioritize smaller signatures, some faster verification, some conservative security assumptions, and others implementation simplicity. No single construction is automatically ideal for every device, protocol, trust model, or operational constraint.
Implementation guidance matters as much as algorithm names
A key-encapsulation mechanism is not interchangeable with the public-key encryption interfaces many engineers have used for years. Misunderstanding its security properties or composing it incorrectly inside a protocol can undermine the assurance expected from the underlying algorithm.
NIST finalized SP 800-227, Recommendations for Key-Encapsulation Mechanisms, in September 2025. It describes KEM definitions, properties, applications, and recommendations for secure use. Its existence is a useful reminder: selecting ML-KEM is not the same as deploying a secure ML-KEM-based system.
Migration programs need to track algorithm, parameter set, implementation, module validation, protocol profile, configuration, peer compatibility, and operating context. An inventory that records only “PQC enabled” discards the information needed to evaluate whether the deployment is appropriate and reproducible.
Crypto agility is an observable engineering capability
Crypto agility is often described as the ability to replace algorithms without a disruptive redesign. In practice, that ability depends on concrete design and operating choices:
- Algorithms and parameter sets are not hard-coded across application logic.
- Protocols can negotiate approved options without unsafe fallback behavior.
- Key, certificate, and trust-store lifecycles can support new formats and sizes.
- Dependencies and cryptographic providers can be identified and upgraded.
- Interoperability and performance can be tested before production rollout.
- Policy can distinguish approved, transitional, experimental, and prohibited states.
- The deployed state can be observed again after a change.
These are testable properties. A team can identify which products expose algorithm choices, which vendors control the implementation, which certificates or protocols create coupling, and which systems require replacement rather than configuration. That evidence turns “we are crypto agile” from an aspiration into a defensible claim.
What migration teams should do with evolving research
- Use approved standards for current migration decisions. Do not confuse an algorithm under evaluation or selected for future standardization with a completed FIPS.
- Track the portfolio, not just one algorithm. Record where ML-KEM, ML-DSA, and SLH-DSA are planned or deployed and where future alternatives may matter.
- Preserve implementation detail. Capture provider, module, version, parameter set, protocol, configuration, and validation status.
- Test the operating environment. Measure handshake size, latency, memory, certificate behavior, failure modes, and peer interoperability in controlled conditions.
- Separate policy states. Make approved production use, limited pilots, research candidates, and legacy exceptions visibly different.
- Design the next replacement path now. A successful PQC migration should make the following cryptographic transition less expensive, not lock in a new generation of brittle dependencies.
Progress and uncertainty can coexist
Continuing research does not weaken the case for migration. It strengthens the case for disciplined migration. The available NIST standards address urgent quantum risk, while the ongoing HQC and signature work adds diversity and application options to the future portfolio.
The durable operating model remains the same: discover deployed cryptography, reconcile it into a canonical inventory, evaluate it against current policy, take accountable action, and preserve proof. Vista Platform supports that loop; it does not select algorithms for an organization, perform every migration, or generate PQC keys.
The goal is not to predict which algorithm will be preferred in every environment a decade from now. It is to know where cryptography is used, understand why a choice was made, and retain the ability to change that choice when standards, research, or mission needs evolve.
Research status reviewed August 21, 2026. Candidate algorithms and draft standards may change; consult the linked NIST sources for current status.