RFC 9958 Just Landed. Your Crypto Infrastructure Is About to Change.

In June 2026, the IETF published RFC 9958: Post-Quantum Cryptography for Engineers. The authors come from Nokia, DigiCert, and Entrust - companies that spend their days neck-deep in cryptographic infrastructure and certificate management. This is not an academic paper speculating about quantum computers. It is an operational guide written by the people who will have to build the transition.

If you manage networks, operate data centers, or maintain TLS termination for anything at scale, RFC 9958 is relevant to you today. Here is what it says and why it matters.

Not a Routine Upgrade

The industry has done cryptographic transitions before. We moved from DES to AES. We bumped RSA keys from 1024 to 2048 bits. We deprecated SHA-1. Each transition was painful, but each was essentially a drop-in replacement: swap the algorithm, update your config, move on.

PQC is not that.

RFC 9958 makes this explicit: previous cryptographic updates were incremental. This one requires protocol redesign. The reason is structural. Post-quantum keys, signatures, and ciphertexts are significantly larger than what the Internet currently carries. And the mechanisms used to establish secure sessions - Key Encapsulation Mechanisms (KEMs) instead of Diffie-Hellman key exchange - have a fundamentally different interaction model at the API level.

The changes will be visible on the network. Handshakes grow in size. More packets are exchanged. The probability of fragmentation increases. In lossy environments, that directly translates into higher failure rates and latency that operators will need to troubleshoot with new tools. IKEv2, the ubiquitous VPN protocol, has already had to introduce new exchanges to handle larger PQC payloads. Expect similar adaptations across TLS, SSH, DNSSEC, and every other protocol that uses public-key cryptography.

The Byte Problem

Size is the single most practical concern for operators, and RFC 9958 dedicates significant attention to it. The numbers tell the story.

A classical X25519 ECDH key exchange produces a 32-byte public key and 32 bytes of shared secret material - 64 bytes on the wire during a handshake. ML-KEM (the NIST-standardized lattice-based KEM, formerly Kyber) at its highest security level produces a ciphertext around 1.6 kilobytes. A single ML-KEM exchange is roughly 25x larger than its classical counterpart.

The signature side is worse. ML-DSA (formerly Dilithium) signatures run about 2.4 kilobytes at the recommended security level, compared to 64 bytes for ECDSA or 256 bytes for a 2048-bit RSA signature. SLH-DSA (formerly SPHINCS+) signatures can range from 8 to 50 kilobytes depending on the security parameter. And these are the NIST-standardized algorithms - there are no smaller alternatives on the standards track.

These numbers add up fast in a real protocol. A TLS 1.3 handshake that currently fits in two round trips and a few hundred bytes of public key material and signatures could easily balloon to 5-10 kilobytes or more once both sides exchange certificates, signatures, and KEM ciphertexts using PQC algorithms. For a server that terminates tens of thousands of connections per second, that is not just a latency problem. It is a memory and CPU problem too.

At scale, those extra bytes matter. Cloudflare and Google have been running hybrid PQC experiments in TLS since 2022, and their published data shows measurable increases in handshake completion time, especially in regions with higher packet loss. For mobile networks and IoT - where MTU is often constrained to 1280 bytes or less and IPv6 minimum MTU is 1280 - the problem is amplified. Every extra round trip caused by fragmentation adds tens to hundreds of milliseconds of latency.

Constrained devices face disproportionate impact, and RFC 9958 calls this out explicitly. Larger messages mean higher energy consumption per connection, more complex fragmentation logic in constrained protocol stacks, and in some cases, hardware that simply cannot handle the new key sizes without replacement. The IETF is actively studying PQC deployment in constrained environments (through working groups like LAKE and CoRE), but no easy answers have emerged.

KEMs Change the Protocol

One of the more fundamental shifts RFC 9958 describes is the move from Diffie-Hellman key exchange to Key Encapsulation Mechanisms.

This is not just a different mathematical operation with the same shape. The API is different at every level. With DH, both sides contribute a key pair and symmetrically derive a shared secret in a two-message flow. With a KEM, one party generates an encapsulation that wraps the shared secret, and the other party decapsulates it. Who sends first matters. Which party bears the computational cost matters. Whether forward secrecy is preserved depends on how the KEM is composed with the protocol.

