On 14 May 2026, NIST moved nine additional post-quantum digital signature candidates into the third round of evaluation. The list is not a shopping list for immediate production use. It is a signal that the signature side of post-quantum cryptography is still expanding beyond the first standards.
That matters because signatures show up in places where replacement is rarely quick: certificate chains, firmware images, package repositories, code-signing services, document workflows, secure boot, hardware roots of trust, and identity systems. Waiting for every future signature standard to settle before doing any architecture work is a costly form of delay.
What is already stable
NIST already finalized FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA in 2024. That gives teams enough ground to start inventory, testing, and policy design. The 2026 additional-signature process is about diversifying the longer-term portfolio, not cancelling the need to prepare now.
Where architects should focus
- Signer inventory: list every place the organization creates or verifies a signature.
- Lifetime: record how long signatures must remain valid and who depends on that validation.
- Update path: identify products where verification logic cannot be changed without firmware, hardware, or customer action.
- Size limits: test whether larger signatures or public keys break protocols, storage, certificates, bootloaders, QR codes, or message formats.
- Policy control: separate algorithm choice from application code wherever the architecture allows it.
The easy mistake: treating signatures like TLS ciphers
Key exchange can often be negotiated at connection time. Signatures are different. A device may need to verify an image years after it shipped. An archive may need proof long after the signing certificate changed. A bootloader may accept only a narrow signature format burned into an old trust chain.
That is why signature migration needs a stronger evidence base. Teams need test vectors, representative artifacts, failure-mode analysis, and a plan for old verifiers. A lab result that works on a new server is useful. It is not the same as a deployable migration path.
A sensible 2026 move
Create a signature migration map before choosing final algorithms for every use case. Mark where ML-DSA or SLH-DSA could fit, where standards are still maturing, where hybrid or parallel signatures may be needed temporarily, and where product constraints require redesign. That map gives security leaders something better than a promise: it gives them work packages.
Further reading: NIST May 2026 additional signatures update, NIST Post-Quantum Cryptography project.