up:: Migration Architecture MOC

Data at Rest, in Motion, and in Use

Data at rest, in motion, and in use are the three states any piece of information can occupy: sitting in storage, crossing a network, or being processed in memory. Each state is protected by a different mechanism, each is touched by the quantum threat in a different way, and a post-quantum migration is sequenced by mapping which data lives in which state and how long that data has to stay secret. The lens that matters is the data, and the infrastructure follows from it.

The short version:

• Data at rest is stored information (disks, databases, backups, archives), protected by symmetric encryption like AES, whose keys are usually wrapped or delivered by RSA or ECDH.
• Data in motion is information crossing a network, protected by TLS and IPsec key exchange. This is the state exposed to harvest now, decrypt later, because traffic recorded today can be decrypted later.
• Data in use is information being processed in memory or on a CPU, and it’s the domain of confidential computing and hardware-based trusted execution environments.
• A migration starts with the data because the real question is which records must stay confidential and for how long, measured against how long the protecting algorithm stays safe. NIST calls the first quantity the security life of the data.

Think of a company’s secrets as cash. Some of it sits in the vault (at rest), some of it moves in an armored truck between branches (in motion), and some of it is out on the counter being counted (in use). You protect each place differently, a vault door, an armored truck, a teller’s cage, and if you’re deciding where to spend on stronger security first, you start by asking which cash matters most and how long it has to stay yours, then you follow that answer to the room it lives in.

What are the three states of data?

The three states describe the physical situation a piece of information is in at any moment, and every dataset moves through all three over its life. The framing is standard across federal security guidance, where a data-loss-prevention capability is defined as the ability to identify, monitor, and protect data in use through endpoint actions, data in motion through network actions, and data at rest through storage.

1. Data at rest is information held on a storage medium and not currently being moved or processed. Disk volumes, database records, object storage, file shares, backups, and long-term archives are all at rest.
2. Data in motion (also called data in transit) is information traveling across a network or between systems. A TLS session, a VPN tunnel, an API call, and an email in flight are all in motion.
3. Data in use is information loaded into memory and being actively read, computed on, or transformed by a processor. A decrypted record open in an application, a key held in RAM, and a model running inference are all in use.

A single record can pass through all three in seconds: it rests in a database, moves in motion over a query response, and lands in use inside the application that renders it. Because the protections differ by state, the same record can be well-defended in one state and exposed in another.

Source: Committee on National Security Systems, “CNSSI 4009-2015, Committee on National Security Systems (CNSS) Glossary,” CNSSI 4009-2015; NIST, “Cybersecurity Framework Profile for Electric Vehicle Extreme Fast Charging Infrastructure,” NIST IR 8473.

Why does a post-quantum migration start with data, not infrastructure?

Because the thing you’re actually protecting is a secret with a lifetime, and the algorithm protecting it has a durability, and a migration is the work of keeping the first inside the second. NIST SP 800-57 states the rule directly: an organization selects an algorithm and key size based on the algorithm security lifetime and the security life of the data to be protected, and cryptographic protection should not be applied to data using an algorithm if the security life of the data extends past the end of that algorithm’s security lifetime.

NIST defines the security life of the data as the time period during which the security of the data needs to be protected, covering its confidentiality, integrity, or availability. That single quantity, how long a given dataset must stay secret, is what tells you whether a quantum-vulnerable algorithm is an acceptable protector today. A record that must stay confidential for 20 years cannot sit behind an algorithm expected to fall in 10, even if that algorithm is perfectly strong right now.

This is the same arithmetic as Mosca’s theorem, X + Y > Z: the data’s required secrecy lifetime plus your migration time versus the time until the cryptography breaks. Both frameworks put the data first and let the infrastructure follow. When you lead with infrastructure instead, you migrate systems in the order they’re easy to reach and discover only afterward whether the crown-jewel data was even in the batch. When you lead with data, the systems fall out in priority order automatically, which is why the CBOM pairs every algorithm it finds with the data class that algorithm protects.

Source: NIST, “Recommendation for Key Management, Part 1 - General,” NIST SP 800-57 Part 1 Rev. 5, §5.6.4.

What protects data at rest, and how does quantum touch it?

Data at rest is protected by symmetric encryption, and the quantum exposure hides in the key path rather than the cipher. The bulk data on a disk or in a backup is almost always encrypted with a symmetric algorithm like AES-256, and symmetric encryption is the durable part of the stack. Grover’s algorithm gives a quantum attacker only a quadratic speedup against a symmetric key, which cuts an effective 256-bit key to roughly 128 bits of security, a level that stays comfortably out of reach. AES-256 at rest is quantum-resistant.

