Quantum computing threatens today’s public‑key cryptography (RSA/ECC). Adversaries can harvest sensitive traffic now and decrypt it later once capable quantum systems arrive, putting long‑lived data and credentials at risk. With post‑quantum standards finalized and government timelines published, SaaS providers need to begin migration planning and phased adoption immediately to protect data durability, compliance, and customer trust.
What changed recently
- NIST finalized the first post‑quantum cryptography (PQC) standards:
- FIPS 203 (ML‑KEM, based on CRYSTALS‑Kyber) for key establishment; FIPS 204 (ML‑DSA, based on CRYSTALS‑Dilithium) and FIPS 205 (SLH‑DSA, based on SPHINCS+) for digital signatures, published Aug 13, 2024.
- Additional algorithms in the pipeline:
- NIST selected HQC as a backup KEM in Mar 2025, with draft/final standards expected 2026–2027, strengthening resilience against single‑family weaknesses.
- Government migration timelines are set:
- NSA’s CNSA 2.0 roadmap targets quantum‑resistant National Security Systems by 2035, with milestones beginning as early as 2025 and new acquisitions required to support CNSA 2.0 by Jan 1, 2027.
Why this matters for SaaS
- Harvest‑now, decrypt‑later risk
- Any data with multi‑year confidentiality needs (PII, health/financial records, IP, auth materials, backups) is vulnerable if protected only by RSA/ECC today.
- Compliance and procurement pressure
- Public‑sector and regulated buyers are starting to ask for PQ‑readiness; CNSA 2.0 and NIST FIPS make requirements concrete for vendor assessments and future audits.
- Ecosystem interoperability
- Browsers, TLS, SSH, VPNs, code signing, and PKI will progressively adopt PQC; SaaS vendors must interoperate during hybrid periods (classical+PQC) without breaking clients.
What to adopt and where
- Key establishment
- Plan migration from ECDH/RSA‑KEM to ML‑KEM (Kyber) once supported in TLS/IPsec/QUIC and KEM‑TLS profiles; use hybrid key exchange during transition to preserve compatibility.
- Digital signatures
- Move from ECDSA/RSA to ML‑DSA (Dilithium) for server identities, artifacts, and tokens; use SLH‑DSA (SPHINCS+) where conservative, hash‑based assurance is preferred (e.g., long‑term code signing).
- Backup KEM readiness
- Track HQC as an alternate KEM to diversify beyond lattice assumptions; plan for crypto‑agility to swap KEMs as standards finalize.
Migration blueprint for SaaS (12–24 months)
- Inventory and risk rank
- Catalog all cryptography in use: TLS endpoints, mTLS, SSH, VPN, databases, KMS/HSM, code signing, JWT/OIDC, S/MIME, backups, firmware signing; tag data with confidentiality lifetimes to prioritize PQC for long‑lived secrets and archives.
- Build crypto‑agility
- Abstract crypto calls behind well‑typed interfaces; support algorithm negotiation and hybrid modes; ensure certificate chains, CSRs, OCSP, and CT logs can carry PQC algorithms and larger keys/signatures.
- Pilot hybrid TLS/mTLS
- Test KEM‑TLS (hybrid X25519+ML‑KEM) in canaries; measure handshake latency, packet sizes, CPU, and error rates; validate CDN/WAF/proxy compatibility and fallback behavior.
- Update PKI and code signing
- Stand up a PQC‑capable CA; issue test certs with ML‑DSA; pilot double‑signing of artifacts and containers (classical+PQC) and verify supply‑chain tools handle larger signatures.
- Data at rest and backups
- Wrap data keys with PQC‑ready key‑encapsulation or deploy PQC‑capable KMS/HSM gateways; re‑encrypt long‑lived archives and secrets likely to outlive the classical window.
- Protocol and vendor coordination
- Coordinate with browser, OS, DB, CDN, and identity vendors on PQC roadmaps; require PQC support in new procurements per CNSA‑aligned milestones.
- Monitoring and governance
- Add cryptography SBOMs to track algorithms/params; run “crypto drills” to rotate algorithms; publish a trust page section on PQC posture for customers and auditors.
Engineering considerations and trade‑offs
- Performance and payload size
- Expect larger keys/ciphertexts and signatures (especially SPHINCS+); benchmark CPU, handshake times, and bandwidth, and tune caches and record sizes accordingly.
- Backward compatibility
- Maintain hybrid modes and graceful degradation for older clients; stage rollouts behind feature flags with canary cohorts.
- Storage and logs
- Ensure monitoring, CT logs, and telemetry systems can handle larger certs and signatures; adjust limits in proxies and message buses.
- Security posture
- Maintain classical hardness (AES‑256/GCM, SHA‑384/512) alongside PQC; avoid premature deprecation of proven symmetric primitives while upgrading asymmetric ones.
Governance, compliance, and communication
- Policy updates
- Update cryptographic policy to name ML‑KEM/ML‑DSA/SLH‑DSA targets, hybrid requirements, and deprecation timelines for RSA/ECC in external interfaces; align with CNSA 2.0 milestones where applicable.
- Vendor requirements
- Add PQC support to RFPs and security questionnaires; require roadmap evidence for TLS, PKI, VPN, S/MIME, and code signing components.
- Customer trust
- Communicate “harvest‑now, decrypt‑later” risk and roadmap; offer PQC opt‑in endpoints for sensitive tenants; share benchmarks and compatibility guidance.
90‑day starter plan
- Days 0–30: Assess and plan
- Crypto inventory, data lifetime mapping, and control owners; choose pilot domains (edge TLS, artifact signing); open discussions with CDN/IdP/KMS vendors on PQC timelines.
- Days 31–60: Pilot and validate
- Stand up a PQ‑capable test PKI; enable hybrid KEM‑TLS in a canary region; double‑sign one artifact class; measure latency/size impacts and client compatibility.
- Days 61–90: Govern and communicate
- Draft PQC policy and deprecation plan; add PQC requirements to procurement; publish a trust page update and customer FAQ; schedule quarterly reviews tied to NIST/NSA updates.
Executive takeaways
- The standards are here: NIST finalized ML‑KEM (Kyber) and ML‑/SLH‑DSA (Dilithium/SPHINCS+) in Aug 2024 and selected HQC in 2025, removing excuses to wait.
- Government clocks are ticking: CNSA 2.0 sets milestones from 2025–2035 that will cascade into enterprise requirements and procurement checklists.
- Act now: inventory cryptography, build crypto‑agility, pilot hybrid TLS and PQ signatures, and coordinate with vendors; communicate clearly to customers about harvest‑now, decrypt‑later risk and the migration roadmap.
Related
How vulnerable are current SaaS systems to quantum computer attacks
Why should SaaS companies urgently adopt quantum-resistant encryption now
How will quantum-safe encryption impact SaaS data security strategies
What risks does delaying quantum-proofing pose for SaaS providers
In what ways can SaaS benefit from NIST’s new post-quantum standards