Post-Quantum Security for Business: Why 'Harvest Now, Decrypt Later' Demands Action Today

In March 2026, the security team at Alderwood Health Analytics — a mid-sized claims-processing firm in Austin, Texas that handles insurance data for a network of 40 regional hospitals — received a routine third-party risk assessment from one of its largest hospital-system clients. Buried on page 14 was a paragraph that kept CISO Daniel Cho up for the better part of a week: every encrypted transmission of patient claims data since 2020, protected with standard RSA-2048 and ECC-based TLS, could plausibly already be sitting on a server somewhere, harvested and stored by an unknown adversary, waiting for the day a quantum computer becomes powerful enough to decrypt it. Health records in the US carry confidentiality obligations that routinely extend 20 to 30 years or longer, well past even the most optimistic timelines for cryptographically relevant quantum computers, which most serious research roadmaps place somewhere between the early 2030s and mid-2030s. After a six-week internal audit, Alderwood budgeted $340,000 for a phased cryptographic modernization project spread across nine months. This is not a hypothetical scare story — it's the exact calculus a growing number of companies holding long-lived sensitive data are now running.

What Quantum Computers Actually Threaten

Nearly every piece of digital security we rely on today — HTTPS in the browser, corporate VPNs, digital signatures on contracts, database encryption, API authentication — rests on two families of public-key cryptography: RSA (typically RSA-2048 or RSA-3072) and elliptic curve cryptography, or ECC (used in ECDSA and ECDH). Their strength doesn't come from being mathematically unbreakable; it comes from the fact that breaking them with a classical computer would take an impractical amount of time, in some cases longer than the age of the universe.

The problem is that quantum computers operate on fundamentally different physical principles. In 1994, mathematician Peter Shor published an algorithm that, if run on a sufficiently large and stable quantum computer, could factor large numbers and solve the discrete logarithm problem — the two mathematical foundations underpinning RSA and ECC — dramatically faster than any classical supercomputer. In practice, that means Shor's algorithm could eventually break RSA-2048, ECC-based TLS/HTTPS connections, digital signatures on electronic contracts, and public-key-based VPN encryption, all at once.

The good news: a quantum computer of that scale doesn't exist yet. Today's machines are experimental, with hundreds to roughly a thousand noisy physical qubits, nowhere near the millions of stable, error-corrected logical qubits believed necessary to run Shor's algorithm against a 2048-bit key. Most credible research roadmaps place a cryptographically relevant quantum computer somewhere in the late 2020s to mid-2030s. But that timeline is precisely where the trap lies, as the next section explains.

"Harvest Now, Decrypt Later": A Risk That's Already Active

The attack strategy known as "harvest now, decrypt later" (HNDL) doesn't wait for quantum computers to be ready. Adversaries — ranging from organized cybercrime groups to well-resourced state actors — can start intercepting and stockpiling encrypted traffic today, then decrypt it retroactively once a sufficiently powerful quantum computer exists. Technically, this is straightforward: intercept encrypted traffic at network chokepoints, compromised ISPs, or breached cloud infrastructure, then store it cheaply for years until it can be unlocked.

This strategy only makes economic sense if the harvested data still has value by the time it's decrypted. That's why "confidentiality shelf-life" matters so much. Several categories of data carry unusually long shelf-lives:

• Health and medical records — legally required to remain confidential for decades, in some jurisdictions even after a patient's death.
• Trade secrets and intellectual property — product formulas, source code, and design specifications that represent competitive advantage for years.
• Financial and banking data — transaction histories, KYC records, and investment strategies that remain sensitive long after the transaction itself.
• Government and legal records — contracts, litigation files, and diplomatic correspondence with strategic value that persists for decades.

If your business handles any of these categories and transmits them today using classical encryption alone, there's a real possibility that data is being harvested right now, to be unlocked five, eight, or ten years from now — right around when a capable quantum computer is likely to exist. This isn't a hypothetical worst case; it's the exact reasoning that drove NIST to begin standardizing quantum-resistant cryptography over a decade ago.

NIST's Finalized Standards: ML-KEM and ML-DSA Are Here

