keepcalculator

06 Numbers and Powers

Post-Quantum Readiness: A Practical Guide

Card No. 06·8339 · Updated · Standard formula, shown below

This guide walks your organization through preparing for the shift to post-quantum cryptography (PQC). You’ll learn how to inventory your cryptographic assets, assess quantum risk, and build a migration plan that keeps your data secure well into the future. By the end, you’ll have a clear, actionable roadmap that doesn’t require a PhD in quantum physics—just a methodical approach and some cross-team coordination.

What You’ll Need

  • An up-to-date asset inventory of your systems and data flows (or the ability to create one)
  • Access to your organization’s security policies and compliance requirements
  • Cooperation from IT, security, development, and procurement teams
  • A basic understanding of public-key cryptography (e.g., RSA, ECC) and where it’s used
  • Budget and executive sponsorship for potential software/hardware upgrades

Step-by-Step

  1. Create a cryptographic inventory. List every system, application, and device that uses public-key cryptography. Include TLS certificates, VPNs, code-signing keys, SSH keys, email signing (S/MIME, PGP), and any embedded systems (IoT, routers, medical devices). Use network scans, certificate management tools, and configuration management databases (CMDBs) to fill gaps.
  2. Classify data by sensitivity and lifespan. Identify data that must remain confidential for decades (e.g., health records, government IDs, trade secrets). These are at highest risk from “harvest now, decrypt later” attacks, where adversaries store encrypted data today to decrypt it once quantum computers mature. Prioritize this data for early migration.
  3. Map cryptographic dependencies. For each asset, note the algorithms and key lengths in use (e.g., RSA-2048, ECC P-256). Identify which protocols and standards they rely on (TLS 1.2/1.3, SSH, IPsec). This helps you spot where changes are needed and what might break.
  4. Assess quantum risk. Estimate the time it takes to migrate each asset (e.g., 1-3 years) and the “quantum-safe horizon”—when a large-scale quantum computer could break current algorithms (commonly estimated at 10-20 years, but treat as uncertain). If migration time + data lifespan > horizon, that asset is at risk. Prioritize accordingly.
  5. Monitor NIST standards. Follow the NIST Post-Quantum Cryptography Standardization process. As of 2024, NIST has selected CRYSTALS-Kyber (ML-KEM) for key encapsulation and CRYSTALS-Dilithium (ML-DSA) for digital signatures, along with SPHINCS+ (SLH-DSA) as a backup. Use these as your primary targets, but stay flexible.
  6. Plan a crypto-agile architecture. Design systems so that cryptographic algorithms can be swapped without major re-engineering. Use abstraction layers, avoid hard-coding algorithms, and support multiple algorithms simultaneously (hybrid mode) during transition. This is the single most important step to future-proofing.
  7. Pilot with a low-risk system. Choose a non-critical internal application to test PQC integration. For example, enable hybrid TLS (using both classical and post-quantum key exchange) on a dev server. Document the process, performance impact, and any compatibility issues.
  8. Develop a migration roadmap. Sequence the migration: start with high-risk data and systems that are easiest to update (e.g., web servers, VPNs). Include timelines, responsible teams, and budget. Plan for overlapping classical and PQC algorithms to ensure interoperability.
  9. Update policies and procurement. Revise your security policies to require PQC support in new purchases. Add PQC readiness to vendor RFPs and ensure that any new hardware/software you buy is crypto-agile or already supports NIST-approved PQC.
  10. Train your teams. Educate developers, network engineers, and procurement staff on PQC basics—what it is, why it matters, and how to implement it. Use NIST’s guidance and vendor documentation. Keep training ongoing as standards evolve.
  11. Test and iterate. After migrating each asset, run interoperability and performance tests. Verify that systems still work with external partners who may not yet support PQC. Maintain a fallback plan to revert to classical algorithms if issues arise.
  12. Continuously review. Revisit your inventory and risk assessment annually. New vulnerabilities, standards updates, or changes in data sensitivity may require adjusting your roadmap.

Common Mistakes

  • Waiting for quantum computers to exist. The threat is real today due to harvest-now-decrypt-later attacks. Start migrating long-lived data now.
  • Assuming all cryptography needs to change. Symmetric algorithms (AES) are mostly safe if key sizes are doubled; only public-key systems are broken by Shor’s algorithm.
  • Ignoring legacy systems. Embedded devices and old software may not support PQC and could require replacement—plan for that cost.
  • Relying solely on NIST’s finalists. Standards can change; build in crypto-agility so you can switch if needed.
  • Forgetting about certificates and PKI. Your public key infrastructure (CA, CRLs, OCSP) also needs PQC migration, not just end-entity certificates.

Tips

  • Start small but start now. Even a simple inventory is a huge step forward.
  • Use hybrid modes (e.g., X25519Kyber768) during transition to maintain compatibility with older systems.
  • Leverage cloud providers’ PQC offerings (e.g., AWS KMS, Azure Key Vault) to reduce implementation effort.
  • Join industry working groups (e.g., Cloud Security Alliance, IETF) to stay ahead of best practices.
  • Document everything—your future self will thank you when audits come around.

Troubleshooting

If your migration stalls or fails, try these steps:

  • Compatibility issues: If a system doesn’t support PQC, check for firmware updates or vendor patches. If none exist, consider a virtual patch or a gateway that terminates PQC and re-encrypts to classical for legacy systems.
  • Performance degradation: PQC algorithms can be slower, especially on constrained devices. Optimize by using hybrid modes only where necessary, or offload crypto operations to hardware accelerators.
  • Interoperability failures: If external partners can’t connect, enable a fallback to classical algorithms temporarily, but set a deadline for them to upgrade.
  • Lack of budget: Prioritize the most critical assets first and present the risk to executives in terms of data exposure. Use free tools and open-source libraries (e.g., OpenQuantumSafe) to reduce costs.
  • Resistance to change: Educate stakeholders with concrete examples of harvest-now attacks and the cost of a breach. Often, a small pilot success story is enough to win support.

Frequently Asked Questions

  1. When will quantum computers break RSA? Estimates vary, but many experts predict a 10-20% chance by 2030 and a 50%+ chance by 2040. The uncertainty is why you should start now.
  2. Do I need to replace all my encryption? No. Symmetric algorithms like AES-256 are considered quantum-safe if used with sufficient key sizes. Only public-key algorithms (RSA, ECC, Diffie-Hellman) are at risk.
  3. What is “harvest now, decrypt later”? Adversaries capture encrypted data today and store it until they have a quantum computer. This makes long-lived data vulnerable even if you migrate later.
  4. Can I use the same PQC algorithm for everything? Not necessarily. Different use cases (key exchange vs. signatures) require different algorithms. NIST has selected separate families for each.
  5. Is NIST’s process final? As of 2024, NIST has standardized ML-KEM and ML-DSA, but additional algorithms are still being evaluated. Keep an eye on updates.
  6. What is crypto-agility? It’s the ability to swap cryptographic algorithms without redesigning systems. It’s achieved through abstraction layers and modular design, making future migrations easier.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →