Which Regulation Applies to Me?
| You are... | Primary regulation | Key requirement | Urgency |
|---|---|---|---|
| US federal / defense / intelligence | CNSA 2.0 (NSA) | ML-DSA-87 + ML-KEM-1024 for NSS | Now — 2025 deadlines active |
| US commercial handling sensitive data | NIST PQC Standards | FIPS 203/204/205 algorithms | 2025–2027 recommended |
| EU / EEA | ETSI / BSI | Hybrid PQC for eIDAS, ETSI TS 119 312 | Hybrid by 2025, full PQC by 2030 |
| Financial services (PCI, SWIFT, banking) | PCI DSS 4.0 + sector guidance | Crypto-agility, risk-based PQC adoption | Crypto-agility now, PQC by 2028 |
| Healthcare (HIPAA) | HIPAA Security Rule | "Reasonable and appropriate" encryption | Risk assessment by 2026 |
| Telecom / 5G | 3GPP / GSMA | PQC for subscriber authentication | Standards in progress, 2027+ |
| Any sector, long-lived data | "Harvest now, decrypt later" | Encrypt sensitive data with PQC today | Now |
CNSA 2.0 Timeline (NSA)
For National Security Systems. Commercial systems should follow the same timeline as best practice.
Algorithm Mapping by Regulation
Use this table to pick algorithms that satisfy your regulatory requirements. All are available from the Qudo provider.
| Use case | CNSA 2.0 (NSS) | NIST (commercial) | ETSI / BSI (EU) | Qudo provider call |
|---|---|---|---|---|
| Digital signatures | ML-DSA-87 | ML-DSA-65 | ML-DSA-65 (hybrid with ECDSA) | provider.sign(data, key, "ML-DSA-65") |
| Key establishment (TLS) | ML-KEM-1024 | ML-KEM-768 | X25519MLKEM768 hybrid | provider.kemEncapsulate(pub, "ML-KEM-768") |
| Key establishment (VPN) | ML-KEM-1024 | ML-KEM-768 or 1024 | ML-KEM-768 hybrid | provider.kemEncapsulate(pub, "ML-KEM-1024") |
| Firmware / code signing | ML-DSA-87 | ML-DSA-65 or SLH-DSA-256s | ML-DSA-65 | provider.sign(hash, key, "ML-DSA-87") |
| Root CA / long-lived certs | ML-DSA-87 | SLH-DSA-SHA2-256s | SLH-DSA-SHA2-256s | provider.sign(cert, key, "SLH-DSA-SHA2-256s") |
| Symmetric encryption | AES-256 | AES-256 | AES-256 | Standard Java Cipher.getInstance("AES/GCM/NoPadding") |
| Hashing | SHA-384 / SHA-512 | SHA-256+ | SHA-256+ | Standard Java MessageDigest.getInstance("SHA-256") |
What Replaces What
| Classical (retire) | PQC replacement | FIPS | Portal service |
|---|---|---|---|
| RSA-2048/3072/4096 (signing) | ML-DSA-65 (or ML-DSA-87 for NSS) | 204 | Signing, REST API |
| ECDSA P-256/P-384 (signing) | ML-DSA-65 | 204 | dApp (dual-sig transition) |
| RSA/ECDSA JWT (RS256, ES256) | ML-DSA-65 JWT (alg: "ML-DSA-65") | 204 | REST API |
| ECDH / X25519 DH (key exchange) | ML-KEM-768 (or hybrid X25519MLKEM768) | 203 | VPN, Email |
| RSA key exchange (TLS <1.3) | ML-KEM-768 via TLS 1.3 | 203 | REST API |
| AES-128 | AES-256 (already quantum-safe) | 197 | All services |
| SHA-256 HMAC | SHA-384/512 (already quantum-safe) | 180-4 | N/A (no change needed) |
Recommended Migration Path
Prioritize by risk exposure. Start with what protects data in transit today ("harvest now, decrypt later" threat).
Now: Enable Hybrid PQC TLS (1 day)
Add X25519MLKEM768 to your NGINX/Apache TLS config. Zero application-code changes. Instant quantum-safe forward secrecy for all web traffic.
Next: Migrate Code Signing (1 week)
Replace ECDSA/RSA code signing with ML-DSA-65 via provider.sign(). Add to CI/CD pipeline.
Then: Migrate Authentication (2 weeks)
Replace RS256/ES256 JWT with ML-DSA-65 JWT. JWKS endpoint publishes ML-DSA public key. Client-side change: update the alg header.
Then: Migrate VPN / Key Exchange (2 weeks)
Replace DH/ECDH handshakes with ML-KEM-768/1024 encapsulation. Same tunnel cipher (AES-256-GCM). Identity with ML-DSA-65.
Later: Full PKI Migration (1–3 months)
Issue ML-DSA-65 certificates. Replace ECDSA server certs. Root CA with SLH-DSA-SHA2-256s for 20+ year validity.
Qudo Provider Coverage
Every algorithm required by CNSA 2.0, NIST, and ETSI is available from the Qudo Cryptographic Module.
FIPS 204 — digital signatures
FIPS 203 — key encapsulation
FIPS 205 — hash-based signatures
X25519MLKEM768, X448MLKEM1024
RSA3072+ML-DSA-65, P384+ML-DSA-65
Validation in progress
"Post-quantum cryptographic operations (digital signatures, key encapsulation) are performed by the Qudo Cryptographic Module, an OpenSSL FIPS provider implementing NIST-standardized algorithms ML-DSA (FIPS 204), ML-KEM (FIPS 203), and SLH-DSA (FIPS 205). The module is targeting FIPS 140-3 validation. Algorithm selection follows CNSA 2.0 guidance: ML-DSA-65/87 for signatures, ML-KEM-768/1024 for key establishment, AES-256-GCM for symmetric encryption. Hybrid key exchange (X25519MLKEM768) is used during the migration period for backwards compatibility."