RSA, ECDSA and DSA signatures are in scope for post-quantum migration. The two final NIST signature standards are ML-DSA in FIPS 204 and SLH-DSA in FIPS 205. This guide explains where each belongs and how to start migration without breaking existing trust chains.
Primary post-quantum digital signature standard
Most future signature workflows where ecosystem support, throughput and operational practicality matter.
Stateless hash-based digital signature standard
High-assurance or lower-frequency signing workflows that need a conservative non-lattice option.
Encryption migration gets most of the attention because of harvest-now-decrypt-later risk. Signatures have a different failure mode: if a quantum-capable attacker can forge a trusted signature, software updates, certificates, signed documents and identity assertions become harder to trust.
Signature migration is also operationally different from TLS key exchange. A signature can be stored, archived, countersigned, audited and verified years after it was created. That means the verifier population matters as much as the signing key.
The practical objective is crypto-agility: know where signatures are used, know how long they must remain trustworthy, and make sure signing and verification systems can accept NIST-standardised post-quantum options when the ecosystem is ready.
| Decision point | ML-DSA | SLH-DSA |
|---|---|---|
| Standard | FIPS 204 | FIPS 205 |
| Algorithm name | ML-DSA | SLH-DSA |
| Original submission | CRYSTALS-Dilithium | SPHINCS+ |
| Cryptographic family | Module-lattice digital signatures | Stateless hash-based signatures |
| Typical role | Primary general-purpose PQC signature candidate | Conservative backup or high-assurance option |
| Migration fit | Start here for most signing pilots | Use where the assurance case justifies size and performance trade-offs |
Do not limit discovery to TLS certificates. Post-quantum signature migration affects any workflow where authenticity, integrity or non-repudiation depends on RSA, ECDSA or DSA.
For many real systems, the first production step will not be a sudden replacement of RSA or ECDSA. It will be a period where classical and post-quantum signatures coexist. NIST describes this as dual, hybrid or composite signatures where more than one component signature is verified.
Dual signatures are most useful when legacy verifiers must continue to work, but new verifiers can start collecting post-quantum evidence. They are not free: they add size, policy complexity, validation logic and review effort. Use them where the compatibility problem justifies the cost.
Start with controlled workflows before introducing post-quantum signatures into public trust chains. Package repositories, internal release pipelines and signed evidence logs are better early candidates than uncontrolled customer verifier fleets.
ML-DSA is the NIST-standardised digital signature algorithm derived from the CRYSTALS-Dilithium submission. For new requirements, use the FIPS 204 name and parameter sets rather than older draft names.
SLH-DSA is the NIST-standardised stateless hash-based digital signature algorithm derived from SPHINCS+. It is useful as a conservative option with different trade-offs from ML-DSA.
No. Start by inventorying signature systems and piloting post-quantum signatures where signer and verifier compatibility can be controlled. Long-lived code, documents, firmware and identity chains deserve earlier planning.
No. ML-KEM is for key establishment, while ML-DSA and SLH-DSA are for digital signatures. Most migration plans need both categories, but they affect different systems.
Use the free scanner to collect public TLS evidence, then expand the same inventory process to certificates, signing keys, release pipelines, suppliers and long-lived verification workflows.
A PQC guide is more useful when it is attached to current evidence. Create a free account, add a public domain now or later, and keep a repeatable baseline for TLS, security headers and visible post-quantum readiness.
Prefer to scan first? Open the free quantum security scanner.