This matters because every major protocol implementation in production today assumes the DH model. TLS 1.3, IKEv2, SSH, WireGuard - they are all built around DH-style key agreement or RSA key transport. Adapting them to KEMs is not a find-and-replace operation. It requires rethinking message flows, handshake timing, and error handling. A KEM decapsulation failure, for instance, behaves differently from a DH key mismatch. The RFC warns that security properties protocol designers take for granted - binding between key exchange and peer identity, for example - may need to be re-established through new mechanisms when transitioning to KEMs.

The Harvest-Now Threat Is Already Here

RFC 9958 does not spend much time on fear-mongering about quantum computers, but it does highlight one threat that is active today: harvest now, decrypt later (HNDL). An adversary with sufficient resources can collect encrypted traffic today, store it, and wait for a future CRQC to decrypt it retroactively.

For bulk web traffic, the practical value of this is limited for most organizations. But for anyone handling long-lived sensitive data - government classified information, medical records, intellectual property that will remain valuable for decades - the threat is real and present. The encryption you deploy today needs to protect data that will still be sensitive when quantum computers arrive. That argument alone justifies starting the transition now.

Hybrid Deployments Are the New Normal

RFC 9958 is blunt about the timeline: the Internet will operate in a hybrid state combining classical and post-quantum cryptography for years. Think IPv4/IPv6 dual-stack, but for cryptography.

The reasoning is straightforward. Classical cryptography works today and is thoroughly analyzed. PQC is designed to resist future quantum threats but is less battle-tested. Nobody knows precisely when a cryptographically relevant quantum computer (CRQC) arrives, and nobody knows definitively whether today's PQC algorithms will withstand all future cryptanalysis. Hybrid schemes combine both - security holds as long as at least one remains trustworthy, and operators gain practical experience with PQC without putting all their trust in algorithms that have been public for less than a decade.

In practice, hybrid means carrying multiple keys, multiple signatures, and multiple certificates in every transaction. A TLS server that currently presents one X.509 certificate may need to present two: one classical RSA or ECDSA, one post-quantum ML-DSA. Certificate Authorities need to issue both types. Hardware Security Modules (HSMs) need to support both algorithm families. Protocol negotiation becomes more complex. The certificate lifecycle - issuance, renewal, revocation - effectively doubles in complexity and cost.

The Mosca model, cited in RFC 9958, frames the urgency simply. If your data needs to stay secure for x years, your PQC migration will take y years, and a CRQC arrives in z years, then you have a problem when x + y > z. For organizations protecting long-lived sensitive data, that inequality may already be true. The worst case is not a sudden quantum breakthrough. The worst case is running out of time because the migration took too long.

What Operators Should Start Doing Now

RFC 9958 is informational, not a standards-track document. It does not mandate anything. But it is the clearest signal yet from the IETF that PQC migration is not optional and the lead time is measured in years, not weeks.

First, inventory your cryptographic footprint. Most organizations do not know where cryptography is used in their infrastructure. TLS termination points, VPN concentrators, code-signing pipelines, certificate authorities, HSM-backed services, firmware signing, secure boot chains - catalogue all of them. Cryptographic agility starts with knowing what you have.

Second, start testing PQC algorithms on non-production systems. OpenSSL 3.x added support for ML-KEM and ML-DSA in late 2025. curl and Nginx have experimental builds with PQC support. Run them through your test suites. Measure the handshake sizes. See what breaks in your certificate management tooling. The problems you discover in a lab are significantly cheaper than the ones you encounter during an emergency migration driven by compliance or audit requirements.

Third, pay attention to your constrained devices. IoT gateways, small-form-factor network appliances, embedded controllers, and remote terminal units (RTUs) in industrial environments are the hardest to upgrade and most likely to require hardware replacement for PQC support. Identify them now. Factor replacement timelines into your 2027-2028 budget cycles.

Fourth, plan for hybrid operations. You will run classical and PQC cryptography simultaneously for years. That is a material operational cost: more CPU per handshake, more bandwidth per connection, more complex certificate management, and more failure modes to diagnose. Your infrastructure needs headroom.

Fifth, watch the NIST standards track and the IETF pquip working group. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) are finalized. FIPS 206 (FN-DSA) is on the way along with additional signature schemes from NIST's recent call. These are the algorithms you will deploy. Focus on them and ignore the noise from unstandardized alternatives.

The transition to post-quantum cryptography is not a 2030 problem. It is happening now. RFC 9958 is the field guide. Read it.