PQC Transition: Where to Start (A Practical Roadmap)

Last updated: October 25, 2026

If you’re confused about post‑quantum cryptography (PQC), you’re in good company. The confusion usually comes from treating PQC like a single switch you can flip. In practice it’s a set of migrations across different parts of your stack: protocols (TLS/VPN/SSH), PKI, signing pipelines, key custody (HSM/KMS), and the operational machinery that keeps it all from breaking at 2 a.m.

This page helps you pick a sensible starting point and a sensible next step – without pretending every organization should follow the same order.

The baseline facts (what’s “real” as of October 2026)

These are safe anchors for planning:

What this section contains (so you can pick the right page fast)

These are the guides currently in the PQC & Cryptography section:

  • Crypto Agility – how crypto transitions succeed operationally (inventory, policy, testing, rollback), not just “pick algorithms.”
  • CNSA 2.0 – what’s required (and not allowed) in NSS contexts, plus the timeline buyers plan around.
  • Crypto Inventory & CBOM – how to discover where crypto is actually used and represent it in a shareable way.
  • PQC for TLS/VPN/SSH – the constraints that break real deployments (interoperability, MTU, middleboxes).
  • PKI Migration to PQC – certificate profiles, trust stores, enrollment flows, CA/hardware constraints.
  • Certificate Rotation – the operational backbone: inventory, automation, safe reload, monitoring, rollback.
  • PQC Key Management (HSM/KMS) – key custody, access control, rotation, audit, and what changes with PQC key sizes.
  • PQC Signatures & Timestamping – code/firmware signing reality and why timestamping matters for long-lived verification.
  • Hybrid Signatures (Composite Signatures) – what “hybrid signature” means in X.509/PKI (not TLS), and why verifier support is the bottleneck.
  • Trusted Timestamping (RFC 3161) – how RFC 3161 works, what timestamp tokens prove (and don’t), TSA trust models.

Pick your starting point (three “first moves” that actually work)

Most teams land in one of these three buckets. Choose the one that matches your situation.

1) “We don’t know where crypto is used, and nobody agrees what’s in scope.”

Start with Crypto Inventory & CBOM

If you can’t answer “where are we using RSA/ECC, which services terminate TLS, where are signing keys, who owns each dependency,” every other decision becomes politics. Inventory turns PQC from a vague risk into a project list.

2) “Our biggest risk is operational: cert incidents, expiry outages, fragile mTLS.”

Start with Certificate Rotation

PQC transitions force more certificate and trust changes than most organizations are used to. If rotation is manual or brittle today, you’ll feel that pain immediately – regardless of which PQ algorithm you choose.

3) “We have external requirements (government, defense supply chain, procurement language).”

Start with CNSA Suite 2.0

If you’ll be judged against a requirement set with dates and parameter choices, read that first. It prevents wasted effort on solutions that won’t satisfy your buyers later.

Then choose your “track” (what are you actually trying to migrate?)

Track A: Protocols (TLS, VPN, SSH)

If your immediate concern is secure communications and interoperability, go here next:
PQC for TLS/VPN/SSH: Practical Migration Constraints

This is where you learn why “just enable PQC” fails: client/server skew, middleboxes, and VPN MTU/fragmentation realities.

Track B: PKI (cert issuance, trust stores, enrollment)

If your challenge is certificates and trust distribution, go here next:
PKI Migration to PQC

This is about certificate profiles, trust stores, and why “our CA can issue it” is not the same as “our ecosystem can validate it.”

Track C: Key custody and access control (HSM/KMS)

If your question is “where do keys live and who can use them,” go here next:
PQC Key Management (HSM/KMS)

This is where PQC becomes operationally concrete: key sizes, non-exportability, audit trails, and rotation/recovery.

Track D: Code signing / firmware signing (long-lived artifacts)

If you ship devices or sign artifacts that must validate for years, go here next:
PQC Signatures & Timestamping

This guide is intentionally about the reality of verifiers and long-lived verification- not just “choose ML‑DSA.”

Track E: Hybrid signatures in X.509 (composite signatures)

If you’re exploring hybrid certificate signatures as a transition mechanism, go here next:
Hybrid Signatures (Composite Signatures)

This is a PKI/verifier ecosystem topic. It’s worth reading only if you actually control (or can influence) the relying-party population.

A realistic first 30 days (if you want progress you can measure)

Days 1–7: decide scope and name owners

  • Write your scope in one sentence (examples: “internal mTLS,” “VPN + bastions,” “firmware signing,” “customer-facing TLS,” “PKI modernization”).
  • Assign owners for: PKI, networking/VPN, platform/infrastructure, and security governance.
  • Pick one pilot surface where you control both ends.

Days 8–15: inventory + pick one pilot with success criteria

  • Produce an initial crypto inventory snapshot (it can be incomplete; it must be actionable).
  • Pick a pilot and define metrics:
    • TLS/VPN/SSH: handshake success rate, negotiation distribution, error spikes
    • PKI: validation success across representative clients, chain correctness
    • signing: verification success on real verifiers, rollback path
    • keys: auditability, access control correctness, rotation rehearsal

Days 16–30: make the pilot boring

  • Upgrade endpoints first (clients/servers/verifiers), then enable new negotiation options.
  • Add regression tests before rollout (handshake tests, chain validation tests, signature verification tests).
  • Write rollback steps while you’re calm, not during an incident.
  • Document what blocked you; those blockers become your roadmap.

The short “don’t do this” list (saves time and embarrassment)

  • Don’t start with algorithm debates in isolation. Start with inventory and constraints.
  • Don’t treat PQC as one project. It is multiple migrations with different bottlenecks.
  • Don’t start with your hardest surface (often VPN across unknown paths, or public TLS with diverse clients).
  • Don’t roll out crypto changes without monitoring and rollback. Crypto failures often look like “random network flakiness” until you instrument them.

FAQ

Do we need to be “PQC-only” to start?

No. In 2026, phased adoption is normal. For protocols, hybrid approaches are explicitly documented in IETF RFCs for TLS and SSH. For PKI and signing, verifier support is usually the limiting factor.

What’s the most common reason PQC programs stall?

Lack of inventory and ownership. If crypto usage isn’t mapped to systems and teams, you can’t prioritize, test, or roll out safely.

What’s a good early win that still pays off if timelines change?

Build certificate rotation capability and produce an initial crypto inventory snapshot. Both reduce outages and improve security today, independent of PQC urgency.

When should we think about hybrid signatures (composite signatures) in PKI?

Only when you can test and upgrade the verifier ecosystem that must validate those certificates. Hybrid signatures can be useful as a transition technique, but they increase complexity and interoperability surface area.

Scroll to Top