FIPS 204 and FIPS 205 Explained — Post-Quantum Digital Signatures for Businesses
FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) are NIST's quantum-safe digital-signature standards. Learn how they replace RSA and ECDSA signatures, when to use each, and what they mean for your business.
NIST's post-quantum standards cover more than key exchange. While FIPS 203 (ML-KEM) protects the handshake that sets up an encrypted connection, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) protect the identity side: the digital signatures that prove a server, document, software update, or transaction really came from who it claims.
This matters because the RSA and ECDSA signatures used everywhere today break under Shor's algorithm just as badly as RSA encryption does. If your business signs code, issues certificates, approves transactions, or authenticates APIs, the migration to quantum-safe signatures is not optional.
Here is what FIPS 204 and FIPS 205 do, how they differ, and how to choose between them.
What FIPS 204 and FIPS 205 replace
Digital signatures do three jobs in modern infrastructure:
- Authentication — prove identity during a TLS handshake (the certificate chain).
- Integrity — prove a document, package, or message was not altered after signing.
- Non-repudiation — bind an action to a signer in a way they cannot later deny.
Today those jobs are done by RSA signatures and ECDSA/EdDSA signatures. A quantum computer running Shor's algorithm can forge any of them in practical time. That means a future attacker could impersonate your website, tamper with your signed updates, or repudiate transactions protected only by classical signatures.
FIPS 204 and 205 are the replacements. They are built on math problems that, as far as we know, quantum computers do not solve efficiently.
FIPS 204 — ML-DSA (CRYSTALS-Dilithium)
ML-DSA is the primary replacement for RSA and ECDSA in most systems. It is fast to generate keys, fast to sign, and fast to verify. Its security is based on the hardness of structured lattice problems, the same family used by ML-KEM.
Where ML-DSA fits
- TLS certificates and certificate authorities
- Code-signing pipelines
- Document signing and e-signatures
- API authentication tokens and signed webhooks
- Blockchain and ledger transactions that need high throughput
Trade-offs
ML-DSA signatures and public keys are larger than ECDSA but smaller than SLH-DSA. A typical ML-DSA-65 signature is about 3,300 bytes, and a public key is about 1,900 bytes. That is larger than a 64-byte Ed25519 signature, but well within the budget of modern networks, certificates, and storage systems.
The main operational concern is not size — it is statelessness. Like RSA and ECDSA, ML-DSA is stateless: you can use the same key to sign an unlimited number of messages without leaking secret material. That makes it a drop-in replacement for most existing signature workflows.
FIPS 205 — SLH-DSA (SPHINCS+)
SLH-DSA is the conservative option. It is a hash-based signature scheme built only on the security of cryptographic hash functions like SHA-256. It does not rely on lattices at all. If you trust SHA-256 but worry that someday a quantum algorithm could break lattice assumptions, SLH-DSA is your hedge.
Where SLH-DSA fits
- Long-term trust anchors and root certificates
- Firmware and bootloader signatures where the key must last decades
- High-assurance environments that prefer conservative cryptography
- Any system where signature size is less important than algorithmic diversity
Trade-offs
SLH-DSA signatures are large — roughly 7,800 bytes for the smaller parameter set and up to 49,000 bytes for the most conservative. Public keys are small, around 60 bytes, but the signing process is slower and each signature is bulky.
Because of the size and speed cost, SLH-DSA is not a wholesale replacement for ECDSA in performance-sensitive protocols like TLS. It is better thought of as a backup trust anchor and a diversification play.
ML-DSA vs SLH-DSA at a glance
| Factor | ML-DSA (FIPS 204) | SLH-DSA (FIPS 205) |
|---|---|---|
| Underlying math | Structured lattices | Hash functions only |
| Signature size | ~3,300 bytes | ~7,800–49,000 bytes |
| Speed | Fast | Slower |
| Key size | ~1,900 bytes public | ~60 bytes public |
| Best use | Everyday signatures, TLS, code signing | Root certs, firmware, long-term anchors |
| Quantum assumption | Lattice problems are hard | Hash functions are one-way |
| State | Stateless | Stateless |
The right answer for most organizations is not one or the other — it is both, used at different layers.
How businesses should plan the signature migration
The migration from RSA/ECDSA to ML-DSA and SLH-DSA follows the same inventory-first pattern as the key-exchange migration:
- Inventory every signature in your stack. TLS certificates, code-signing keys, document-signing workflows, API signatures, internal microservice auth, and any blockchain or ledger uses.
- Classify by lifetime. A certificate that rotates every 90 days faces less quantum risk than a root certificate or a signed firmware image that must be trusted for 10+ years.
- Start with hybrid signatures. Combine a classical signature (RSA/ECDSA) with a quantum-safe one (ML-DSA) so a break in either algorithm does not break trust. This is the same hybrid logic used for TLS key exchange.
- Use SLH-DSA for the crown jewels. Root certificates, long-lived trust anchors, and anything where you want algorithmic diversity should get SLH-DSA.
- Update your PKI and certificate policies. Your CA tooling, HSM firmware, and certificate templates must support the new algorithms. Many enterprise PKI products are adding ML-DSA support in 2025–2026.
- Test everything. Signature sizes affect packet MTU, certificate chains, header limits, and storage quotas. Run real traffic through hybrid signatures before flipping them on in production.
FAQ
Can I use ML-DSA for TLS certificates today?
Some CAs and browsers are beginning to support hybrid certificates that include both ECDSA and ML-DSA public keys. Full production deployment depends on your CA, your clients, and your compliance requirements. The tooling is maturing rapidly in 2025–2026.
Is SLH-DSA too big for TLS?
For most TLS handshakes, yes. The signature size adds meaningful overhead to every connection. SLH-DSA is better suited to code signing, firmware, root certificates, and other places where the signature is fetched infrequently and verified once.
Do I need both FIPS 204 and FIPS 205, or just one?
Most organizations should standardize on ML-DSA for operational signatures and reserve SLH-DSA for their highest-value trust anchors. Using both gives you algorithmic diversity without forcing SLH-DSA's size penalty onto high-volume workflows.
How does this relate to FIPS 203 (ML-KEM)?
FIPS 203 protects key exchange — the part of a protocol that agrees on a shared secret. FIPS 204 and 205 protect authentication and integrity through signatures. A fully quantum-safe TLS connection uses ML-KEM for the key exchange and ML-DSA (or SLH-DSA) for the certificate signatures.
Bottom line
FIPS 204 and FIPS 205 complete the post-quantum toolkit. ML-DSA is the workhorse that will replace RSA and ECDSA signatures in everyday systems. SLH-DSA is the conservative backstop for the trust anchors that must survive decades of uncertainty.
The businesses that start inventorying their signature usage now — and testing hybrid certificates and code-signing pipelines — will be the ones that can flip the switch without panic when quantum pressure becomes real. The ones that wait will be racing to re-sign everything under fire.
Want to see where your business stands today? Run Secuur's free quantum-risk scan and get an A–F grade with a migration roadmap in about 20 seconds.