Post-Quantum Cryptography in Carrier Core Routing

Executive summary

Post-quantum cryptography (PQC) adoption in carrier core routing has moved from a planning exercise to an active deployment requirement, driven by NIST's August 2024 finalization of ML-KEM, ML-DSA and SLH-DSA, as well as the well-established harvest-now-decrypt-later threat targeting backbone infrastructure carrying concentrated traffic from thousands of customers simultaneously.

Cisco, HPE Networking and Nokia, the three vendors in WWT's Core Routing practice, are at materially different stages in delivering quantum-safe features. All three have documented support for RFC 8784 post-quantum pre-shared key approaches in at least some IPsec/IKEv2 platforms and releases, while Nokia has also published a carrier IPsec roadmap that includes ML-KEM hybrid key-exchange direction for platforms such as the 7750 SR.

Core routing presents migration challenges distinct from other network domains, including 7–10-year hardware cycles, heterogeneous multi-vendor peering environments, and deep dependencies on classical PKI. Together, these challenges mean that planning decisions made now will constrain or enable options through the end of the decade.

The primary near-term actions include completing a cryptographic asset inventory, deploying RFC 8784 PPKs for immediate IPsec protection and aligning hardware refresh decisions with PQC platform requirements before Q-Day timelines compress.

Methodology

This WWT Research Note draws on publicly available vendor documentation, IETF RFC standards, NIST PQC publications and WWT technical analysis across the Core Routing practice. Vendor capability assessments reflect publicly known information as of Q1 2026 and should be validated against current vendor roadmaps before operational planning.

Companion research

Don't miss our research on two related networking topics:

1. Post-Quantum Cryptography on WAN Technologies
2. Post-Quantum Cryptography Support in the Campus LAN

Introduction

Core routing infrastructure occupies a uniquely exposed position in the PQC threat landscape for at least five compounding reasons:

1. Concentration of sensitive transit traffic: Carrier backbone routers simultaneously carry traffic from thousands of enterprise customers, government agencies and financial institutions. Unlike a campus network, where compromise exposes one organization's traffic, a compromised core router or transit path exposes a cross-section of many customers at once. The concentration of high-value, long-lived traffic on backbone infrastructure makes it a particularly attractive target for harvest-now-decrypt-later attacks.
2. Longest hardware refresh cycles in networking: Core router platforms commonly remain in production for 7–10+ years. Hardware decisions made today — particularly around silicon capabilities for cryptographic acceleration — will determine PQC feasibility across the next decade. Organizations that acquire PQC-incapable platforms now will face a choice between expensive mid-cycle hardware replacement and continued reliance on classical cryptography beyond the projected CRQC (cryptographically relevant quantum computer) arrival window.
3. Regulatory and contractual exposure: Many carrier operators serve customers subject to U.S. government PQC target mandates (i.e., Dec. 31, 2030, for post-quantum key establishment and Dec. 31, 2031, for post-quantum authentication/signatures), NSA CSfC requirements and/or emerging EU NIS2/ENISA cybersecurity frameworks that increasingly reference PQC readiness. Beyond direct regulation, enterprise customers and government agencies will increasingly require their carriers and interconnect partners to demonstrate PQC-capable infrastructure as a contractual condition of service.
4. Interconnect dependencies and systemic risk: Carrier networks interconnect with each other at Internet Exchange Points (IXPs) and via Network-to-Network Interfaces (NNIs). PQC migration on one side of a peering session is only effective when both sides have migrated. This creates a coordination problem that spans organizational and contractual boundaries — one requires early conversation, not last-minute negotiation.
5. Foundational protocols still being redesigned for PQC: The security protocols that core routing depends on are mid-migration at the standards level, not only in the vendor gear that implements them. Route origin validation via RPKI, path validation via BGPsec and DNS integrity via DNSSEC all rely on quantum-vulnerable RSA and ECDSA signatures, and their post-quantum replacements are still being drafted in IETF working groups. Some of this work is technically hard: Post-quantum signatures are far larger than classical ones, which strains protocols like DNSSEC that were never built to carry them. Until these standards mature, parts of the core routing trust model stay quantum-vulnerable even after an operator has done everything within its own control, a dependency that sits upstream of any single carrier.

PQC threat surface in core routing

The threat surface in carrier core routing is broader than it first appears. It spans the control plane, data plane and management plane, with different vulnerability profiles and migration timelines for each.

Control plane

Routing protocol authentication