In August 2024, the US National Institute of Standards and Technology (NIST) formally published three post-quantum cryptography (PQC) standards, capping an eight-year competitive selection process that evaluated dozens of candidate algorithms submitted by cryptographers worldwide. The three core standards are:

• FIPS 203 — ML-KEM (formerly CRYSTALS-Kyber): a key encapsulation mechanism for secure key exchange, designed to replace ECDH/RSA in TLS connections and VPNs.
• FIPS 204 — ML-DSA (formerly CRYSTALS-Dilithium): the primary digital signature algorithm, replacing ECDSA/RSA for identity verification, document signing, and certificates.
• FIPS 205 — SLH-DSA (based on SPHINCS+): a backup signature algorithm built on a fundamentally different mathematical approach (hash-based), serving as a safety net in case any weakness is ever found in the lattice-based math underlying ML-KEM and ML-DSA.

Most of these algorithms rely on lattice-based cryptography, which the cryptographic research community currently believes resists both Shor's algorithm and other quantum algorithms that might be discovered in the future. What matters for business owners: this is no longer academic. These are official standards already being rolled out by major cloud providers and CDNs through hybrid key exchange in TLS 1.3 — combining a classical algorithm (like X25519) with ML-KEM simultaneously, so connections stay secure even if one approach is later found to have a flaw.

Crypto-Agility: An Architectural Foundation, Not Just a Swap

"Crypto-agility" refers to a system's ability to swap out the cryptographic algorithms it uses — keys, signatures, encryption protocols — without a ground-up rebuild of the application. That sounds simple, but in practice many legacy systems hard-code specific cryptographic algorithms directly into application code, scattered across dozens of modules with no abstraction layer whatsoever.

Architecturally, real crypto-agility includes several core principles:

• A centralized cryptography abstraction layer — algorithms aren't called directly throughout the codebase; instead, a single configurable crypto service layer handles them.
• Centralized key management — using a key management system (KMS) or hardware security module (HSM) that supports algorithm swaps without manual data migration across every system.
• Hybrid support by default — new TLS connections are configured to support a combination of classical and post-quantum algorithms simultaneously during the transition period, rather than jumping straight to PQC-only, which carries risk if an implementation bug is later found.
• A living crypto inventory — complete documentation of which algorithms are used where, which library versions, and which third-party vendors are involved, so that when migration becomes necessary, the team knows exactly what to change.

Businesses building new systems today — a website, a mobile app, an ERP platform — have a rare opportunity to bake crypto-agility in from day one, at a fraction of the cost of retrofitting it onto a system that's already run for years with thousands of integration points.

The Cheap Fix vs. a Properly Built Architecture

Many companies are tempted to take a shortcut: flip on TLS 1.3 at the web server and call it done. But enabling TLS 1.3 alone doesn't automatically protect traffic from HNDL — that depends on the chosen cipher suite and key exchange method, whether hybrid PQC is actually enabled, whether certificates and digital signatures are updated in tandem, and whether mobile apps and third-party API integrations are adjusted too.

The DIY or patchwork approach typically:

• Only touches web server configuration, leaving application logic, internal APIs, and document-signing workflows untouched.
• Relies on whatever cryptographic library ships by default with the framework, often an outdated version with no PQC support at all.
• Has no clear crypto inventory, so the team has no idea which systems still rely on vulnerable algorithms.
• Skips performance testing for the significantly larger key and signature sizes PQC algorithms produce, which can slow down handshakes on high-traffic applications if left unplanned.

A properly built architecture instead starts with a full audit of every cryptographic touchpoint in the system — not just HTTPS, but database encryption, API signing, key storage, and communication with third-party vendors. From there, engineers design a crypto-agile abstraction layer, select frameworks and infrastructure (including CDNs and cloud providers) that already support PQC natively, and roll out migration in phases with compatibility testing at every step. The result isn't just "we turned on TLS 1.3" — it's a system genuinely capable of adapting the next time cryptographic standards shift, which they inevitably will.

Realistic Cost and Timeline Ranges

Investment in post-quantum readiness varies significantly with system scale and complexity. Based on comparable projects, here are realistic ranges:

• A business website or light e-commerce platform: a security audit plus TLS/hybrid key exchange configuration updates, typically $3,000–$12,000, delivered in 2–4 weeks.
• A mobile app with a backend API and user authentication: including crypto inventory audits, migration to PQC-capable libraries, and performance testing, typically $25,000–$90,000, delivered in 6–14 weeks.
• An ERP or enterprise platform with multiple third-party integrations: full audit, crypto-agile architecture redesign, phased module-by-module migration, and internal team training, typically $100,000–$600,000, delivered over 6–14 months depending on integration count.

These figures vary based on how many legacy systems need auditing, how many third-party vendors must be coordinated with, and whether the company already has clean architectural documentation or is starting from scratch. What's consistent across projects: planning migration early — while building a new system or modernizing an ERP — is far cheaper than an emergency migration triggered by a breach or a sudden compliance deadline.

Case Study: The Results After Migration

Back to Alderwood Health Analytics. After its nine-month, $340,000 modernization project, the results reported in its year-end 2026 review included: 100% of inter-facility traffic now running on TLS 1.3 with hybrid key exchange (X25519 combined with ML-KEM), all 52 internal systems documented in a centralized crypto inventory that hadn't existed before, and key rotation time across all systems dropping from an estimated four months under the old manual process to under ten days thanks to the new centralized key management layer. TLS handshake overhead did increase by roughly 9-14% compared to the previous setup, judged an acceptable tradeoff given the sensitivity of the data protected. Just as importantly, the hospital-system client's next annual risk assessment, delivered in early 2027 planning cycles, flagged Alderwood's HNDL exposure as "substantially mitigated" — a marked shift from the finding that triggered the project in the first place.

Metrics to Monitor After Implementation

Post-quantum readiness is not a one-time project that ends at go-live. Metrics worth tracking on an ongoing basis include:

• Percentage of traffic using active hybrid key exchange — the target should approach 100% across all public-facing endpoints.
• Crypto inventory coverage — what percentage of systems and third-party services have documented cryptographic algorithms, kept current with every new integration.
• Key rotation time — how quickly the team can rotate keys or swap algorithms across all systems if a new vulnerability surfaces.
• Latency and payload overhead — because PQC keys and signatures are substantially larger than RSA/ECC, it's important to track the impact on application speed, especially over bandwidth-constrained mobile connections.
• Third-party vendor readiness — whether CDN, payment gateway, and external API providers have a clear PQC support roadmap.
• Recurring security audit results — ideally conducted every 6-12 months to catch configuration regressions introduced by routine updates.

Common Implementation Challenges and How to Overcome Them

A few challenges surface repeatedly in projects like this, along with practical ways to address them:

• Legacy systems that don't support modern libraries — the fix is rarely a full system replacement; more often it's a crypto-agile gateway or proxy placed in front of the legacy system as a temporary translation layer.
• Third-party vendors not yet PQC-ready — requires proactive communication about vendor roadmaps and architecture that avoids hard dependency on any single vendor without a migration path.
• Performance overhead from larger key sizes — addressed through load testing early in the project and selecting the right algorithm for each context (ML-KEM tends to be more efficient for key exchange than some hash-based signature alternatives, for instance).
• Limited in-house expertise — internal teams rarely have hands-on PQC experience since the standards are still new; partnering with developers who have tracked NIST's standardization process closely is usually far more efficient than training a team from scratch mid-project.
• Difficulty prioritizing which systems to migrate first — resolved by ranking systems according to data sensitivity and confidentiality shelf-life, not simply technical ease.

The quantum threat to RSA-2048 and ECC hasn't materialized yet, and it may be years before it fully does. But as Alderwood Health Analytics discovered, the "harvest now, decrypt later" risk is already active today, quietly, against any data with a long confidentiality shelf-life. NIST's standards have been finalized since 2024, and major infrastructure providers are already rolling out support — which means waiting is no longer the safe option, especially if your business is building or modernizing a website, app, or ERP system in the near future. That makes right now the cheapest and most effective moment to bake in crypto-agility, rather than retrofitting it later at multiples of the cost. AFSS's team builds architecture designed to adapt as security standards continue to evolve. Check our pricing for your project, or submit your project for a post-quantum readiness consultation with our team.