Organizations are starting to understand the risk that “harvest now, decrypt later” poses: encrypted data stolen today can be read once a capable quantum computer exists. No one knows when that will be, and the argument does not depend on it.
Dr. Michele Mosca, co-founder of the Institute for Quantum Computing at the University of Waterloo, formulated a risk framework to help organizations gauge the urgency of their post-quantum migration. Mosca’s rule states: if the time your data must stay confidential, plus the time it takes to migrate, is longer than the time until a capable quantum computer exists, you are already exposed.
To minimize the risk, organizations need to understand the data they have – where it is, who has access to it, and how long it needs to be kept and protected. They also must get to grips with the migration from current cryptographic algorithms to post-quantum algorithms.
The standards and deadlines are set
NIST published the first three PQC standards (FIPS 203, 204, and 205) in August 2024, and the IETF has since standardized their use in certificates and TLS (RFC 9881, RFC 9935, and RFC 10024). Government migration deadlines converge on 2030–2035. Private sector organizations that have not thought about migration plans should use these as a guide and adjust based on the data they need to protect.
Published government timelines. Sources listed at the end of the article.
The troubling part is that many organizations are already late to the game.
This is an architecture problem
Cryptography is embedded everywhere: VPNs, TLS certificates and PKI, code signing, hardware security modules (HSMs), databases, SaaS platforms, and, increasingly, IT/OT devices. Most organizations do not have an inventory of which cryptographic algorithms are used where, so they struggle to identify what needs to be replaced and how the replacement will affect existing applications and business processes.
Adding to the complexity are vendor-controlled applications and platforms, where most organizations have little say in the vendor’s PQC roadmap, and long-lived hardware and roots of trust that will outlast the deadlines. Treat supplier PQC readiness as a third-party risk: add it to supplier questionnaires and risk tiering, and track gaps like any other control (see third-party risk programs).
The cryptographic algorithm swap is the easy part. The role of architecture is to find, prioritize, and sequence the transition while minimizing risk to the business.
Crypto-agility as a design attribute
Crypto-agility is the ability to change cryptographic algorithms and keys without having to re-architect or re-engineer systems.
SABSA treats crypto-agility as a business attribute and traces it down to specific security controls and design choices. For example:
These patterns also make it easier to adopt standards as they evolve. Built once, crypto-agility pays off at every future algorithm change, not just this one (see Why SABSA?).
A practical sequence for mid-market organizations
Five steps to guide the migration to PQC:
- Prepare. Name an owner for the migration, responsible for maintaining executive support and a budget line.
- Discover. Build a cryptographic inventory: which algorithms and key lengths are used, where, by which systems and suppliers, and what data they protect. It does not need to be 100% complete at the start; improve it over time in line with your migration timeline. This is also the time to identify your key suppliers. An architecture assessment can establish the baseline.
- Prioritize. Rank by data shelf life (how long the data must stay confidential) and exposure (data that transits public networks first).
- Engage suppliers. Starting with your key suppliers, ask for their PQC roadmaps, then work down the list until all identified suppliers’ plans are documented. Ensure new contracts and renewals include PQC and crypto-agility clauses.
- Transition. Start with hybrid deployments, then disable legacy cryptographic algorithms through your normal change management process, with a documented and tested rollback plan. Where a device cannot be upgraded, isolate or tunnel its legacy cryptography until it is replaced.
What leadership needs to decide now
Leadership needs to understand that this is a multi-year program, not a single project or product purchase. Align it to your refresh cycles. A Fractional CISO can own the roadmap and board reporting.
Affordable now: creating or updating your inventory, adding PQC and crypto-agility clauses to procurement, and including PQC in architecture standards.
Expensive later: waiting until the deadlines are around the corner results in rushed system and hardware replacement, with higher budget and resource costs.
Treat “quantum-safe” claims as marketing until the vendor shows which standard, where it is used, and how it was validated.
Questions to ask vendors
- Which algorithms and key lengths does your product use, and where (data in transit, at rest, signing, firmware)?
- What is your PQC roadmap, with dates? Which of FIPS 203, 204, and 205 will you support?
- Can algorithms be changed through configuration, or does a change need a new release or new hardware?
- Will you support hybrid modes during the transition?
- Can you provide a cryptographic bill of materials (CBOM)?
- What happens to hardware and firmware already deployed, and who pays?
- What independent validation backs your “quantum-safe” claims?
Sector notes
- Insurance and financial services: long-lived personal and financial data (mortgage and life-insurance records can need protecting for decades) and heavy PKI use.
- Public transit and IT/OT: devices with service lives of 15 years or more that may not be upgradable. Replacing them with devices that support PQC or crypto-agility is a lengthy process.
- Government suppliers: national, provincial, and municipal roadmaps flow down into procurement requirements.
Bottom line
If you have not yet started, you are already behind. Start now with your inventory and architecture decisions, and rough out your migration path based on your refresh cycle.
If you do not yet know where cryptography lives in your environment, that is the first conversation. Book a 30-minute strategy session to discuss scope, inventory, or an architecture review.
Sources
- NIST FIPS 203 (with FIPS 204 and 205), August 2024
- NIST IR 8547, Transition to Post-Quantum Cryptography Standards, October 2026
- IETF RFC 9881, RFC 9935, and RFC 10024
- Canadian Centre for Cyber Security, ITSM.40.001, June 2025
- UK NCSC, PQC migration timelines, March 2025
- EU NIS Cooperation Group, coordinated implementation roadmap, June 2025
- Australian Signals Directorate, Planning for post-quantum cryptography, September 2025
Standards and government timelines are current to November 2026. Goni Sarakinov is a SABSA Chartered Security Architect, Foundation. Sarakinov Consulting provides independent, vendor-neutral security architecture advisory to mid-market organizations.
Continue reading