NIST published IR 8610 in May 2026 and moved nine additional post-quantum digital signature candidates into a third evaluation round: FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, and UOV.
That is important news, but it is easy to misread. The new round is not a signal to wait. It is a signal that the post-quantum portfolio is maturing beyond the first production baseline.
The baseline is already here
The current standards baseline remains ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA for stateless hash-based signatures. These are the standards teams should be mapping against today. They are the algorithms that procurement, engineering, and risk teams can use to start inventories, pilots, and implementation planning.
NIST’s additional-signature process has a different purpose. It is looking for more algorithm diversity, including candidates that may be useful where current signatures have awkward size, speed, or trust-assumption trade-offs. The project page explains that NIST wanted additional schemes, especially beyond structured lattices, because the first signature portfolio was intentionally narrow.
Why signature diversity matters
Key exchange often gets the loudest attention because harvest-now/decrypt-later risk is easy to understand. Signatures are different. A quantum break against classical signatures would not mainly expose old traffic. It would attack trust: software updates, certificates, device identities, code signing, document signing, payment infrastructure, and administrative access.
In that world, algorithm diversity is not an academic luxury. It is resilience planning. If a single mathematical family develops an unexpected weakness, organisations need a way to move without redesigning every protocol and operating process. A broader standards portfolio gives future migration programmes more room to choose the right primitive for the right use case.
What to do now
- Keep current migration work anchored to published standards. Do not delay ML-DSA or SLH-DSA inventory and pilots because future candidates are being evaluated.
- Require crypto-agility in procurement. Vendors should explain how algorithm updates can be deployed without replacing the whole product.
- Separate signing use cases. Code signing, firmware signing, certificates, identity tokens, and documents have different performance, size, lifecycle, and audit needs.
- Track standards without betting on winners. The Round 3 candidates are not yet standards. They belong in watchlists, not hard-coded roadmaps.
The strongest 2026 posture is boring in the best way: deploy against current standards where appropriate, keep inventories current, make vendors prove upgrade paths, and track the next NIST round as portfolio intelligence.