IS-IS and OSPF use HMAC-based authentication with symmetric keys. HMAC-SHA256 provides approximately 128-bit post-quantum security (Grover's algorithm halves symmetric key strength), which places it within an acceptable range for near-term use. It is worth noting that IS-IS and OSPF authentication keys are frequently operator-chosen strings with far less entropy, and Grover's practical advantage against symmetric primitives is narrower than the halving heuristic implies. Moreover, BGP uses TCP-MD5 or TCP-AO for session authentication — protocols that carry their own vulnerability profiles and interact with the larger PKI ecosystem through RPKI.

RPKI (the sleeping giant)

Resource Public Key Infrastructure (RPKI) secures BGP route origin validation through X.509 certificates using RSA and ECDSA — both quantum-vulnerable algorithms. The certificates that validate route origin data have long lifetimes and are issued by a small number of Regional Internet Registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC). Compromising the PKI hierarchy underlying RPKI would allow an adversary to forge route-origin certificates and invalidate the BGP security posture of the entire carrier ecosystem.

The IETF SIDROPS working group is tracking PQC extensions for RPKI, but the work is in its early stages, and no standards have been finalized. Carriers with RPKI deployments should closely track this work. RPKI PKI migration will require coordination across the global RIR hierarchy. This is not a problem any single carrier can solve on its own.

BGPsec

BGPsec (RFC 8205) uses ECDSA signatures on path attributes and is quantum vulnerable. Its low deployment rate means it is not a widespread near-term risk, but any carrier that has deployed BGPsec should include it in its PQC planning scope. No finalized PQC extension for BGPsec exists as of this writing.
 

Data plane

IPsec / IKEv2

This is the most immediately actionable PQC gap in carrier core routing. IPsec is widely used for encrypted backhaul (5G transport, enterprise VPN termination, inter-datacenter links and NNI encryption). IKEv2's Diffie-Hellman key exchange is quantum-vulnerable. 

Two RFC standards provide the migration path:

• RFC 8784: Post-Quantum Pre-Shared Keys (PPKs) for IKEv2. Adds PQC protection without requiring a full PQC stack. Available in production on Cisco IOS XR and Nokia SR OS today. This is the recommended immediate action for any carrier with active IPsec tunnels.
• RFC 9370: Multiple Key Exchanges for IKEv2. The proper hybrid path (classical DH + ML-KEM simultaneously). Provides defense-in-depth: If either algorithm is broken, the session remains secure. This remains largely a forward-looking capability in carrier routing. While Cisco and HPE Networking have begun introducing hybrid key exchange support in parts of their portfolios, it is not yet widely implemented across core routing platforms.

MACsec on core and metro links

Carriers increasingly deploy MACsec for link-layer encryption on metro Ethernet, dark-fiber interconnects and peering links. MACsec's AES-GCM data plane is quantum-resistant, but the control plane — the MKA (MACsec Key Agreement) protocol using 802.1X/EAP-TLS — is quantum-vulnerable when relying on classical certificates. As platforms add support for EAP-TLS 1.3 with ML-KEM, this vulnerability will be closed.

Segment routing (SR-MPLS/SRv6)

Segment Routing (SR) does not natively encrypt traffic. When IPsec or MACsec is overlaid for encrypted transport over SR-MPLS or SRv6, the PQC considerations collapse into those protocols. However, SR policy and segment list integrity depend on the authenticity of the control plane (IS-IS, BGP-LS, PCE). Therefore, it is important to confirm that the control plane building SR topologies are protected by quantum-safe authentication.
 

Management plane

The management plane is the most neglected PQC surface in carrier routing, and arguably the one with the shortest path to exploitation. An adversary who can decrypt management-plane traffic gains access to device credentials, configuration data, routing table dumps and operational commands — intelligence that compounds the value of any data-plane harvest.

• SSH: Used for interactive logins, automated provisioning (Ansible, Nornir, Salt) and scripted operations. SSH key exchange uses Diffie-Hellman or ECDH, both quantum-vulnerable. PQC KEX extensions for SSH are in development at IETF (SSHM WG) but are not yet widely available in router operating systems.
• NETCONF/YANG: Runs over SSH and inherits its vulnerability. Widely used for configuration management and telemetry.
• gRPC/gNMI: Streaming telemetry runs over TLS. Those TLS sessions require PQC handshakes. Network automation pipelines built on gNMI are an overlooked PQC dependency.
• NOC tooling: NMS platforms, orchestrators (Cisco Crosswork, HPE Routing Director, Nokia NSP) and automation frameworks all use classical crypto in their management sessions and API connections.

