Quantum computing and its implications for cryptography isn't a new discussion. Security professionals have been tracking this technology for years, and the theoretical pieces, particularly Shor's algorithm and its ability to break RSA and elliptic curve cryptography, have been well understood since the 1990s. So why should your organization prioritize this now?
The answer comes down to three factors that have shifted this from a theoretical concern to an operational priority.
First, we now have standards to implement. In August 2024, NIST released the first finalized post-quantum cryptography standards, FIPS 203, 204, and 205. After eight years of evaluation and refinement, organizations finally have concrete, vetted algorithms to adopt. The "we're waiting for standards" justification for inaction no longer applies.
Second, the timeline is tighter than it appears. The general consensus places cryptographically relevant quantum computers roughly 10 years out. But that estimate describes when breaking current encryption becomes practical and routine, not when it becomes possible. Early quantum systems capable of limited cryptographic attacks could emerge sooner. More importantly, large-scale migrations take years to complete. If we look at other technology transitions, they show us that transitioning to the newer systems is neither easy nor fast. For example, the transition from DES to AES took decades and SHA-1 remains in some systems twenty years after its vulnerabilities were first identified. If you need 5-7 years to migrate and quantum threats emerge in 10, the margin for delay is razor thin.
Third, and most critically, the threat is already active. Nation-state actors and advanced threat groups are already collecting encrypted data with the expectation of decrypting it once quantum capabilities mature. This strategy, known as harvest now, decrypt later (HNDL), means that sensitive data you transmit today could be exposed years from now, even if you eventually upgrade your encryption. The encrypted traffic crossing your network this week may be sitting in an adversary's archive, waiting for the day quantum decryption makes it readable.
NIST notes that the harvest now, decrypt later threat is one of the primary reasons the transition to post-quantum cryptography is urgent, not merely important. Data that needs to remain confidential for a decade or more is already at risk.
The good news is that preparation doesn't require a massive immediate investment. It starts with understanding your exposure and building a roadmap. Here's what that looks like in practice.
Step 1: Reassess Data Classification and Retention Policies
Your first action item should be revisiting your data classification and retention policies through a new lens: data relevance longevity. Traditional data classification focuses on sensitivity levels and compliance requirements. Quantum readiness demands an additional dimension: how long does each data element remain valuable if exposed?
Consider two examples. Social Security Numbers are essentially permanent. A SSN stolen today and decrypted in 15 years remains fully exploitable for identity theft, tax fraud, and financial crimes. Credit card numbers, by contrast, are time-limited; a card number decrypted after its expiration date holds significantly reduced value.
This distinction matters because it helps you prioritize. Post-quantum readiness assessments should focus first on data that must remain confidential for 10+ years; healthcare records, government intelligence, intellectual property, and personally identifiable information that doesn't change.
Your updated policies should explicitly address classification criteria that include temporal relevance, retention schedules that account for quantum-era risk exposure, and accelerated migration priorities for long-lived sensitive data.
Step 2: Identify Long-Term Data and the Applications That Touch It
This is where the real work begins, and it's currently the most challenging phase of quantum readiness. You need to catalog all data elements with long-term relevance. Remember this is not based on how long you retain them, but on how long they remain valuable. Then you must trace every application, system, and integration point that processes, stores, or transmits this data.
According to CISA's Post-Quantum Cryptography Initiative, this inventory should include:
- Applications using public-key cryptography across your infrastructure
- Data lifecycle mapping that identifies where sensitive information travels
- Third-party dependencies that handle your long-term data
This task naturally splits into two parallel workstreams:
New Systems: Work with development teams, business units, and procurement to establish documentation requirements for any new system that will handle long-term sensitive data. What cryptographic algorithms will they use? What's their post-quantum migration path?
Legacy Systems: Audit existing applications to understand their cryptographic implementations. This is typically the harder challenge because documentation may be incomplete, and cryptographic decisions may be buried deep in codebases or handled by dependencies you don't directly control.
The NCCoE's Migration to Post-Quantum Cryptography project emphasizes that organizations should create a comprehensive cryptographic inventory connecting systems, data classifications, and business functions.
Step 3: Evaluate and Upgrade Cryptographic Implementations
Once you've mapped your long-term data and the systems that handle it, evaluate each implementation against post-quantum safety standards.
The reality check: almost nothing in production today uses post-quantum safe algorithms by default.
In August 2024, NIST released the first three post-quantum cryptography standards:
- FIPS 203 (ML-KEM): Module-Lattice-Based Key-Encapsulation Mechanism for general encryption
- FIPS 204 (ML-DSA): Module-Lattice-Based Digital Signature Algorithm
- FIPS 205 (SLH-DSA): Stateless Hash-Based Digital Signature Algorithm
Each system touching your long-term data will eventually need to support these or equivalent algorithms. But here's an important nuance: post-quantum algorithms haven't been battle-tested against classical attacks as thoroughly as our current standards.
This is where hybrid encryption models become relevant. A hybrid approach combines post-quantum algorithms with traditional cryptography (like RSA or ECC), providing a "belt and suspenders" protection. If a quantum adversary defeats the classical component, the post-quantum algorithm maintains security. Conversely, if an unknown vulnerability emerges in the new post-quantum algorithm, the classical component provides fallback protection.
Yes, this essentially means encrypting data twice, adding complexity and computational overhead. But for your most sensitive long-term data, the risk mitigation is worth it during this transitional period. Major technology companies including Google and Cloudflare are already implementing hybrid TLS connections using this approach.
Step 4: Design for Cryptographic Agility
And now the part for the future: build systems that support algorithm agility from the start.
NIST's guidance on crypto agility describes this as the capability to replace cryptographic algorithms without interrupting system operations. The post-quantum transition won't be the last time we need to swap algorithms,— it should be a wake-up call to build more adaptable systems.
Crypto-agile design principles include:
- Modular architecture: Isolate cryptographic logic from application code
- Configuration-driven algorithms: Reference algorithm identifiers rather than hardcoding implementations
- Protocol flexibility: Design systems that can negotiate multiple algorithm options
As IBM's quantum-safe guidance notes, organizations can use the quantum-safe migration as the perfect opportunity to establish crypto-agility, while reducing future transition pain regardless of what cryptographic challenges emerge.
Step 5: Update Procurement and Development Standards (Do This First)
While I've listed this last based on the logical flow of preparation, there's a strong argument that this should be your first action.
Every new application your organization purchases or builds should address post-quantum cryptography. Update your procurement requirements and development guidelines to mandate:
- Current state disclosure: What cryptographic algorithms does the product use today?
- Post-quantum roadmap: How does the vendor plan to support post-quantum standards within the next few years? Or how do they support them now?
- Algorithm agility: Can the product swap cryptographic implementations without major re-engineering?
This won't immediately fix your legacy exposure, but it prevents the hole from getting deeper while you work on remediation.
The Bottom Line
The quantum computing timeline contains uncertainty, but the preparation requirements are clear. Organizations that begin this work now will have manageable, phased transitions. Those that wait will face rushed, expensive, and potentially incomplete migrations when regulatory mandates or competitive pressure force the issue.
The NIST transition roadmap sets 2035 as the deadline for federal systems to complete migration to quantum-resistant algorithms, with classical algorithms providing only 112 bits of security disallowed after 2030. While private sector requirements may differ, these government timelines signal where the industry is heading.
Start with procurement policy updates and data classification reviews; they're low-risk, high-impact actions. Then methodically work through the cryptographic inventory and system evaluation phases. The goal isn't to solve everything immediately; it's to make steady, documented progress while the window for proactive preparation remains open.