The exposure is one layer up. The symmetric key that unlocks the data is rarely stored in the clear. It’s wrapped, delivered, or escrowed using public-key cryptography, and that wrapping is usually RSA or ECDH. NIST notes that a password can also be used to derive keys that protect and access data in storage, but where public-key mechanisms guard the access path, Shor’s algorithm breaks them. An attacker who recovers the wrapped key through a future quantum attack opens the strong symmetric encryption underneath without touching AES at all.

So for data at rest, the migration target is the key management and key-wrapping path, not the data cipher. Two disciplines matter here:

1. Keep the strong symmetric encryption. AES-256 is doing its job and stays in place through the transition.
2. Migrate the key-establishment or key-wrapping mechanism to a post-quantum method like ML-KEM, because that public-key layer is where a quantum computer reaches the archive.

Archives deserve special attention, because they carry the longest security life of any data an organization holds and the worst cryptographic visibility. A 20-year retention obligation sitting behind an RSA-wrapped key is a long fuse already lit.

What protects data in motion, and why is it the harvest-now-decrypt-later state?

Data in motion is protected by the key exchange inside transport protocols, and it’s the state where the quantum threat is already live. Every TLS session, IPsec tunnel, and VPN connection begins with a key-establishment handshake that uses public-key cryptography, ephemeral ECDH (ECDHE), classical Diffie-Hellman, or RSA key transport, to agree on the symmetric key that then encrypts the traffic. That handshake is exactly what Shor’s algorithm dismantles.

This is why data in motion is the HNDL-exposed state. An adversary who records an encrypted session today can store it and, once a cryptographically relevant quantum computer exists, recover the session key from the captured handshake and decrypt the whole conversation retroactively. The collection is happening now, against protection that will fall later, which makes this the state where waiting quietly locks in a future breach. CISA’s baseline guidance already tells organizations to encrypt data both at rest and in transit; the post-quantum layer raises the in-transit requirement from classical key exchange to quantum-resistant key exchange.

The fix on this state is the most time-sensitive of the three: move the key exchange to ML-KEM, generally through a hybrid step that runs a classical and a post-quantum key exchange together, as in TLS 1.3 hybrid key exchange. Closing this window on new sessions is an action worth taking ahead of any confirmed quantum timeline, because it’s the only state where the damage is being staged in the present.

Source: CISA, “Encrypt Business Data,” CISA Secure Your Business.

What protects data in use, and does the quantum threat reach it?

Data in use is protected by confidential computing, and the quantum exposure sits in its trust and channel layers rather than in the isolation itself. When a record is loaded into memory and decrypted for processing, it’s outside the protection of both storage encryption and transport encryption, which is why this state was long the hardest to defend. Confidential computing closes it by performing the computation inside a hardware-based, attested trusted execution environment (TEE), a secure region of the processor that keeps the data confidential and its integrity intact while it’s being used, even from a privileged attacker or the cloud operator.

The Confidential Computing Consortium defines a TEE by three assured properties: data confidentiality, so unauthorized entities cannot view data in use within the TEE; data integrity, so they cannot add, remove, or alter it; and code integrity. The TEE also issues remotely verifiable attestations that prove which code is running inside it. That protection is hardware isolation, which a quantum computer does nothing to weaken directly.

The quantum threat reaches this state through two indirect paths:

1. Attestation and identity. The remote attestation that proves a TEE is genuine, and the keys that identify it, rest on digital signatures like ECDSA and RSA, which Shor’s algorithm forges. That’s a trust problem, and it lands once a quantum computer is real rather than through harvesting.
2. The channels into and out of the enclave. Getting data and keys into a TEE, and results back out, uses the same transport key exchange as any other data in motion, so the enclave inherits the in-motion exposure at its boundary.

Data in use is a smaller and newer footprint in most estates than at rest or in motion, and its core protection holds under quantum, so it typically migrates last. The work there is post-quantum attestation and post-quantum-protected channels, rather than a new cipher.

Source: Confidential Computing Consortium, “A Technical Analysis of Confidential Computing,” v1.3, Confidential Computing Consortium.

How do you prioritize the three states for migration?

You prioritize by pairing each state with the security life of the data in it and with how the quantum threat actually reaches that state, which usually sorts the queue in the order below. The table is the fast version of the whole note.

