The Security Clock Is Already Ticking

On a Wednesday afternoon in 2024, network monitoring equipment at a European telecommunications provider flagged an anomaly. Outbound traffic from a government client’s encrypted VPN connection was being duplicated and routed to an unfamiliar IP address. The packets were encrypted with standard TLS 1.3 using ECDHE key exchange. Unbreakable by any computer that currently exists.

The security team identified and stopped the tap within hours. But the data that had already been copied, several terabytes of encrypted diplomatic communications, was gone. Stored on servers whose location was unknown, by actors whose identity was eventually attributed to a state intelligence service.

Those encrypted files are worthless today. But diplomatic communications between allied governments need to remain confidential for 25 to 50 years. And the encryption protecting them has perhaps 10 to 15 years before a quantum computer can break it.

This is not a hypothetical scenario. Intelligence agencies have been capturing encrypted traffic at scale for years. The NSA’s data center in Utah has capacity measured in exabytes. The operational assumption among signals intelligence professionals is that anything transmitted over public networks is being recorded by someone, somewhere. Encryption meant that capturing this data was pointless. Quantum computing means it was an investment.

The Inequality That Should Keep You Awake

The core logic of the quantum cryptography threat can be expressed as a simple inequality:

S + M > Q

Where:

• S = how many years your data must remain secret
• M = how many years it takes your organization to migrate to quantum-safe encryption
• Q = how many years until a cryptographically relevant quantum computer (CRQC) exists

If S + M is greater than Q, you are already exposed. Not “will be exposed.” Are exposed. Because the data that needs protection is already being transmitted under encryption that will be broken, and you cannot migrate fast enough to prevent the overlap.

Let us put numbers to this.

S (secrecy period): Medical records: 50+ years. Financial transaction data: 7-25 years depending on jurisdiction. Government classified information: 25-75 years. Trade secrets: indefinite. Customer personal data under GDPR: as long as identifiable. Mergers and acquisitions communications: 5-10 years.

M (migration time): Based on historical data from previous cryptographic migrations (SHA-1 to SHA-2 took most large organizations 5-8 years, and that was a simpler change), realistic post-quantum migration timelines for large organizations range from 3 to 7 years. This includes discovery, inventory, testing, deployment, and verification.

Q (quantum threat timeline): Current estimates for a CRQC that can break RSA-2048 range from 2029 to 2035. Intelligence agencies, which typically plan for worst-case scenarios, appear to be operating on timelines at the earlier end of this range. The Chinese government’s quantum program is advancing rapidly, with significant investment in both superconducting and photonic approaches.

For an organization with medical records (S=50) and a 5-year migration timeline (M=5), the math is: 50 + 5 = 55 years of combined exposure. If Q = 9 (CRQC by 2035), then 55 > 9. Overwhelmingly. Every year of data you transmitted with current encryption adds another year of vulnerable records.

For a financial services firm with transaction data that needs 15 years of confidentiality and a 4-year migration: 15 + 4 = 19. 19 > 9. Still exposed.

Even for a company with relatively short confidentiality requirements, say 5 years, the math gets tight: 5 + 4 = 9. Right at the boundary. And boundaries, in security, are not comfortable places.

What Exactly Breaks

Not everything breaks. This matters because undifferentiated panic is as dangerous as complacency.

What breaks completely: RSA encryption (all key sizes). Elliptic curve cryptography (ECC). Diffie-Hellman key exchange. These are the public-key algorithms that protect TLS/SSL connections, VPNs, email encryption, code signing, digital certificates, and most of the internet’s security infrastructure.

Shor’s algorithm, running on a fault-tolerant quantum computer, solves the mathematical problems these algorithms rely on. This is not a matter of opinion or prediction. The math is proven. The only question is when hardware capable of running Shor’s algorithm at the required scale becomes available.

What weakens but survives: Symmetric encryption (AES-128, AES-256). Grover’s algorithm gives quantum computers a quadratic speedup in brute-force searching, which effectively halves the security level of symmetric keys. AES-256 drops to the equivalent of AES-128, which is still considered secure. AES-128 drops to AES-64, which is not. The fix is straightforward: use AES-256.

What is unaffected: Hash functions (SHA-256, SHA-3). The quantum speedup against hash functions is modest and does not break them at standard security levels.

The NIST Standards Are Ready. You Are Probably Not.

In August 2024, NIST released three finalized post-quantum cryptography standards:

• ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, formerly CRYSTALS-Kyber): for key exchange. This replaces the RSA and ECC-based key exchange in TLS and other protocols.
• ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium): for digital signatures. This replaces RSA and ECDSA signatures.
• SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, formerly SPHINCS+): an alternative digital signature scheme based on hash functions rather than lattice math. Serves as a hedge in case lattice-based approaches are found to have vulnerabilities.

A fourth standard, FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm, formerly FALCON), was finalized in 2025.

These standards are production-ready. Major TLS libraries (OpenSSL, BoringSSL, liboqs) have implementations. Cloud providers are beginning to offer post-quantum TLS options. The standards exist. The software exists.

What most organizations do not have: a complete inventory of where they use the algorithms that need replacing.

This is the actual bottleneck. Not the standards. Not the software. The knowledge of what you need to change.

The Inventory Problem

Every large organization has thousands, sometimes tens of thousands, of systems that use public-key cryptography. Databases, APIs, VPN concentrators, email gateways, certificate authorities, IoT devices, embedded systems, partner connections, SaaS integrations. Each one uses some combination of RSA, ECC, and Diffie-Hellman.

