RFC 9958 for Engineers: A Practical Field Guide to PQC Migration

Quick answer: RFC 9958, “Post-Quantum Cryptography for Engineers,” is an informational IETF document published in June 2026 by the PQUIP working group that explains what actually breaks when protocols move to post-quantum algorithms: keys and signatures that run 6 to 700 times larger than their classical equivalents, fragmentation and packet-loss problems in protocols like IKEv2, chain bloat in PKI, and a hybrid deployment model designed to bridge the gap while PQC algorithms mature. This guide translates it into a practical migration sequencing path for engineers.

Most PQC guidance stops at “use ML-KEM instead of ECDH.” RFC 9958 is different. It was written by engineers at Nokia, DigiCert, and Entrust specifically because algorithm substitution is not what makes PQC migration hard. Protocol behavior under much larger keys and signatures is what makes it hard, and that behavior does not show up until you actually try to fit a 4,627-byte ML-DSA-87 signature into a protocol designed around 64-byte ECDSA signatures.

This guide translates RFC 9958’s core content, the size reality, the protocol-level failure modes, and the hybrid deployment model, into a practical field guide for engineers actually doing the migration work.

Key Takeaways

• RFC 9958 is an informational RFC from the IETF PQUIP working group, published June 2026, written to explain PQC’s operational impact rather than its mathematics.
• Lattice-based keys and signatures run roughly 6 to 10 times larger than classical equivalents for public keys, and 10 to 100 times larger for signatures; SLH-DSA signatures run up to 700 times larger than ECDSA.
• Those size increases break assumptions baked into older protocols: IKEv2 needed a new “Intermediate Exchange” (RFC 9242, used by RFC 9370) specifically to fragment PQC key exchange messages that no longer fit the original design.
• Hybrid PQ/T schemes, combining a classical and a post-quantum algorithm, are the recommended bridge: key exchange migration is largely self-contained, but signature migration touches certificates, CAs, HSMs, and trust anchors across the whole ecosystem.
• Key reuse across hybrid and single-algorithm certificates enables stripping attacks. RFC 9958 is explicit that hybrid keys must be freshly generated, never repurposed from an existing single-algorithm key.

What RFC 9958 Actually Is

RFC 9958, “Post-Quantum Cryptography for Engineers,” is an informational document from the IETF’s PQUIP (Post-Quantum Use In Protocols) working group, published in June 2026. It is not a standards-track specification and does not define a protocol. It is a reference document, written by authors from Nokia, DigiCert, and Entrust, aimed at engineers working on cryptographic libraries, network security, and infrastructure who need to understand what changes when a system moves to PQC, beyond simply swapping one algorithm identifier for another.

The document’s core argument is that PQC migration is not a one-for-one algorithm replacement. Key exchange, historically handled by Diffie-Hellman-family algorithms, and digital signatures, historically RSA or ECDSA, both change shape fundamentally under PQC, and protocols built around the old shapes need real engineering work, not just a config flag, to accommodate the new one.

The Key and Signature Size Reality Check

This is the number most engineers underestimate until they see it in a table.

Algorithm	Public key	Ciphertext / signature	Classical equivalent
X25519 (classical KEM)	32 bytes	32 bytes	—
ML-KEM-768	1,184 bytes	1,088 bytes	~37x larger than X25519
ML-KEM-1024	1,568 bytes	1,568 bytes	~49x larger than X25519
ECDSA-P256 (classical signature)	64 bytes	64 bytes	—
ML-DSA-65	1,952 bytes	3,309 bytes	~52x larger than ECDSA-P256
ML-DSA-87	2,592 bytes	4,627 bytes	~72x larger than ECDSA-P256
SLH-DSA-SHA2-128s	32 bytes	7,856 bytes	~123x larger than ECDSA-P256
SLH-DSA-SHA2-256f	64 bytes	49,856 bytes	~779x larger than ECDSA-P256

RFC 9958 frames lattice-based keys and signatures as growing by roughly 6 to 10 times for public keys and 10 to 100 times for signatures compared to classical schemes, calling this the best available trade-off for general-purpose use. SLH-DSA sits well outside that range, which is exactly why it is a narrow-use fallback rather than a general default.

See how HSM-as-a-Service supports ML-KEM key exchange pilots without a hardware procurement cycle.

Why These Sizes Break Protocols: Fragmentation, Timeouts, Chain Bloat

Size increases of this magnitude are not just a bandwidth inconvenience. RFC 9958 documents specific protocol-level failure modes that engineers need to plan around.

• UDP fragmentation in IKEv2: the original IKE_SA_INIT exchange cannot use IKE-level fragmentation, so PQC key material did not fit. RFC 9242 introduced an “Intermediate Exchange” specifically so RFC 9370 could carry PQC key exchange after the initial handshake, where fragmentation is available.
• Packet loss and timeouts: larger key exchange messages span more network packets. In lossy network conditions, that raises the total probability of losing at least one packet in the exchange, which increases handshake latency and can trigger retransmission timeouts that did not occur with classical key sizes.
• PKI chain bloat: a four-certificate chain signed with ML-DSA-87 instead of ECDSA carries roughly 70 times more signature data per certificate. Multiply that across a full chain, and TLS handshakes, OCSP responses, and certificate stores all grow substantially, with downstream effects on middlebox behavior and constrained-device memory.
• Constrained devices: IoT and embedded systems that were already tuned for classical key sizes face increased handshake latency, higher energy consumption, and a need for fragmentation logic that many were never designed to support.

