The post-quantum cryptography migration is the largest cryptographic transition in modern enterprise history, and it is going to land on most CIOs as a series of small, badly-sequenced shocks unless they get ahead of it. This is the playbook I run with the executives I advise.

Frame: this is a multi-year program, not a project

The first executive miscalibration is treating post-quantum cryptography as a discrete project — a sprint to swap one set of algorithms for another. It is not. It is a multi-year program that touches identity, network, application, data, vendor, and OT layers, and it will outlive at least two CIOs in most organizations. Frame it accordingly with the audit committee from the start.

Step 1: Cryptographic inventory

The single most under-funded prerequisite. You cannot migrate what you cannot see. Most enterprises have a vague mental model of where they use TLS, SSH, code signing, and disk encryption — and almost no inventory of where they use cryptographic primitives that NIST has now deprecated for the post-quantum era.

The inventory has to cover at minimum: TLS endpoints (and their certificate chains), SSH hosts and clients, VPN concentrators, code-signing pipelines, document signing, email signing, disk and file encryption, database encryption, key management systems, hardware security modules, identity providers and the cryptographic primitives they rely on, and OT firmware-signing paths (typically the most overlooked).

This inventory is also the document the federal mandate posture ultimately will require, so it has dual value. See the federal-specific take in quantum readiness.

Step 2: Vendor PQC roadmap evaluation

Most enterprise cryptography is not implemented by the enterprise. It is implemented by vendors — identity providers, network equipment manufacturers, cloud providers, KMS/HSM vendors, application platforms, and OT/ICS vendors. Their roadmaps are your roadmap.

The evaluation pattern I use scores each major vendor on five dimensions:

  1. Published PQC roadmap — does one exist, with dates?
  2. NIST PQC algorithm coverage — ML-KEM, ML-DSA, SLH-DSA, FALCON.
  3. Hybrid posture — do they support classical-plus-PQC during the transition?
  4. Migration support — tooling, services, contractual clarity.
  5. Crypto agility commitment — can they swap again when NIST publishes the next round?

Vendors that score zero or one on this matrix are not partners for the migration; they are migration risks. The procurement leverage operators have right now, while the migration is still elective for most categories, is significant and time-bound.

Step 3: Crypto agility as architectural requirement

Crypto agility — the ability to swap cryptographic algorithms across the enterprise without rebuilding the systems that depend on them — is now an architectural requirement, not a future concern. NIST will publish more PQC algorithms. Some of the current selections may be deprecated. The migration is not a single event.

The architectural pattern that produces real crypto agility is straightforward to describe and operationally hard to execute: abstract the cryptographic primitives, manage them through centralized configuration, refuse to let application teams hard-code algorithm choices, and build the inventory continuously rather than as a one-time exercise.

Step 4: Phasing

The phasing pattern that survives a real budget cycle is sequenced by data-sensitivity lifetime, not by technical convenience. Migrate the things that protect data with the longest sensitivity tail first.

The order I typically run with CIO clients:

  1. Federal-stewardship data and long-life regulated data first. Defense, healthcare, life sciences IP, financial long-life records.
  2. Identity-system signing and federation. If your IdP signing material gets harvested today, the consequences are persistent.
  3. Code signing. Both for internal application provenance and for OT firmware-signing paths.
  4. TLS and VPN endpoints handling sensitive transactional data.
  5. General-purpose data-at-rest encryption.

This sequencing is also defensible to a board: it correlates investment with the threat that is most operational today, the harvest-now-decrypt-later threat against long-life data.

Step 5: Reporting

The board reporting pattern that sticks reduces the migration to four metrics:

  • Inventory coverage — what percentage of the cryptographic surface is mapped.
  • Vendor PQC posture — score against the five-dimension matrix above, weighted by spend.
  • Migrated estate — what percentage of the cryptographic surface is on a NIST PQC algorithm.
  • Crypto-agility readiness — qualitative score against the architectural pattern.

Quarterly reporting on these four numbers is sufficient for board governance. The audit committee can see the program move without becoming PQC experts themselves.

Where most CIOs are right now

Across the executives I work with: most have a partial inventory, no vendor scorecard, an early conceptual position on crypto agility, and no defensible phasing plan. That is not a failure — it is the normal state at this point in the migration. The CIOs who will be in the best position 24 months from now are the ones who are starting the inventory and the vendor scorecard now.

If you want a tailored briefing for your audit committee or executive team, see post-quantum migration speaker or quantum cybersecurity board speaker.