Why Encrypted Archives from 2018 May Not Be Safe in 2030

The standard reassurance that security teams have given themselves about older data is this: the data is encrypted, so it is protected. In most threat models, that is correct. Against a cryptographically relevant quantum computer running Shor's algorithm, it is not. This article explains why 2018-era encrypted archives carry a specific and growing risk that reaches its credible lower bound in 2030, and what, if anything, organisations can do about it now.

Why 2018 and Why 2030 Are Not Arbitrary

In 2018, TLS 1.2 with Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange was the standard for securing enterprise communications, cloud services, and web traffic. TLS 1.3 (RFC 8446) was published in August 2018 but had not yet reached widespread deployment. Both versions use asymmetric key exchange mechanisms that Shor's algorithm breaks completely. An adversary who captured encrypted TLS traffic in 2018 also captured the ephemeral public key material exchanged during each handshake. That key material is the mathematical input to a Shor's algorithm attack.

2030 matters because it is the conservative lower bound of the credible CRQC probability window in the published expert literature. The Global Risk Institute Quantum Threat Timeline Report 2024 (Mosca and Piani) places meaningful probability of CRQC capability from 2030 onwards. NIST IR 8547 (November 2024) deprecates RSA and ECC for new systems by 2030. NSA's CNSA 2.0 advisory mandates RSA and ECC retirement from National Security Systems by 2033, a deadline that implies a government-assessed probability of CRQC capability before that date. The 2030 figure is not an alarmist projection. It is the lower bound of estimates published by the organisations responsible for setting cryptographic policy.

The connection between the two years follows from Michele Mosca's inequality, published in IEEE Security & Privacy in 2018. If the time required to complete a cryptographic migration (X) plus the required confidentiality lifetime of the data (Z) exceeds the time until a CRQC (Y), the data is at risk under harvest-now, decrypt-later (HNDL) attack. An organisation with 2018-era archives that must remain confidential until 2030 or beyond, and whose migration programme will take several years to complete, has X + Z > Y and is inside that risk window today.

How Captured TLS Traffic Becomes Readable

The mechanism is specific and worth explaining directly. During a TLS handshake, the client and server exchange ephemeral ECDH public keys to derive a shared session secret. That public key exchange is visible in plaintext in the handshake records, even though the session payload is encrypted. An adversary capturing TLS traffic in 2018 captured both the encrypted payload and the public key material needed to derive the session key.

On a CRQC, Shor's algorithm solves the elliptic curve discrete logarithm problem (ECDLP): given the ephemeral public key, it recovers the corresponding ephemeral private key. From the private key, the adversary reconstructs the TLS session's pre-master secret and all derived symmetric session keys. The AES-encrypted payload that follows the handshake becomes readable.

A common 2018 cipher suite was ECDHE-RSA-AES128-GCM-SHA256: ECDHE for key exchange, AES-128-GCM for bulk encryption. Once Shor's algorithm breaks the ECDHE key exchange to recover the AES-128 session key, the bulk encryption provides no residual protection. For completeness: Grover's algorithm also reduces AES-128's effective key length from 128 bits to approximately 64 bits under quantum brute-force attack (Grassl et al., PQCrypto 2016). The realistic attack path for 2018 HNDL archives is via the ECDHE key exchange break, not symmetric brute force, but both vulnerabilities exist in the AES-128 layer.

For the underlying mechanics of Shor's algorithm and what it does to RSA and ECC specifically, see our detailed treatment of Shor's algorithm and public-key cryptography.

Which Archived Data Faces This Risk

Not all 2018-era encrypted data carries the same risk. The relevant question is whether the confidentiality requirement extends past the point at which a CRQC might be available.

Data categories that are specifically at risk include:

• Enterprise email archives under regulatory hold. MiFID II Article 16(7) requires financial services firms to retain communications records for five to seven years. Email transmitted over TLS-protected SMTP in 2018 under a seven-year retention falls due in 2025 or later. Records from late 2018 with seven-year retention are still in the risk window. NHS Records Management Code of Practice 2021 sets a minimum retention of eight years after last clinical contact for adult records. A clinical record from 2018 must remain confidential until at least 2026; for records with longer clinical holding requirements, that extends further.
• Financial transaction records. SWIFT and REST API calls made over TLS-protected connections in 2018, where the underlying transaction records are retained for five to seven years under MiFID II, represent a concentrated archive risk for financial services organisations.
• Legal correspondence with permanent privilege. Client communications under legal professional privilege carry a permanent confidentiality obligation. The privilege itself is a common law doctrine; the solicitor's duty of confidentiality is codified in SRA Code of Conduct, para 6.3. An encrypted email archive from 2018 containing privileged correspondence is in the risk window indefinitely: there is no point at which the confidentiality requirement expires and moves Z to zero.

Data that is not at risk from 2018 HNDL includes retail browsing sessions (no retention requirement), content that was public at the time of transmission (press releases, marketing pages served over HTTPS), and data whose confidentiality requirement has already legally expired. The risk is specific to retained, confidential data whose sensitivity has not been extinguished by time.

See our data classification analysis at which data is most at risk from HNDL today for a full taxonomy.

The Pre-2018 Problem: RSA Key Transport and the Absence of Forward Secrecy

The ECDHE key exchange used in 2018 provides forward secrecy: each TLS session generates a fresh ephemeral key pair, so breaking one session's key does not expose any other session. An adversary with 2018 ECDHE archives must break each session's ephemeral key individually. That multiplies the quantum computational work required, though it does not eliminate the threat for targeted sessions.

Pre-2018 TLS environments using RSA key transport (TLS 1.0/1.1, deprecated by RFC 8996 in March 2021, but widely deployed before that) face a worse situation. In RSA key transport cipher suites such as TLS_RSA_WITH_AES_128_CBC_SHA, the server's long-term RSA private key is used to decrypt the pre-master secret from every captured session. There is no session-specific ephemeral key. Breaking the server's RSA private key once decrypts every captured session simultaneously. Pre-2015 archives from environments that had not yet migrated to ECDHE-based cipher suites carry this elevated exposure. One CRQC computation against the server's RSA key unlocks the entire archive.

What Can Be Done Now

For data in transit from this point forward, the answer is clear: deploy hybrid TLS key exchange using X25519 combined with ML-KEM-768 (per IETF RFC 9496). The ML-KEM-768 component is not vulnerable to Shor's algorithm, so a future CRQC cannot recover the session key from captured traffic. This step does not require changes to application logic and is available now in OpenSSL 3.5, BoringSSL, and wolfSSL.

For archives from 2018 and earlier, there is no technical fix available. The ciphertext is fixed. The public key material captured alongside it is fixed. A CRQC with Shor's algorithm can reconstruct the session keys from what was already collected. Three risk management options remain:

1. Destruction. Data that has passed its legal minimum retention period and is no longer required can be destroyed. This is the only active risk reduction for historical archives: it eliminates the adversary's target. Review retention schedules against actual legal obligations rather than defaulting to maximum retention periods.
2. Documentation and acceptance. Data that must be retained accepts a residual risk that requires a board-level risk acceptance decision, documented in writing, with clear acknowledgement of what a future CRQC decryption could expose.
3. Treat as potentially compromised. For the highest-sensitivity archives, plan as though the data may be readable from the point a CRQC becomes available. Review what downstream decisions or obligations are affected by that assumption.

The prerequisite for any of these options is a Cryptographic Bill of Materials (CBOM): a structured inventory identifying which archived data was protected by ECDHE or RSA key exchange, what its current confidentiality status is, and what its legal retention expiry date is. Without that inventory, the organisation cannot make informed decisions about which archives to destroy, accept, or flag for special handling. NIST NCCoE SP 1800-38B (2024) defines the CBOM methodology as the foundation for any PQC migration programme.

To apply the Mosca inequality to a specific archive's risk profile, use the QSECDEF HNDL Risk Calculator at /tools/hndl-risk-calculator/.

The question to ask for any significant archive from 2018 is not whether it is encrypted. The question is what key exchange mechanism protected the session that delivered the encryption key, and whether that mechanism is vulnerable to a CRQC with Shor's algorithm. For most enterprise archives from that period, the honest answer is: yes.