Data at Rest vs. Data in Transit: Why Both Need Quantum-Resistant Protection

Ask your CISO a simple question: if a sufficiently capable quantum computer existed tomorrow, which parts of our infrastructure fail first? Most will give you one answer. The correct answer has two parts, and the gap between them is where most quantum migration plans quietly come apart.

Anyone who lived through the SHA-1 to SHA-2 migration knows the shape of what's coming. Cryptographic transitions aren't a single project. They're a hundred small projects, scattered across systems no one fully owns, with deadlines set by mathematics rather than budgets. The post-quantum migration is the same story at ten times the scale. And unlike SHA-1, it splits cleanly into two distinct problems most teams are still treating as one.

Those problems map to two states of your data: the data moving across your networks, and the data sitting in your storage, archives, and signed artifacts. Both face quantum threats and they are not the same threat.

Data Moves and Data Sits: Both Are Exposed

When security teams talk about quantum risk, they usually talk about TLS, the protocol protecting data as it moves between users, servers, and APIs. It's a real exposure and it deserves the attention it gets. But it's roughly half the picture.

Data inside your organization exists in two states. It moves, and it sits.

• Data in transit flows across networks: API calls, VPN tunnels, inter-service communication, customer sessions.
• Data at rest lives in databases, backups, archives, code repositories, signed artifacts, and the certificate chains underpinning your PKI.

These two states are protected by overlapping but distinct cryptographic primitives, and quantum computing threatens them in different ways.

Treating quantum readiness as one migration when it's actually two is a category error. Different cryptography, different exposure timelines, different remediation paths. A plan that addresses one half is a plan with a gap.

Data in Transit: The Harvest Now, Decrypt Later Problem

Harvest Now, Decrypt Later (HNDL) is a threat strategy in which adversaries capture and archive encrypted network traffic today, with the intention of decrypting it once sufficiently capable quantum computers become available.

Every time data crosses a network, it's protected by the same basic pattern. Two parties agree on a shared secret key using asymmetric cryptography (today, RSA or elliptic curve DH), then encrypt the conversation with a symmetric algorithm like AES.

Quantum computing breaks the first half. Shor's algorithm, running on a large enough quantum computer, recovers the private keys behind RSA and ECDH. Once those fall, every session key derived from them falls too. Every message encrypted under those session keys becomes readable.

This is the threat known as Harvest Now, Decrypt Later. An adversary doesn't need a quantum computer today. They need storage and patience. Capture encrypted traffic now, archive it, decrypt it when quantum capability arrives. Public reporting on bulk collection programs has made it pretty clear this isn't hypothetical.

Exposure follows directly from how long your data needs to stay confidential. A session token expiring in fifteen minutes isn't really at risk. An M&A negotiation, a trade secret, a medical record, a piece of regulated financial data: anything with a confidentiality lifespan measured in years is already exposed if it's crossing networks today under classical key exchange.

The unsettling part of HNDL is that the breach happens on a delay you can't see. Your traffic is secure today. The compromise is a future event written against a present action, and the only mitigation is to stop transmitting harvestable ciphertext before the harvesting window closes.

Data at Rest: The Trust Now, Forget Later Problem

Trust Now, Forget Later (TNFL) is a threat to long-lived digital signatures such as code-signing certificates, contracts, audit records, where quantum capability enables retroactive forgery of signatures that were valid at the time they were issued.

Data at rest is protected differently. The file in your database, the backup in cold storage, the document in your archive: all of it is encrypted with a symmetric algorithm, typically Advanced Encryption Standard (AES). And here's the part most quantum conversations skip: AES is fine. Grover's algorithm impacts symmetric encryption only partially and only in theory. In practice, AES is fine even at 128 bits of key size, so it’s not the actual problem.

The problem at rest is twofold, and neither half is the encryption itself.

First, key management hierarchies. The AES keys protecting your data don't sit in plaintext. They're wrapped by other keys, and somewhere up that chain, in your KMS, your HSM, your cloud provider's root of trust, there's an asymmetric key. Almost always RSA or ECC. Break the wrapper, and every key beneath it falls. The encryption on the data is irrelevant if the keys protecting the keys are quantum-vulnerable.

Second, digital signatures on long-lived artifacts. This is where the second quantum threat lives: Trust Now, Forget Later. Every signed object in your environment depends on a signature algorithm that says this came from us, and it hasn't been altered. That includes:

• Code-signing certificates and software releases
• Signed contracts and notarized records
• Certificate authority chains
• Audit trails

RSA and ECDSA, the algorithms doing that signing today, are quantum-vulnerable. Once a quantum computer of sufficient scale exists, signatures produced today can be forged retroactively. An adversary in 2032 could produce a “signed” software update from your CA, dated 2026, that your systems accept as authentic.