Recommendation: Treat the management plane as a first-class PQC migration target alongside the data plane. An operator who has quantum-safe IPsec tunnels but a classically authenticated management plane remains vulnerable to credential theft and configuration exfiltration.

Hardware and silicon considerations

PQC algorithms are computationally viable — ML-KEM adds negligible latency per key exchange — but at carrier scale, aggregating millions of tunnel negotiations, management sessions, and protocol authentications means hardware capabilities matter. Not every deployed platform will support PQC through a software upgrade.

The critical platform question

For every platform in the deployed base, operators need a clear answer to the question: Can existing silicon support PQC via firmware or microcode updates, or does PQC require new linecards or a chassis replacement? This question cannot be answered generically — it requires platform-specific, linecard-specific and software version-specific engagement with each vendor.

Hardware crypto acceleration

Platforms with dedicated crypto ASICs can handle ML-KEM key exchange with minimal CPU impact. 

Older platforms using software-only crypto may achieve acceptable performance for management-plane PQC but face bottlenecks during high-volume tunnel termination.

FPGA-based forwarding architectures (as found in some Nokia platforms) offer a meaningful advantage: cryptographic capabilities can be updated through bitstream changes without silicon replacement.

Crypto-agility (the strategic differentiator)

Crypto-agility is the ability to quickly swap cryptographic algorithms when a vulnerability is discovered — without requiring hardware replacement or service disruption. PQC algorithms are newer and less battle-tested than AES or SHA-2. NIST itself acknowledges the possibility that cryptanalytic advances could weaken a standardized PQC algorithm, which is why algorithm agility is considered a design requirement rather than a nice-to-have.

Platforms with modular, software-configurable cryptographic stacks offer a significant advantage over fixed-function implementations. This should be an explicit evaluation criterion in hardware refresh decisions, not an afterthought.

PQC maturity model for core routing

Organizations can assess their current PQC posture and plan migration using a four-stage maturity framework. The model applies across all cryptographic surfaces in core routing and provides a common language for tracking progress across teams, vendors and interconnect partners.

Most carrier operators will spend considerable time at Level 2 and Level 3 during the transition period. That is expected and by design. The hybrid approach at Level 3 is the recommended near-term enterprise state: It achieves quantum safety while maintaining interoperability with peers who may not yet be fully PQC-capable.

Vendor analysis: Cisco, HPE Networking and Nokia

The three vendors in WWT's Core Routing practice are at different stages of PQC delivery, with different strategic angles and platform-specific considerations. The comparison below reflects publicly known capabilities as of early 2026 and should be validated against the vendors' current roadmaps.

Cisco

Cisco is the most vocal and advanced of the three in carrier routing PQC, driven by a "WAN-first" strategic position and active leadership in IETF standards. Cisco authored RFC 8784 (PPKs for IKEv2) and co-authored RFC 9370 (Multiple Key Exchange for IKEv2), positioning PQC as a near-term deployment priority rather than a roadmap aspiration.

Platform considerations

Cisco 8000 Series Core Routers (IOS XR): The flagship PQC platform for carrier core roles. Built on Silicon One (Q100/Q200) with hardware acceleration for ML-KEM and ML-DSA. RFC 9370 hybrid key exchange is in production as of IOS XR 26.1.1 and was validated as interoperable with Cloudflare IPsec in April 2026.

Cisco 8000 Series Secure Routers (IOS XE): A separate family that shares the 8000 name but serves enterprise WAN edge and aggregation, not the backbone. Positioned as a purpose-built quantum-safe WAN infrastructure, the G2 generation runs IOS XE on Quantum Flow Processor ASICs and delivers line-rate PQC IPsec and MACsec. Carriers will encounter it in managed WAN and CPE services rather than core routing, but it signals how far Cisco has pushed PQC across its portfolio.

ASR 9000: Widely deployed in carrier cores. PQC support is platform- and linecard-dependent. Software PQC is viable for management plane and low-volume tunnel scenarios; high-throughput tunnel termination requires explicit hardware capability confirmation.

NCS 5500/NCS 540: Used extensively in transport and metro roles. PQC roadmap is less publicized than the 8000 Series. Explicit clarity on the availability of IOS XR versions and silicon-level PQC support is required for each NCS linecard in the deployed base.

Key strengths

