Data at rest and data in motion are simply two blades of the same weapon both run-of-the-mill encryption. In practice, they confront qualitatively distinct quantum threats, require different responses, and are on different migration timelines. As a result, conflating the two leads to planning errors which manifest as either overstated scope or understated urgency, depending on which side of this distinction gets muddied.
A successful migration means recognizing that the quantum threat behaves differently in each domain and tailoring a migration approach to each.
How Quantum Computing Can Threaten Your Data In Transit
Data-in-flight is protected by the encryption layer, which relies on a key exchange step at the very start of every session. Asymmetric cryptography used to negotiate a shared secret between the two parties, which is then used to derive the symmetric key that encrypts the actual traffic. The step where the quantum threat focuses on is key exchange.
A comprehensive breakdown of quantum safe encryption for stored data and data crossing networks covers both threat categories, but the transit threat has a quality that makes it particularly acute: the harvest-now, decrypt-later attack.
An adversary monitoring traffic today is under no pressure to break the key exchange immediately. It holds on to the captured session data, including parameters for the asymmetric key exchange, until a quantum computer with sufficient power to run Shor’s algorithm becomes available. Once such hardware does arrive, the key exchange that took place in history can be reversed and the session contents can be decrypted afterward. This retrospective attack threatens, in principle, to extend to every RSA- or elliptic-curve-protected communication we exchange today, even if the real-time interception was effectively secure.
The practical mitigation for data in transit is to substitute the key exchange algorithm with a post-quantum primitive. ML-KEM is a standardized KEM (multiple forms) under FIPS 203 and the obvious way forward for this role in protocols such as TLS and IPsec. Hybrid key exchange, which runs ML-KEM in parallel with classical elliptic-curve methods, is already being deployed by modern browsers to protect against the quantum threat and any unforeseen weaknesses of the new algorithm. Post-quantum key exchange in TLS, SSH and IPsec is being standardized in the IETF with an estimated completion time around 2027.
The NCSC guidance on preparing for post-quantum cryptography explicitly identifies TLS and IKE as the protocols where quantum-safe key exchange needs to be integrated, recommending hybrid PQ/T schemes as an interim approach that allows organizations to gain protection before the full standards ecosystem matures.
Quantum Computing Data at Rest Threats
Data at rest is differently threatened by quantum. Shor’s algorithm does not break symmetric encryption like AES (the most common way to protect stored data today). Now Grover’s algorithm presents a less severe threat as it lowers the effective strength of a 128 bit AES key to around 64 bits, and that of a 256 bit key to about 128 bits. The cipher itself does not need to be replaced for systems that already use AES-256.
This quantum exposure for data at rest come from different angles. In most data storage systems, somewhere up the key hierarchy, they safeguard their symmetric encryption keys using asymmetric cryptography. Key management systems encode data encryption keys using RSA or elliptic-curve keys. The public-key mechanism is used to authenticate and deliver the keys in hardware security modules. Storage systems: Certificate-based access control to storage systems is based on the same vulnerable asymmetric cryptographic infrastructure used, for example, by Shor’s algorithm.
For organizations assessing how quantum computing affects their stored data, NIST SP 800-111, which covers storage encryption technologies across enterprise deployments, provides the baseline framework for understanding where cryptography sits within storage encryption architectures. The key insight it supports is that the symmetric cipher protecting stored data is typically not the vulnerable element. The vulnerable element is wherever an asymmetric key exchange or signature protects the symmetric key itself.
Why the Migration Timelines Differ
These are two very different threat profiles that generate genuinely different levels of urgency. You are vulnerable to a harvest-now, decrypt-later attack on your data in transit today. If it was intercepted today, then any session key negotiated using RSA or ECC might be decrypted tomorrow. Thus, in transit encryption, migrating key exchange is urgent depending on the importance of intercepted traffic and how long it needs to remain confidential.
Moreover, data at rest is practically vulnerable only due to the key management layer rather than through the cipher itself also that exposure tends to be prospective rather than retrospective. The purpose of this is that an adversary running such an attack will need quantum hardware at the time of their heat death to extract the asymmetric key protecting stored data. In other words, the timing for data at rest is tuned to expected quantum hardware, not exploitation that could be happening now.
The timelines coalesce for data with long confidentiality requirements: any properly secured data that would be expected to require confidentiality beyond the projected arrival of cryptanalytically relevant quantum computers is already subject to lengthier key-hierarchy attacks if stored and, if transmitted, also to harvest-now troubles. The remediation paths differ though. Transit encryption relates to the deployment of quantum-safe key exchange in TLS and VPN connections. This protects the key management infrastructure that protects stored data, not replaces the AES cipher that encrypts the files themselves both are still needed to provide storage protection in case of a breach!
Are Backups and Archives Worth Specific Attention?
One of the most underappreciated pieces of data-at-rest quantum risk is the backup and archive environment. Backup systems retain copies of data which may reach back years into sensitivity windows, and is often secured by key management systems that are not updated as frequently as primary storage infrastructure.
If encrypted today under a key hierarchy that includes RSA or ECC components, a backup will remain an RSA or ECC-encrypted file (regardless of how many times it is backed up) until the backup has been retired (based on retention policy), restored and re-keyed, or explicitly noted for re-keying. When organizations migrate their primary storage key management to post-quantum algorithms, they need to carefully consider whether their backup estate is included in that migration or, nevertheless, maintains classical cryptographic dependencies, creating an exposure window with potentially very long effective lifetimes.
It gets even worse with regulatory retention requirements for archive environments. Data retained for long-term compliance, of ten to twenty years, must have its key management infrastructure assessed against quantum timelines, not only against classical threat models.
Frequently Asked Questions
If my organization is currently safer than ACTUAL usable AES-256 for stored data, am I quantum safe?
Mostly, but not entirely. While Grover does not weaken AES-256 itself, the key management layer that secures AES-256 keys can be based on RSA or elliptic-curve mechanisms that are vulnerable to Shor’s algorithm. What cipher is used to encrypt the data is only half of the story; how encryption keys are generated, wrapped and stored rounds out the full picture.
How much more of a priority should be given to migration from storage encryption to transit encryption?
The imperative of transit encryption is more pressing because the harvest-now, decrypt-later attacks exist. Later, quantum hardware could potentially be used to decrypt data or intercept communications captured now. Managing storage encryption keys is important too, but the issue becomes prospective rather than retrospective.
Should VPNs be upgraded to quantum-safe protocols prior to TLS?
Both need consideration, but IPsec-based VPNs are among the highest-scoring systems from which to migrate transit encryption, owing to their often long-lived nature and the relative sensitivity of the traffic they carry. IPsec uses IKE for key exchange and post-quantum variants of IKE are being developed as part of the ongoing standardization work at the IETF.