When a security topic gets hot, engineers tend to get bombarded from both directions. On one side, there’s a flood of serious, fast-moving research and standards work. On the other, there’s hype, confusion, and a lot of “just swap the algorithm” advice that doesn’t survive contact with real systems.

Post-quantum cryptography (PQC) has been exactly that kind of space for the last few years.

What I hear again and again are the same practical questions from the people building and operating real systems: Which algorithms matter right now? What does “hybrid” actually mean in a protocol? What’s a migration path that doesn’t break everything? How big are the keys and signatures, and what does that do to handshakes and message sizes?

That’s the gap we set out to close in the IETF PQUIP working group. And it’s why I’m excited to share RFC 9958, Post-Quantum Cryptography for Engineers. It’s not a math paper, and it’s not a marketing deck. It’s a field guide for engineers who have to build, migrate, and ship real systems as the cryptographic ground shifts beneath their feet.

The transition is real. And it’s bigger than crypto libraries

The part of the PQC conversation that tends to get lost is that “post-quantum” doesn't just mean picking a new primitive. It means changing assumptions that have been baked into protocols, infrastructure, and operations for a long time.

If your mental model is “swap algorithm A for algorithm B,” you’re likely to be surprised by where the friction shows up. Sometimes it’s performance, but just as often it’s message sizes and the knock-on effects: fragmentation, retransmits, handshake timeouts, buffer limits, hardware constraints, certificate chain bloat, or some intermediate box that quietly enforces a maximum size you didn’t know existed.

The good news is that this is an engineering problem we know how to solve. But it requires approaching PQC as a migration program, not a feature flag.

What “hybrid” really means in the real world

If you’re trying to turn PQC into a plan that fits real roadmaps and real constraints, here’s a migration path that tends to work well and matches how we framed the problem in RFC 9958.

1. Inventory where public-key crypto actually lives

This sounds obvious, but it’s where almost every effort either succeeds or stalls. You don’t just have “TLS” and “certificates.” You have public-key cryptography sprinkled across places that don’t show up on your mental architecture diagram.

In most organizations, the first pass should cover: 

• TLS termination and service-to-service identity
• Certificate validation paths
• Artifact and code signing
• Device identity and enrollment
• Authentication flows that rely on signatures
• Any long-lived data protections where “decrypt later” is a realistic concern

Instead of looking for perfection on day one, look for the parts that will surprise you later if you don’t uncover them now.

2. Find the brittle paths before picking the “most important” system

A lot of teams start PQC testing by picking their crown jewel system. That can work, but it's usually a slow way to learn.

A faster way is to identify the paths where modest size increases or timing changes will cause immediate pain: MTU-sensitive links, UDP-heavy protocols, constrained devices, older stacks, deep proxy chains, and anything that has hard-coded limits around handshake or message size.

Those brittle paths are where you’ll learn the most, the fastest. Because they’ll show you the real integration constraints that will eventually apply everywhere.

DMARC is the enforcement mechanism that makes email authentication meaningful. Without it, SPF and DKIM provide data but no action. With DMARC at enforcement, unauthorized senders are blocked at the source.

This is Zero Trust for email. Verify the sender. Enforce the policy. Don't trust messages that fail authentication.

3. Decide what success looks like for your unique environment

There’s no single “PQC migration” that fits everyone. Your sequencing depends on what you control.

If you control both endpoints, you can move quickly and learn a lot in a pilot. If you don’t control endpoints (or you’re in a big ecosystem), you’ll likely need a longer compatibility story. If you have strict compliance requirements, you may need a more formal policy and validation approach earlier. If you have a long tail of embedded devices, your timeline and constraints will look different than a cloud-only service.

This is also where “hybrid” becomes a planning tool instead of a buzzword. In some environments, hybrid is a bridge that reduces risk while standards and implementations mature. In others, it’s a cost you avoid until you have a specific reason to pay it.

4. Treat crypto-agility as a deliverable, not a slogan

PQC is a major transition, but it won’t be the last time we have to evolve cryptography across deployed systems. The organizations that handle this well usually do a few things consistently:

• Keep algorithm choices out of application code where possible
• Invest in automation for certificate issuance and rotation
• Make negotiation and policy enforcement observable
• Plan rollbacks and staged deployment the same way they plan any other infrastructure change

Even if your first PQC pilot is limited, it can still deliver something valuable: better crypto-agility as an operational capability.

5. Pilot where you can measure outcomes and contain risk

Early PQC efforts should optimize for learning. Pick a bounded environment where you own the endpoints, somewhere you can observe failures and iterate quickly.

And be honest about what you’re measuring. The most useful early signals often aren’t “CPU cost.” They’re things like:

• Handshake success rate across real network conditions
• Interoperability across libraries and platforms
• Where fragmentation shows up
• What breaks in middleboxes

How much operational overhead gets introduced through things like certificate handling, logging, monitoring, and incident response

Your first pilot doesn’t need to prove a final architecture. It just has to surface the constraints you’ll need to design around later.

How I hope engineers use RFC 9958

If RFC 9958 does its job, engineers will have a shared reference point: a way to explain the problem clearly to teams that don’t live in cryptography, reason about tradeoffs like hybrid approaches and message size impact, and turn “we need PQC” into steps that can actually land in a roadmap.

This transition will take time, and it will touch more systems than most people expect. But it’s manageable if we treat it as what it is: a large-scale engineering migration that needs sequencing, testing, and operational discipline.

Where to go next

Learn best by getting your hands dirty? Check out DigiCert Labs, an interactive PQC playground where you can generate and download quantum-ready certificates to see what changes when you put post-quantum cryptography into real workflows.