• RFC 8784 PPKs available in production — immediate IPsec protection without full PQC stack
• RFC 9370 + ML-KEM hybrid KEM in production on 8000 Series core routers (IOS XR 26.1.1); validated interoperable with Cloudflare IPsec in April 2026
• Broad protocol coverage: IKEv2/IPsec, FlexVPN, DMVPN, MACsec with EAP-TLS, SSH
• IOS XR's modular architecture supports crypto-agility without full software replacement

Questions to drive with Cisco

• What is the specific PQC support matrix for ASR 9000 and NCS 5500 (i.e., which linecards, which IOS XR versions)?
• What is the timeline for SSH PQC KEX support in IOS XR?
• How does Crosswork (network automation) handle PQC certificate trust chains?
• Is there a product matrix for supporting new NIST 800-208 and PQC functions and algorithms?
   

HPE Networking (formerly Juniper)

HPE Network has been methodical rather than vocal about PQC delivery. An important platform-specific distinction applies: RFC 8784 Post-Quantum Pre-Shared Key (PPK) support in Junos is documented for SRX Series security gateways as of Junos 22.4R1, but production availability on MX Series (carrier edge and aggregation) and PTX Series (carrier core) should be validated directly with HPE before deployment planning. 

HPE Networking's strength is consistent feature delivery across its platform family once a feature enters the mainline Junos release, and its deep expertise in SRv6 and EVPN architectures is directly relevant to carriers evaluating encryption overlays on modern IP/MPLS cores.

Platform considerations

PTX10000: HPE Networking's carrier core platform. PQC roadmap is in active development. The PTX uses HPE Networking's own Express forwarding ASICs; hardware acceleration for PQC is platform-dependent and should be confirmed on a case-by-case basis.

MX Series: Widely deployed at carrier edges, aggregation and peering. Hybrid PQC KEX (RFC 9370) availability on the MX should be validated directly with HPE before deployment planning. The Trio/Express ASIC generations handle software PQC, with performance scaling considerations for high-volume deployments.

ACX Series: Used in metro/access aggregation roles. PQC timeline and hardware capability should be confirmed specifically for ACX platforms, as the access tier is often the last to receive security feature parity.

Key strengths

• RFC 8784 PPKs are available in production on SRX Series (Junos 22.4R1+); MX/PTX carrier routing: validate platform-specific availability with HPE
• Consistent feature delivery across platform families once in Junos
• EVPN and SRv6 architecture expertise with encryption overlay consideration
• Active IETF contributor across relevant working groups

Key gaps to address

• SSH PQC KEX is still in development — management plane protection lags data plane
• MACsec + EAP-TLS PQC timeline not publicly committed
• Hardware acceleration specifics per linecard are not widely published

Questions to drive with HPE Networking

• What is the specific Junos version for hybrid PQC KEX, and which platforms and linecards is it validated on?
• What is the delivery timeline for SSH PQC KEX in Junos?
• How does Paragon Automation handle PQC certificate trust for gRPC/gNMI telemetry?
• Is there a product matrix for future support of RFC 9867?
   

Nokia

Nokia is the most differentiated vendor in this space from a carrier routing PQC perspective. While earlier assessments placed Nokia primarily on a roadmap, Nokia documents RFC 8784 PPK support in SR OS and markets quantum-safe IPsec on the 7750 SR today, with ML-KEM hybrid mode in active development on its 7750 SR platform. 

Nokia has pursued a dual-track quantum-safe strategy: NIST-standardized PQC for scalable software-layer protection and QKD integration for ultra-high-security use cases in European carrier and government environments. 

Nokia Bell Labs has deep PQC research credentials, and Nokia is active in ETSI and ITU-T standards bodies alongside NIST-track work, making it particularly relevant for operators navigating both U.S. and European regulatory frameworks.

Platform considerations

Nokia 7750 SR-s/SR-e: Nokia's flagship carrier routing platform. SR OS supports RFC 8784 PPK, and the ML-KEM hybrid exchange is in active development. The FP5 NPU supports advanced packet processing, and the platform supports up to 400 Gb/s per encryption services appliance, scaling into multi-terabit aggregate capacity per chassis.

Nokia 7250 IXR: Used in interconnect and peering roles. Relevant for NNI and IXP scenarios where PQC negotiation with third-party peers is a priority.

Nokia SR Linux: Nokia's cloud-native NOS for data center and disaggregated applications. As a newer platform, SR Linux may have a different PQC implementation timeline than SR OS, warranting separate tracking.

Key strengths

