Post-quantum in the network: what is available today and what to prepare now

Post-quantum cryptography suffers from a communication problem: it is discussed as a future topic although the part with a deadline started long ago. The reason is unspectacular and has nothing to do with compute — it is storage.

Why the clock is already running

The attack model is “harvest now, decrypt later”: encrypted traffic is captured and stored today in order to be decrypted once a sufficiently capable quantum computer exists. For the attacker this is cheap — storage costs almost nothing, and they do not need to know what they have.

From that follows the only calculation that matters for planning: how long must the data traversing this link stay protected? For design data, patent preparation, HR or health records, ten years is a conservative assumption. Anyone sending such data over a link protected only classically has already missed the deadline — regardless of when the first cryptographically relevant quantum computer actually runs.

What has now been standardised

The uncertainty of recent years is over on this point. There are named standards, and the protocol work for IKEv2 is finished.

The relationship between the two RFCs is the practical core: RFC 9370 allows several key exchanges to be combined during an IKEv2 setup and a shared key to be derived from all of them. Because post-quantum keys are considerably larger than classical ones, RFC 9242 — the intermediate exchange — is needed so the messages do not have to be fragmented at the IP layer. Together they produce a hybrid exchange that stays backwards compatible.

Hybrid is the recommendation, not a lazy compromise

In a hybrid scheme a classical and a post-quantum method run simultaneously; the session key derives from both. The traffic therefore stays secure for as long as at least one of the two holds.

That is not hesitation but a reasoned transition strategy. The post-quantum methods are young, and their implementations younger still. The combination protects against the quantum computer without buying a new risk from an implementation flaw in a fresh algorithm. NIST, the NSA, Germany's BSI and France's ANSSI recommend this path consistently for the migration phase.

What is available on Cisco platforms — and what is announced

For Cisco Secure Firewall the schedule is public and unusually concrete. Two things are usable today, the rest is a dated roadmap:

The most important reading of that table: interim protection is not a future question. Anyone running ASA at 9.19 or later can enable hybrid exchange today on the links that carry long-lived confidential data. That is a configuration decision, not a procurement project.

MACsec is a different matter. Integrating post-quantum methods into the dynamic key exchange is in development, but timing statements should be treated with caution as long as the features do not appear in a released configuration guide. For data centre interconnects protected with MACsec today that means: the topic belongs on the risk list, not on the project plan.

The step that always comes first: the crypto inventory

Every migration plan founders on the same question: where exactly is what encrypted? Not at product level but per link and per algorithm. That survey is unspectacular, takes weeks and is the only part no upgrade can replace.

1. 01

   Record the links

   Every tunnel, every TLS termination point, every MACsec link, every management path. Including the ones nobody has touched in years — especially those.

2. 02

   Determine the methods per link

   Which key exchange, which signature, which key lengths? That is in the configuration, not in the data sheet.

3. 03

   Assign the data's protection lifetime

   A business question, not a technical one: how long must what flows here stay confidential? That number sets the priority, not the link's bandwidth.

4. 04

   Check peers and dependencies

   A hybrid exchange needs both ends. Third-party peers, cloud endpoints and older appliances decide the actual order of work.

5. 05

   Set the order and execute

   Long protection lifetimes with capable endpoints on both sides first. Migration as a regular change with a fallback plan, not as a special operation.

This inventory has a side benefit that often justifies the work on its own: it reliably finds the links still running outdated methods or expired certificates. The post-quantum question is then the occasion, not the only return. How we run such surveys and turn them into dependable changes is described under enterprise networks and network security.

What is realistic in twelve months

• A crypto inventory for the core links. Complete for site-to-site VPN, management access and data centre interconnects.
• Enable hybrid exchange wherever both ends support it. On ASA from 9.19 that is a configuration, not a project.
• Adjust procurement. New firewalls, routers and termination points are assessed on whether ML-KEM can be added by software — not on today's feature list.
• Tidy up certificate lifetimes and processes. The signature migration arrives in 2027; it only finds those prepared who know which certificates hang where — and the 47-day schedule forces automation anyway.
• Track the MACsec links as an open item. With a date for the next review, not as closed.

What is not realistic in twelve months: a fully post-quantum infrastructure. That is not a planning weakness but the state of the implementations. Pure PQC modes stay the exception for now; the hybrid transition is the target state for this phase.