Post-Quantum Cryptography Migration

Because the deadlines now exist on paper, and your largest customers are reading them.

NIST released its first three finalized post-quantum standards on August 13, 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). In March 2025 it selected HQC as a backup encryption algorithm built on different math than ML-KEM, with a final standard expected in 2027. NIST's own guidance is to keep migrating to ML-KEM now rather than wait for it.

The date that matters most for planning is in the draft NIST IR 8547. It proposes that RSA, ECDSA and elliptic-curve key establishment at the 112-bit security level be deprecated after 2030, and that quantum-vulnerable public-key algorithms be disallowed after 2035. In Canada, the Canadian Centre for Cyber Security's roadmap for the Government of Canada, published June 2025, asks departments for initial migration plans by April 2026, high-priority systems migrated by the end of 2031, and everything else by the end of 2035.

None of those dates bind a private SaaS company directly. They bind your buyers. Federal agencies, banks, insurers and defense suppliers will push the same timelines down into procurement, and the questionnaire line that surprised that CTO is the first sign of it.

Start with shelf life, not algorithms. An attacker who records your encrypted traffic today can only hurt you later if the data is still worth something when they can finally read it. That single question sorts most of the work.

Here is the opinion a lot of vendors will dispute: for most SaaS companies, only the top two or three rows justify any spend before 2028. The rest arrives through upgrades you already pay for. If you already keep a data classification scheme as part of your data security and privacy program, add one column for "years of confidentiality required" and you have done half the prioritization.

The joint CISA, NSA and NIST Quantum-Readiness fact sheet puts the cryptographic inventory at the center of every migration plan, and the Canadian roadmap calls the same step "identification." For a 30 to 200 person SaaS company, the inventory is a spreadsheet, not a platform purchase. Across our assessments, it usually has these columns:

Do not forget the less visible places. Code-signing keys, JWT signing for your API, SAML assertions, SSH keys to production, and encrypted backups sent offsite all rely on public-key cryptography. If your engineers already practice DevSecOps, dependency scanning and certificate tooling will surface much of this automatically.

The inventory pays off even if quantum computers stay a decade away. Auditors under SOC 2 and ISO 27001 already expect you to manage cryptographic keys and know where encryption protects sensitive data. You are building evidence you need anyway.

Crypto-agility means you can swap an algorithm by changing configuration or a library version, without rewriting the application. It is the single design property that turns a future migration from a project into a patch.

In practice, three rules cover most of it. Do not hard-code algorithm names or key sizes in application logic. Terminate TLS in a small number of places you control or that your cloud provider maintains. Wrap signing and encryption calls behind one internal library so a change happens once, not in forty services. Add those three rules to your secure design standard and your architecture review checklist, and new systems stop adding to the backlog.

One sentence of policy does a lot of work here: "New systems and vendors must support algorithm changes without code rewrites." It belongs in the policy set your governance, risk and compliance program already maintains.

Most of your quantum exposure sits in products you do not build. The good news: CISA's January 2026 product categories list found that cloud platforms, collaboration tools, web browsers and servers, and full-disk encryption products already ship post-quantum standards. The catch, as CISA notes, is that most categories have implemented PQC for key agreement but not yet widely for digital signatures and authentication. "We support PQC" usually means half the job.

Add these questions to your vendor review and your annual reassessment:

Treat vague answers the way you would treat a vague answer about encryption at rest: as a finding, logged with a follow-up date. If you sell to US national security customers, note that NSA's CNSA 2.0 requires new acquisitions for national security systems to be CNSA 2.0 compliant from January 1, 2027, so your answers to these questions become your customers' compliance evidence.

This is the sequence we use with SaaS clients. It deliberately puts paperwork ahead of engineering, because the paperwork tells engineering where to look.

For most teams this fits inside an existing part-time security leadership engagement rather than a separate project. Our Virtual CISO services start at the Crawling tier from $2,000 per month for 15 to 20 hours; you can compare tiers on our pricing page.

Often. If your company stores no data with a confidentiality life beyond a few years, your realistic plan is the inventory, the policy sentence and the vendor questions. Nothing more until your vendors ship.

It is also premature if your basics are not done. Expired certificates, TLS 1.0 endpoints, secrets committed to source code and no key rotation are risks today, not in 2035. A cybersecurity baseline assessment will find those faster than any quantum readiness review.

And a "quantum-safe" product does not stop the attacks hurting SaaS companies now: phished credentials, misconfigured cloud storage and compromised vendors. Post-quantum cryptography protects data in transit and signatures. It does nothing for an attacker who logs in with a stolen password.

Most need a plan, not a project. Build a cryptographic inventory, classify data by how long it must stay secret, and ask vendors for their PQC roadmaps. Active migration is justified now only for systems carrying data that must remain confidential for many years.

NIST's draft IR 8547 proposes deprecating 112-bit RSA and elliptic-curve algorithms after 2030 and disallowing quantum-vulnerable public-key algorithms after 2035. The dates apply to US federal systems but are flowing into enterprise procurement.

Hybrid key exchange combines a classical algorithm with ML-KEM in the same TLS handshake, so the connection stays secure as long as either one holds. It is the standard transition approach while post-quantum implementations mature.

Neither standard names a "cryptographic inventory," but both expect controlled key management and documented use of encryption. A PQC inventory produces evidence that supports those controls.

If a customer questionnaire just asked about your post-quantum plan, book a free consultation and we will help you write an answer you can stand behind.