• RFC 8784 PPKs are available in production on 7750 SR (SR OS); ML-KEM hybrid exchange is in active development
• Dual-track quantum-safe strategy: PQC for software protection + QKD for ultra-high-security scenarios
• Active in ETSI and ITU-T standards bodies — particularly relevant for European carrier regulatory environments
• FPGA-based elements in some platform architectures allow cryptographic updates without silicon replacement
• Nokia's optical networking (1830 PSS with Photonic Service Engine, keyed by the 1830 SMS) is exploring quantum-safe encryption at the optical layer — a distinct angle not available from Cisco or HPE Networking

QKD consideration

Nokia has been involved in Quantum Key Distribution (QKD) trials in European carrier networks. While QKD is not a near-term carrier deployment path — it requires dedicated fiber, specialized hardware and has significant distance and scalability constraints — it is a meaningful differentiator for ultra-high-security carrier environments. Organizations evaluating Nokia should understand where QKD fits within Nokia's overall quantum-safe networking roadmap compared to software PQC.

Questions to drive with Nokia

• What is the specific SR OS release timeline for RFC 9370 hybrid KEM and draft-ietf-ipsecme-ikev2-mlkem ML-KEM interoperability?
• What is Nokia's PQC roadmap for SR Linux specifically?
• How does Nokia Network Services Platform (NSP) handle PQC for management plane operations?
• For customers interested in QKD: What are the current trial results, and what is the commercial availability roadmap?

Interoperability and multi-vendor environments

Multi-vendor interoperability is a carrier-specific challenge that enterprise and campus environments largely do not face. A BGP peering session at an IX, an IPsec-encrypted NNI or a MACsec interconnect link necessarily involves equipment from different vendors — often running different OS versions with different PQC implementation timelines. This is not a problem that can be solved by a single vendor; it requires standards-based negotiation and phased coordination.

The RFC foundation for interoperability

The IETF standards that enable PQC in routing are the interoperability foundation across vendors:

• RFC 8784: PPKs for IKEv2 — near-term IPsec protection; available in production on Cisco IOS-XR and Nokia SR OS.
• RFC 9370: Multiple Key Exchange for IKEv2 — hybrid KEM, the proper long-term path.
• RFC 9242: IKE_INTERMEDIATE exchange — the enabling mechanism RFC 9370 uses to carry large post-quantum key shares.

RFC compliance is necessary but not sufficient for interoperability. Different vendors have different implementation timelines, different hybrid-mode negotiation behaviors and potentially different cipher suite preferences. Lab validation across vendor combinations is essential before production rollout on shared links.

NNI and peering coordination

Encrypted NNI connections and IXP peering links require agreement on PQC parameters on both sides. This creates coordination requirements across organizational boundaries:

• Begin conversations with peering partners about PQC migration timelines now — especially for any encrypted peering relationships.
• Evaluate whether existing NNI and peering SLAs need to be updated to include PQC requirements and timelines.
• IXP operators (DE-CIX, Equinix, etc.) will increasingly be asked about their PQC posture for route server and management infrastructure.

PKI as the interoperability bottleneck

In virtually every carrier PQC deployment, PKI readiness will be the bottleneck, not the router operating system. Quantum-safe certificates, quantum-safe root CAs and RADIUS/EAP servers supporting PQC certificate chains must be in place before EAP-TLS or management-plane PQC can function. The PKI migration is a shared dependency that spans network operations, security operations and certificate management teams.

Standards landscape and known gaps

Understanding where standards are mature versus where gaps exist is essential for realistic planning. Not every protocol used in carrier routing has a finalized PQC extension.

Mature/available

• ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205): finalized August 2024
• RFC 8784: PPKs for IKEv2, production-available on Cisco IOS-XR and Nokia SR OS.
• RFC 9370: Multiple Key Exchange for IKEv2, available on leading platforms
• RFC 9867: Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-Quantum Security

In progress/gaps

• PQC for RPKI: IETF SIDROPS WG has drafts in progress; not finalized. Carriers with RPKI deployments are not post-quantum secure today.
• PQC for SSH: IETF SSHM WG PQC KEX drafts are active but not yet widely implemented in router OSes. Management plane protection lags data plane.
• PQC for BGPsec: No active IETF work on BGPsec PQC extensions. Low urgency given the deployment rate, but a gap for relevant deployments.
• PQC for PTP: Authenticated PTP (IEEE 1588-2019) uses classical PKI for message authentication. As authenticated PTP deployment grows for 5G transport, it enters the PQC planning scope.
• Hybrid interoperability standardization: RFC 9370 defines the IKEv2 hybrid path, but equivalent work for all carrier protocols (SSH, NETCONF, gRPC, RSVP-TE) is at various stages. Interoperability cannot be assumed across vendors without explicit testing.

