Archives and backups are where harvest now, decrypt later hurts most, because the data lives for years and copies leave your control. The data cipher is usually fine. The weak point is often how the data key was wrapped: with RSA or elliptic curve keys. Check that wrapping first.
Why archives are different
Live traffic is recorded in transit. Backups can be copied from storage, stolen from a vendor, or taken from a retired disk. Once a copy is out, you cannot recall it. If it is encrypted with a key wrapped by a quantum-vulnerable scheme, the protection depends on that scheme staying strong for the whole retention period.
The two layers
Most backup systems have two layers:
- A symmetric data key, typically AES, that encrypts the content. NIST's FAQ says AES at 128, 192 or 256 bits can continue to be used, with little or no quantum advantage expected from Grover's algorithm.
- A key-encryption step that protects that data key, often with RSA or an elliptic curve key held in a key manager or HSM.
Layer two is the exposure. NIST's draft lists RSA and elliptic curve key establishment as quantum-vulnerable.
Checks to run
- What wraps the data keys: RSA, elliptic curve, or a symmetric key-encryption key?
- Where do the wrapping keys live, and who can export them?
- Are keys per-backup or shared across years of data?
- Which copies sit with third parties?
- What is the retention period for each data class?
Options to reduce risk
- Wrap data keys with a symmetric key-encryption key held in a managed key service, where your vendor supports it. This avoids public-key wrapping for that layer.
- Use post-quantum key encapsulation as your tools add support. FIPS 203 is the standard to look for. Ask your backup vendor for dates.
- Re-wrap, do not re-encrypt. Re-wrapping data keys with a new key is far cheaper than rewriting all content. Design for it now.
- Shorten retention where you can. Data you no longer keep cannot be recorded.
- Keep the most sensitive data offline or in systems with tight access controls.
What re-wrapping needs
Key IDs stored with each backup, a key rotation process that you have tested, and a record of which backups use which key. Without those, a migration becomes a big restore project.
A realistic plan
- Classify archives by retention and sensitivity.
- Check key wrapping for the top classes.
- Ask vendors for their post-quantum dates.
- Test a re-wrap on a small set.
- Schedule the rest with the same cadence as other key rotations.
Quick check
Do we need to re-encrypt every archive with new algorithms?
Usually not the content. If the data cipher is AES, the issue is how its key is wrapped, and re-wrapping is cheaper.
Are short-retention backups a priority?
Lower priority than long-retention ones. The longer a copy must stay secret, the more exposure.
Sources
Last reviewed: 19 October 2026.