The exposure profile here is the inverse of HNDL. HNDL targets confidentiality and bites anything with a long secrecy lifespan. TNFL targets authenticity and bites anything with a long trust lifespan: software you've shipped, contracts you've executed, certificates you've issued, records you're required to retain under HIPAA, GDPR, SOX, or financial regulation. You can re-encrypt a database. You cannot easily re-sign every artifact you've ever issued.

The unsettling part of TNFL is that the damage runs backward in time. HNDL exposes your past communications. TNFL rewrites your past attestations: which version of your software was authentic, which contract you actually signed, which record was real. Trust you established years ago becomes forgeable, and there's no clean way to retroactively prove what was true.

Why the Two Threats Compound

HNDL and TNFL aren't independent risks. They share a single root cause, quantum-vulnerable asymmetric cryptography, but they exploit it against different parts of your stack, in different time directions, against different security properties. Confidentiality on one side, authenticity on the other. Forward-looking exposure on one side, backward-looking on the other.

This is why partial migrations create false confidence. A team that hardens TLS but leaves its code-signing infrastructure on RSA has closed the HNDL door and left the TNFL door open. A team that migrates its KMS but leaves legacy VPN tunnels in place has done the opposite. Both teams will tell their boards they're “working on quantum readiness.” Both will be technically correct. Neither will be protected.

The NIST post-quantum standards reflect this dual structure on purpose. ML-KEM is the standardized replacement for quantum-vulnerable key exchange, the HNDL fix. ML-DSA and SLH-DSA are the standardized replacements for quantum-vulnerable signatures, the TNFL fix. Different algorithms, different problems. A complete migration touches both.

The practical implication: a cryptographic inventory needs to map your stack along two axes, not one. Where do you rely on quantum-vulnerable cryptography for confidentiality (key exchange protecting data in motion)? And where do you rely on it for authenticity (signatures protecting the integrity and origin of data at rest)? The answers live in different systems, owned by different teams, with different vendors and different timelines. A migration plan that doesn't distinguish between them is a plan with a hidden gap.

The Regulatory Clock Is Already Running

The timeline pressure here isn't abstract. Regulators have set specific migration deadlines, and they map directly onto the two-threat structure described above.

In the US, NIST finalized its first quantum-resistant algorithm standards ( FIPS 203, 204, and 205) in August 2024. These are the ML-KEM and ML-DSA replacements for vulnerable key exchange and signatures respectively. CNSA 2.0 requires all new national security system acquisitions to be quantum-resistant by January 2027.

In the EU, DORA, active since January 2025, requires demonstrable crypto-agility across financial services infrastructure. The EU's broader quantum-resistant migration roadmap mandates critical infrastructure compliance by 2030. PCI DSS 4.0 cryptographic controls activated in March 2025.

Healthcare organizations face a compounding problem: HIPAA data retention requirements of seven or more years mean records transmitted today under classical key exchange are already within HNDL exposure windows that extend past the expected arrival of capable quantum systems.

The standards exist. The migration paths exist. What most organizations are still missing is a clear map of which systems need to move first, and in what order.

What This Means for How You Think About Your Stack

The useful shift here is a change in the question being asked.

“Are we quantum-ready?” is the wrong question. It's binary, it's vague, and it invites a vague answer. The right question is two questions, asked separately:

Where in our stack is confidentiality protected by quantum-vulnerable key exchange? That's your HNDL exposure. The answer lives in your network layer, your TLS configuration, your VPNs, your API gateways, your inter-service communication, and the encrypted pipes connecting you to your cloud providers and SaaS vendors.

Where in our stack is authenticity protected by quantum-vulnerable signatures? That's your TNFL exposure. The answer lives in your code-signing infrastructure, your certificate authorities, your document signing systems, your software supply chain, and the long-lived signed artifacts you've already shipped into the world.

These two questions have different answers, owned by different teams, fixed by different algorithms, on different timelines. The NIST standards are finalized. The migration paths exist. The question is no longer whether but in what order, and that ordering depends on which exposure profile dominates your specific risk surface. A bank with decades of regulated archives looks different from a SaaS company with a heavy outbound API footprint. Both have quantum exposure. Neither should migrate in the same sequence.

The organizations that come out of this transition cleanly will be the ones that stopped treating quantum readiness as a single milestone and started treating it as two parallel migrations against two distinct threats. The ones that don't will find the gap the way infrastructure gaps usually get found: late, and from the outside.

****************************
Assess Your Quantum Exposure

Learn how Horizen Labs approaches quantum-resistant security assessment and migration planning: https://horizenlabs.io/quantum-security

Horizen Labs delivers quantum-resistant security assessments and cryptographic advisory to enterprise, financial services, and government organizations. Our Quantum Threat Assessment is a PhD-led review that maps your cryptographic exposure and defines where to focus.