Migration roadmap

The following roadmap is organized by time horizon. Given the range of CRQC timelines, which include projections as early as 2029–2030, organizations should target PQC-Safe (Level 3) posture across critical infrastructure by 2027–2028, leaving sufficient time for validation and fallback removal before Q-Day — the hypothesized moment when quantum computers become powerful enough in the future to break standard public-key encryption.

Immediate (now to 12 months)

• Complete a cryptographic asset inventory across all core routing domains: Identify every IPsec tunnel, MACsec link, management session type and PKI dependency using classical key exchange. Visibility is the essential first step.
• Identify platforms in the deployed base that require hardware refresh for PQC support — engage Cisco, HPE Networking and Nokia for specific platform PQC support matrices. This will need to cover hardware root of trust (TAM or Trust Anchor Model), NIST SP 800-208 (which covers stateful hash-based signatures [LMS/XMSS]), as well as supporting NIST algorithms.
• Align hardware refresh cycles with PQC-capable platform selection — avoid committing to a 7–10-year lifespan for hardware that cannot natively support PQC.
• Deploy RFC 8784 Post-Quantum Pre-Shared Keys (PPKs) for existing IKEv2/IPsec tunnels as an immediate protection measure while native PQC matures.
• Harden existing classical encryption as a bridge measure: Upgrade to Suite-B-GCM-256, 4K RSA keys, SHA-384/512 and remove SHA-1 HMAC from all routing protocol authentication.
• Audit PKI infrastructure: Identify RADIUS/CA components that need PQC-compatible certificate support.
• Align networking, security and PKI teams on a shared roadmap and budget plan.

Mid-term (1 to 3 years)

• Deploy hybrid PQC KEX (RFC 9370) for IPsec across priority carrier domains: encrypted backhaul, inter-datacenter connections and high-value wholesale connections.
• Enable MACsec + EAP-TLS 1.3 with ML-KEM on core and metro interconnects (as platforms support it).
• Begin SSH PQC KEX deployment as vendor implementations become available — prioritize protecting the management plane on the highest-value core routers.
• Implement cryptographic session logging to track PQC vs. classical session ratios across the network.
• Validate hybrid PQC interoperability in lab environments across Cisco, HPE Networking and Nokia before production rollout on shared links.
• Engage peering partners and NNI counterparties on coordinated PQC migration timelines.
• Track IETF SIDROPS PQC RPKI work and begin planning RPKI PKI migration when standards stabilize.

Long-term (3 to 5 years/pre-Q-Day)

• Enforce PQC-Protected mode (no classical fallback) across all carrier domains where readiness has been confirmed.
• Complete RPKI migration to PQC-signed certificates as standards finalize.
• Validate that no classical crypto fallback is occurring on critical network segments.
• Confirm 100% of connected peers, management systems and PKI components are PQC-capable before removing fallback.
• Maintain crypto-agility monitoring: Track algorithm health and maintain rapid response capability if a PQC algorithm proves weaker than expected.
• Meet the December 2030 and 2031 U.S. government PQC mandates for all regulated and government-contract network segments.

Conclusion

Post-quantum cryptography in carrier core routing is not a distant planning exercise — it is an active migration requirement with a defined threat, concrete timelines and immediate actions available today. The harvest-now-decrypt-later threat is not hypothetical; it is occurring now, and backbone infrastructure is a primary target.

Cisco, HPE Networking and Nokia are all moving toward PQC-capable platforms and operating systems, with Cisco leading in production availability and standards authorship, HPE Net providing consistent cross-platform delivery, and Nokia differentiating through Bell Labs research depth and a dual-track quantum-safe networking strategy. No vendor has fully solved the problem, and multi-vendor interoperability testing remains essential before production deployment on shared carrier infrastructure.

The most important near-term decisions for carrier operators are hardware refresh alignment (confirming PQC-capable platforms are selected for all new purchases); cryptographic asset inventory (establishing baseline visibility into what needs to be migrated); and RFC 8784 PPK deployment (providing immediate IPsec protection while the broader PQC ecosystem matures). 

The organizations that begin taking these steps in 2026 will be the ones with options when the quantum threat timeline compresses.