Most organizations do not have a complete map of this. They have a general sense of their architecture, but the specific cryptographic implementations, including what key exchange mechanisms are used, what signature algorithms are deployed, and what libraries are embedded in which devices, are often unknown in aggregate.

This is why migration takes years, not months. The actual cryptographic swap, replacing RSA key exchange with ML-KEM, can be done in a software update. But finding every place that swap needs to happen, testing it, handling backward compatibility with partners who have not migrated yet, updating embedded systems that may not support the new algorithms, replacing hardware security modules that lack post-quantum support. That is the work.

The SHA-1 to SHA-2 migration is instructive. SHA-1 was deprecated in 2011. NIST recommended stopping its use by 2013. In 2017, Google demonstrated a practical collision attack. In 2026, there are still organizations running SHA-1 in some systems. Fifteen years after deprecation.

Post-quantum migration is more complex than SHA-1 to SHA-2. The new algorithms have different key sizes, different performance characteristics, and different integration requirements. ML-KEM public keys are approximately 800 bytes compared to 256 bytes for ECDH. This breaks protocol implementations that assumed smaller keys. ML-DSA signatures are approximately 2,420 bytes compared to 64 bytes for ECDSA. This affects certificate chains, bandwidth calculations, and storage requirements.

Who Is Most Exposed

Different organizations face different levels of urgency. This is not a universal emergency. It is a graduated risk that depends on your specific circumstances.

Highest urgency (act now, not next quarter):

• Government agencies and defense contractors handling classified information
• Financial institutions holding long-term transaction and account data
• Healthcare organizations with patient records
• Telecommunications providers handling encrypted traffic
• Any organization whose adversary model includes state-level actors

High urgency (should be in active planning):

• Energy and critical infrastructure operators
• Legal firms with privileged client communications
• Pharmaceutical companies with proprietary research data
• Technology companies with valuable intellectual property
• Organizations subject to GDPR or similar long-term data protection requirements

Moderate urgency (should begin assessment):

• Retail and consumer companies
• Manufacturing firms with limited long-term data confidentiality needs
• Organizations with primarily short-lived secrets
• Companies whose data would have limited value after 5 years

Note: even “moderate urgency” does not mean “do nothing.” It means the timeline for action is slightly longer, not absent. Every organization using public-key cryptography will eventually need to migrate.

What to Do First: Five Steps in Priority Order

Step 1: Cryptographic Inventory (Weeks 1-4)

Catalog every system, service, and data flow in your organization that uses public-key cryptography. For each, document:

• What algorithm is used (RSA-2048, ECDSA P-256, ECDH, etc.)
• What data it protects
• How long that data needs to remain confidential
• Whether the system can be updated remotely or requires physical access
• Who controls the system (you, a vendor, a partner, an open-source community)

This inventory will be imperfect. Start with your most critical systems and expand outward. An 80% complete inventory in four weeks is infinitely more valuable than a 100% complete inventory that takes two years.

Step 2: Calculate Your Exposure (Week 5)

For each system in your inventory, calculate S + M. Compare to your best estimate of Q. Flag anything where S + M exceeds Q by five or more years. These are your immediate priorities.

Step 3: Enable Hybrid Cryptography on External Connections (Weeks 6-12)

Most modern TLS implementations now support hybrid key exchange, using both a classical algorithm (like ECDH) and a post-quantum algorithm (like ML-KEM) simultaneously. This means your connections are protected by both: if the post-quantum algorithm turns out to have a flaw, the classical one still protects you, and if a quantum computer appears, the post-quantum one protects you.

Enable hybrid TLS on all external-facing services. This is the single highest-impact action you can take in the short term, because it immediately protects all newly transmitted data against harvest-now-decrypt-later attacks.

Step 4: Plan Hardware Security Module Replacement (Months 3-6)

If your organization uses hardware security modules (HSMs) for key management, certificate signing, or other cryptographic operations, check whether your HSMs support post-quantum algorithms. Many older HSMs do not and cannot be updated via software. Budget for replacement. HSM procurement and deployment cycles are long. Start the process now.

Step 5: Engage Partners and Vendors (Months 4-8)

Your cryptographic security is only as strong as your weakest connection. If you migrate to post-quantum algorithms but your banking partner, your cloud provider, or your supply chain platform has not, data flowing between your systems is still vulnerable.

Begin conversations with critical partners about their post-quantum migration timelines. Ask specific questions: “When will your TLS endpoints support ML-KEM? When will you deprecate RSA-2048 key exchange? What is your timeline for post-quantum certificate support?”

The answers will reveal which partners are prepared and which will become your bottleneck.

The Cost of Waiting

Every month you delay starting cryptographic inventory, your migration timeline extends. Not linearly. The late-mover penalty in cryptographic migration is steep because:

• Post-quantum cryptography talent is increasingly scarce and expensive
• Hardware that needs replacing does not get younger
• Partners who migrate first will begin requiring post-quantum connections
• Regulatory requirements are forming. The EU’s Cyber Resilience Act and updates to financial sector regulations increasingly reference quantum-safe cryptography
• Compliance and insurance implications are emerging

The U.S. government has already mandated that federal agencies inventory their cryptographic systems and develop migration plans. Several financial regulators have issued guidance letters. These are early signals. Mandatory requirements will follow, as they always do in cybersecurity.

Starting your cryptographic inventory costs very little. It is primarily an analysis task, not a technology purchase. The barrier is not budget. It is attention and priority. And by the time quantum computers force the priority, the window for orderly migration will have closed.

Between those two conversations, the only difference is one decision, made now.