Hybrid PQ/T Schemes: The Bridge, Not the Destination

RFC 9958 recommends hybrid post-quantum and traditional (PQ/T) schemes as the practical bridge during migration, because neither the classical algorithms nor the newer PQC algorithms are fully trusted on their own: classical algorithms will eventually fall to a cryptographically relevant quantum computer, while PQC algorithms are newer and less battle-tested against implementation bugs and unknown cryptanalytic weaknesses.

Two hybrid key agreement patterns show up in current standards work. A concatenated scheme, used in TLS 1.3 hybrid key exchange, combines the two shared secrets by concatenation before they enter the key derivation function. A cascaded scheme, used in RFC 9370 for IKEv2, applies the key derivation function once per algorithm in sequence. Either way, the resulting security holds as long as at least one component algorithm remains secure, which is the entire point of running classical and post-quantum algorithms together rather than switching outright.

One warning from RFC 9958 is worth calling out on its own: hybrid keys must be generated fresh, never built by pairing a post-quantum key with an existing classical key already in use elsewhere. Reusing a classical key across a single-algorithm certificate and a hybrid certificate opens the door to a stripping attack, where an attacker removes the post-quantum signature from signed data and presents the remainder as if it were signed only by the classical algorithm.

Migration Sequencing: Why Key Exchange Comes First

RFC 9958 draws a clear operational distinction between the two migration tracks, and it is the most actionable piece of sequencing guidance in the document.

PQ or hybrid key exchange is relatively self-contained, typically requiring changes only to the cryptographic library, such as OpenSSL, without touching the broader certificate and trust infrastructure. That makes it the right starting point: it lets teams gain operational experience with PQC in production with comparatively low blast radius.

Migrating to post-quantum or hybrid digital signatures involves much broader ecosystem changes: certificates, certificate authorities, certificate management protocols, HSMs, and trust anchors all need to move together. Starting signature migration prototyping and planning early, even while key exchange migration is still underway, is how teams surface those ecosystem-wide impacts before they become production blockers.

What We’d Actually Recommend

Start hybrid key exchange pilots now, since the library-level change is contained and the operational learning is valuable regardless of which protocol you touch first. In parallel, begin the much slower signature-side planning: inventory every certificate authority, HSM, and trust anchor that a signature migration will eventually touch, because that inventory work takes longer than the pilot and needs to be running concurrently, not sequentially, to avoid the ecosystem-wide changes RFC 9958 warns about becoming a late-stage surprise. Test under real network conditions, not just a lab environment, since the fragmentation and packet-loss effects RFC 9958 documents only show up under realistic latency and loss.

How Encryption Consulting Can Help

RFC 9958’s own sequencing, hybrid key exchange first, signature-side ecosystem planning in parallel, maps to two different products. HSM-as-a-Service is where the low-blast-radius key exchange pilot this guide recommends actually runs, FIPS-validated ML-KEM key management without a hardware procurement cycle. CertSecure Manager carries the broader signature-side migration, orchestrating hybrid and pure PQC certificate rollout across your CA hierarchy from a single policy plane, exactly the ecosystem-wide coordination RFC 9958 flags as the harder half of the transition.

Our PQC Advisory Services apply the inventory and sequencing this guide describes to both tracks at once, so the fragmentation, packet-loss, and chain-bloat effects covered above are planned for rather than discovered mid-rollout.

Engineering the Migration, Not Just the Algorithm

RFC 9958’s real contribution is refusing to treat PQC migration as an algorithm swap. Keys and signatures 6 to 700 times larger than what protocols were designed around create fragmentation, latency, and chain-bloat problems that only show up under real network conditions, and the hybrid PQ/T model exists specifically to buy time while those problems get engineered around rather than discovered in production. Key exchange migration first, signature-side ecosystem planning running in parallel, is the sequencing RFC 9958 itself recommends, and it holds up as practical guidance for almost any organization’s migration plan.

Frequently Asked Questions

Is RFC 9958 a standard that systems must implement?

No. It is an informational RFC, not a standards-track specification. It does not define a protocol or mandate behavior; it explains the engineering challenges of PQC migration and points to the standards-track RFCs, like RFC 9370 and RFC 9180, that do define specific protocol behavior.

Why are PQC keys and signatures so much larger than classical ones?

They rely on different mathematical hardness assumptions, lattice problems or hash function security instead of integer factorization or elliptic-curve discrete logarithms, and those problems require larger structures to reach equivalent security levels. It is an inherent trade-off of the underlying math, not an implementation inefficiency.

Why does RFC 9958 recommend starting with key exchange instead of signatures?

Key exchange migration is largely contained to a cryptographic library change, while signature migration touches certificates, certificate authorities, HSMs, and trust anchors across the whole ecosystem. Starting with the more contained change lets teams gain operational experience before tackling the broader signature migration.

Can a hybrid key reuse an existing classical key?

No. RFC 9958 is explicit that hybrid keys must be freshly generated. Reusing a classical key that also appears in a separate single-algorithm certificate creates a stripping attack risk, where an attacker removes the post-quantum component and presents the data as validated by the classical algorithm alone.

What is the practical impact of larger keys on IKEv2 VPN connections?

The original IKE_SA_INIT exchange could not fragment large key exchange messages, so PQC key material did not fit within the protocol’s original design. RFC 9242 and RFC 9370 solve this by moving PQC key exchange into a later, fragmentable exchange, but it required a protocol-level fix, not just a larger buffer.