RFC 9958 and the operational reality of PQC

The recent publication of RFC 9958: Post-Quantum Cryptography for Engineers signals a shift in how the industry approaches quantum risks. While quantum computing is still evolving and is regularly discussed in terms of 'sometime in the future', the implications are already clear.

A sufficiently powerful cryptographically relevant quantum computer (CRQC) would break the public-key cryptography used across today's Internet, including RSA, Diffie-Hellman, and elliptic curve systems that underpin protocols such as TLS, IPsec, and DNSSEC.

Not a routine upgrade

Operators have seen cryptographic changes before. Algorithms have been deprecated, key sizes increased, and new standards introduced. Those transitions were disruptive, but largely incremental. RFC 9958 makes it clear that this is not a simple algorithm swap. PQC changes the structure and message flows of protocols themselves. Keys and signatures are significantly larger, and the mechanisms used to establish secure sessions differ in terms of message size, flow, and timing. As a result, existing protocol designs often need to be revisited.

For operators, this means changes will be visible on the network. Handshakes grow in size, more packets are exchanged, and the probability of fragmentation increases. In lossy environments, that directly translates into higher failure rates and latency. This is already being seen in practice. Protocols such as IKEv2 (RFC 7296) have had to introduce new exchanges to handle larger PQC payloads. Similar adaptations are expected across other parts of the stack.

One of the more profound changes described in RFC 9958 is the move away from traditional Diffie-Hellman-style exchanges towards Key Encapsulation Mechanisms (KEMs) (RFC 9180). This is more than an implementation detail. KEMs follow a different interaction model, where one party generates and encapsulates a shared secret rather than both sides symmetrically deriving it. That difference can affect how many messages are exchanged, how quickly a session is established, and which security properties, such as forward secrecy, can be preserved.

For operators, these changes appear as altered handshake behaviour - different timing, different packet flows, and potentially new failure modes.

Hybrid deployments

The transition will not be immediate or clean, drawing parallels to IPv6 deployment. RFC 9958 emphasizes that the Internet will operate in a hybrid state for years, combining classical and post-quantum algorithms.

This reflects a dual uncertainty. Classical cryptography is well understood but will eventually break under quantum attack. PQC is designed to resist that future, but it is yet to be fully resolved.

Hybrid approaches combine both, ensuring security holds as long as at least one remains trustworthy. In practice, however, this means carrying larger keys, signatures, and certificates, supporting multiple algorithms simultaneously, and managing increased complexity in protocol negotiation and certificate handling.

That translates into heavier handshakes and more intricate interoperability challenges, especially when interacting with systems that are upgraded at different rates. One of the most tangible impacts of PQC is size. Keys, signatures, and ciphertexts are often significantly larger than what networks carry today. At scale, those extra bytes matter. Larger messages mean more packets, and more packets increase the likelihood of loss. In turn, that can drive retransmissions, increase latency, and put additional load on both endpoints and intermediary devices.

In constrained environments, including mobile networks, edge deployments, and IoT, the effect is amplified. More data exchanged during connection setup can affect everything from power consumption to user experience. These are operational concerns that sit outside cryptographic design but are central to successful deployment.

Migration expectations

A key message throughout RFC 9958 is that transition timelines are often underestimated.

Replacing cryptography is not just a matter of updating software. It can involve new hardware, updated cryptographic modules, changes to PKI systems, and alignment with regulatory and compliance frameworks. Familiar issues such as vendor readiness, testing cycles, and staged rollouts all extend the process, which will all apply under the duress of broken cryptography.

Even in relatively well-managed environments, this becomes a multi-year effort. During that time, systems must continue to interoperate, meaning old and new cryptography will coexist at scale.

This is where interoperability and management complexity increase.

While the timeline for practical quantum attacks remains uncertain, the RFC authors agree that preparation will take time. RFC 9958 frames it like this : The time needed to complete a migration may rival, or exceed, the time before quantum threats become real. Sensitive data encrypted today may remain exposed if that transition is delayed.

The implication is straightforward. The challenge is not just adopting PQC, but doing so while maintaining performance, reliability, and interoperability across live networks. While many may still see this as a future problem or someone else's responsibility, RFC 9958 makes it clear that preparation is a present-day task. That work should not begin when quantum computing arrives. It should begin now. At the very least, the RFC is worth reading now.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.