State	Where it lives	What protects it	How the quantum threat touches it	Migration priority
Data in motion	Network traffic, TLS and IPsec sessions, VPNs, APIs	Key exchange (ECDHE, DH, RSA key transport)	Handshake breaks under Shor’s; the HNDL-exposed state, harvested today	First, because collection is live now
Data at rest	Disks, databases, backups, archives	AES bulk encryption, keys wrapped by RSA / ECDH	The cipher holds; the key-wrapping and access path breaks under Shor’s	Second, long data lifetimes, fix in the key path
Data in use	Memory and CPU during processing	Confidential computing, hardware-based TEEs with attestation	Isolation holds; attestation and channels rest on ECDSA / RSA signatures Shor’s forges	Third, smaller footprint, trust-layer exposure

The ordering isn’t a rule for every organization, it’s a default that the data reshuffles. A firm whose crown-jewel secret is a 30-year archive may pull data at rest forward. A firm running sensitive multi-party computation may weight data in use higher. The point is that the state tells you the mechanism to change, the security life of the data tells you the urgency, and the two together produce the sequence. That sequence is where migration architecture and the CBOM pick up the work.

How long must my data stay secret?

That question is the whole game, and NIST gives it a name: the security life of the data, the period during which its confidentiality, integrity, or availability must be protected. It’s distinct from how long you retain the data, how long the system runs, or how long a contract lasts, and it’s routinely underestimated by conflating it with those. The forcing move is to put a number on it per data class, then compare that number against the durability of the algorithm currently protecting it.

The comparison is obligation-duration against algorithm-durability. If a dataset’s obligation-duration (its security life) runs longer than the durability of its protecting algorithm (how long that algorithm stays unbroken), the protection is already inadequate, regardless of how strong the algorithm looks today. For quantum-vulnerable public-key cryptography, the durability horizon is the arrival of a capable quantum computer, which is why long-lived data protected by RSA or ECDH is the first thing a migration surfaces. This is the reasoning Mosca’s theorem formalizes and the reason the data state, on its own, is never the full answer. The state tells you the mechanism; the security life tells you when it becomes a problem.

Common misconceptions

• “Strong encryption on the disk means data at rest is quantum-safe.” The AES layer is fine. The quantum exposure is the public-key mechanism that wraps or delivers the symmetric key, and that path is where the migration work lives.
• “Data in use is the scariest quantum target.” For most estates the reverse holds. The hardware isolation that protects data in use is untouched by quantum, while data in motion is the state being harvested today.
• “Data in transit and data in motion are different things.” They’re two names for the same state, information crossing a network. Federal glossaries use both.
• “A record is protected if any one state is protected.” A record moves through all three states, and a weakness in any state exposes it. Encrypting at rest does nothing for the same record while it’s in motion.
• “Confidential computing solves the quantum problem for data in use.” It solves the in-memory isolation problem. Its attestation and its channels still depend on signatures and key exchange that a quantum computer breaks, so they migrate too.
• “We should migrate the biggest systems first.” Size of system is the wrong sort key. Security life of the data and the state it lives in are what set urgency, and they often point at a small, overlooked archive rather than the largest application.

Questions people ask

Which state do I migrate first? Data in motion, in almost every case, because harvest-now-decrypt-later means the exposure is being staged today rather than at some future quantum arrival. Turning on quantum-resistant key exchange for TLS and VPN traffic closes the window on new sessions immediately.

Is my encrypted data at rest safe from quantum? The AES encrypting the bulk data is safe, since Grover’s algorithm only halves symmetric strength and 256-bit keys stay strong. The risk is the public-key mechanism that protects the symmetric key, so audit the key-wrapping and access path, not the cipher.

What’s the difference between data at rest and data in use if both are on the same server? State is about what the data is doing, not where it sits. At rest it’s encrypted and idle in storage; in use it’s decrypted and loaded in memory for processing. The same file is protected by different mechanisms in each, which is why a record safe on disk can still be exposed while an application has it open.

Does confidential computing replace encryption at rest and in transit? No, it completes the set. Storage encryption protects data at rest, transport encryption protects data in motion, and confidential computing protects data in use, and a fully protected record needs all three.

How do I know how long my data must stay secret? Classify by data type and its regulatory, contractual, and strategic sensitivity, then assign each class a security life, the years its confidentiality must hold. Health, legal, defense, financial, and trade-secret data carry long lives; ephemeral operational data carries short ones.

Where does the CBOM fit into the three states? A CBOM records which algorithm protects which data, and pairing that with the data’s state and security life is what turns an inventory into a prioritized migration queue.

Is data in motion only a confidentiality problem? Primarily, through harvesting, but the same handshakes also authenticate the endpoints, so a broken key exchange can enable interception and impersonation once a quantum computer exists, which crosses into the trust category.

---

Everything here is the map, given freely. When your team needs the three states mapped across your own estate, each dataset paired with its security life and sequenced into a defensible migration, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.