The quantum threat: why encrypted traffic needs a migration plan

Some information must remain confidential for years after it crosses a network. If an adversary records the encrypted exchange, a later breakthrough may matter long after the original session has ended. The planning problem begins with the lifetime of the information and the time required to migrate. It does not require predicting the arrival date of a quantum computer capable of breaking today’s public-key cryptography.

This Field Note accompanies our Module 1 explainer in the Cisco Quantum Readiness course. It explains the threat in terms of network sessions, trust dependencies, and an inventory you can use to prioritize work.

Technical and policy sources checked October 12, 2026.

One connection performs several cryptographic jobs

Picture a branch application sending customer records to a central service. The connection needs shared key material, a basis for trusting its peer, and protection for its payload.

Key establishment lets the parties derive shared secrets. Authentication checks the peer’s identity through the protocol’s trust rules. Symmetric encryption, such as AES, protects the traffic using derived keys.

A future attacker who recovers the key-establishment secret may be able to reconstruct traffic keys without breaking AES directly. An attacker who can forge a signature attacks trust, with different consequences. An inventory that records only “AES-256 enabled” cannot describe either dependency. IETF’s Post-Quantum Cryptography for Engineers.

Shor and Grover affect different problems

Shor’s quantum algorithms address integer factorization and discrete logarithms. A sufficiently capable quantum computer could therefore threaten RSA, finite-field Diffie-Hellman, elliptic-curve Diffie-Hellman, and signatures such as ECDSA. Increasing a conventional RSA or elliptic-curve key size does not provide a practical post-quantum migration strategy. Shor’s paper.

The qualification “sufficiently capable” matters. A processor’s advertised qubit count is not, on its own, evidence that it can execute a cryptographically relevant attack. Reliability, error correction, and the resources required by the computation matter too. NIST does not give a known arrival date for that capability. NIST PQC introduction.

Grover’s algorithm provides a different theoretical advantage for searching for a symmetric key. Turning a query-count result into a practical attack requires substantial assumptions about hardware and execution. NIST’s current guidance permits continued use of AES-128, AES-192, and AES-256; it does not establish that AES-128 has become practically equivalent to a classical 64-bit cipher. Follow the profile that applies to your system, while reviewing key establishment independently. NIST PQC FAQ.

How harvest now, decrypt later creates exposure

An adversary may retain ciphertext and the public handshake material needed for a later attack. If the relevant public-key problem becomes solvable while the information is still sensitive, the recording may become useful. This is the concern commonly called harvest now, decrypt later. NIST’s explanation.

The exposure is conditional. The attacker needs useful captured material, future capability, and a vulnerable cryptographic path. Compromising one transport layer also does not automatically defeat an independently protected application payload.

For an enterprise review, trace the actual flow: branch to gateway, gateway to proxy, proxy to service, and any separately encrypted content within it. Identify what each layer protects and where it terminates. A label on the outer tunnel does not describe every record’s end-to-end protection.

Forward secrecy has a defined boundary

Forward secrecy is valuable because later compromise of long-term authentication keys should not reveal earlier session keys, under the protocol’s assumptions. TLS 1.3 describes this property explicitly. RFC 8446, Appendix E.1.

That guarantee addresses a particular failure: later theft of long-term key material. It does not promise that a recorded ephemeral Diffie-Hellman problem will remain unsolvable forever. Combining the forward-secrecy definition with Shor’s discrete-log result explains why a future quantum attack on recorded ephemeral DH or ECDH values remains a concern.

Deleting ephemeral private keys does not delete the adversary’s recording. Rotating a certificate does not recall old traffic. Moving to suitable post-quantum protection can reduce exposure for subsequent connections, while historical recordings remain a separate residual risk. Keep forward secrecy and rotation as useful controls, and evaluate the quantum-vulnerable dependency they do not replace.

Signatures create a separate migration workstream

Network infrastructure also relies on signatures to establish trust in certificates, software, and firmware. A future ability to forge a relevant signature can undermine those decisions. It does not mean an attacker retroactively joins an old TLS session or automatically replaces software already installed on every device.

The practical review follows the verification path: which keys are trusted, which algorithms are accepted, how updates are verified, how trust anchors change, and what happens when an algorithm is retired. Equipment with a long service life may need a supported upgrade path well before its normal replacement date. The standards companion article explains why key-establishment and signature standards must be evaluated separately.

Data lifetime changes the order of work

An expired one-time code and a long-lived customer record do not have the same confidentiality requirement. The transaction carrying the code might also contain identifying information that remains sensitive, so classify the data flow rather than judging it by one short-lived field.

Consider an illustrative migration that takes three years, while newly transmitted records need ten years of confidentiality. Records sent near the end of that migration can remain sensitive thirteen years from today. The arithmetic describes a protection horizon, not a forecast that a cryptographically relevant quantum computer will arrive in thirteen years.

The X9 risk study expresses the concern through the relationship between required protection lifetime, migration time, and uncertain time to adversary capability. Use several plausible scenarios and document the assumptions, instead of treating one estimate as an arrival forecast. ASC X9 quantum-computing risk report.

Would you close this risk finding?

Read this illustrative review note before opening the explanation:

The service uses AES-256, ephemeral ECDH, and regular key rotation. Customer records require ten years of confidentiality. The quantum exposure finding can be closed.

Which dependency still requires attention, and what evidence would you request next?

Compare your reasoning

Ephemeral ECDH still presents a quantum-vulnerable key-establishment dependency. AES-256 describes payload protection; rotation and forward secrecy do not resolve that mathematical threat. The note also leaves peer authentication unspecified.

Request the actual negotiated key establishment, authentication scheme, data-lifetime requirement, and supported migration options for both peers. Then test the intended replacement and its fallback behavior. The evidence should support a bounded decision for this service, rather than a claim that every historical recording or network dependency is now protected.

Deadlines describe policy, not the arrival of an attacker

A transition date needs its source, status, and affected systems attached. As checked for this article, NIST IR 8547 remained an Initial Public Draft. NSA’s October 2026 announcement describes 2027 requirements for new commercial National Security Systems and a 2030 phaseout for incapable legacy systems. These statements have different status and scope; neither establishes a universal quantum-computer arrival date. NIST status page; NSA announcement.

Start with a service you can describe

Create a record containing the information owner, required confidentiality lifetime, endpoints, protocol, key establishment, authentication, software versions, and upgrade dependencies. Add the business consequence of disclosure or forgery and the evidence needed to accept a migration.

That record turns a broad concern into assignable work. Start with valuable, long-lived information and dependencies that take time to change, then retain test evidence as each service moves. The Cisco Quantum Readiness course develops these concepts through threat analysis, standards, and migration planning. Reading and watching support that work; completing an independent analysis provides the evidence of your understanding.

RouteSwitchU is an independent training publisher and is not affiliated with or endorsed by Cisco Systems, Inc.