Post-Quantum Cryptography Migration: An Enterprise Playbook

A post-quantum cryptography (PQC) programme should be treated as a risk-managed transformation, not a one-time algorithm swap. The practical sequence is: establish governance, build a living cryptographic inventory, prioritise long-lived and high-impact dependencies, select standards-based algorithms, validate them in controlled pilots, document decisions and residual risk, coordinate suppliers, and then execute a phased rollout with measured fallback and retirement controls.^[1]^[2]^[3]

This playbook distinguishes documented guidance from proposed enterprise operating controls. The supplied research supports ML-KEM for key establishment, ML-DSA for general-purpose signatures, selective use of SLH-DSA, and hybrid traditional plus PQC transition patterns. It does not support treating HQC as a current production replacement for ML-KEM or treating illustrative performance gates as universal requirements.

1. Mobilise the Programme and Set Governance

Create a named quantum-readiness team before technical discovery. Include IT and OT procurement specialists, cybersecurity risk managers, privacy risk managers, security architecture, engineering, operations, legal, compliance, business owners, and supplier-management representatives. Assign an executive sponsor with authority over funding, ownership disputes, and risk acceptance; the cited guidance supports executive sponsorship and formal risk governance but does not prescribe a particular job title.^[4]^[5]

Approve a programme charter covering scope, decision rights, reporting cadence, data-quality rules, exceptions, escalation, and funding. These operating details are proposed implementation controls derived from the guidance’s emphasis on formal governance and measurable progress.^[6]
Make the inventory a controlled, continuously updated enterprise record rather than a one-time spreadsheet. NIST describes a centralised inventory of cryptographic data and metadata, with analytics and policy-driven findings supporting migration decisions.^[7]
Give each record an accountable business or technical owner, operational contact, and risk owner. This is a recommended control based on the guidance’s focus on clear operational and risk roles, not an explicitly prescribed NIST field.^[8]^[9]
Approve a phased roadmap with milestones, target dates, investment, capability requirements, dependencies, and escalation paths. The NCSC migration-timelines guidance recommends phased planning and prioritisation of systems with high impact or long migration lead times.^[10]

2. Build the Cryptographic Asset Inventory

Start with quantum-vulnerable public-key signatures and key-establishment mechanisms. The NIST discovery project places symmetric ciphers and hash functions outside its immediate scope because they are less drastically affected by a cryptographically relevant quantum computer, although the wider inventory should still record cryptographic context where it affects dependencies.^[11]

Use both top-down architectural analysis and bottom-up technical discovery. Begin with core services and dependencies, then inspect managed IT and OT cryptography, protocols, hardware, certificates, libraries, binaries, running processes, and certificate stores. Include cloud and managed services, products, suppliers, software-development pipelines, HSMs, firmware, and network infrastructure.^[12]^[13]^[14]

Asset and deployment: system, service, application, product, hardware, firmware, HSM or cryptographic module, cloud or managed-service environment, version, and patch level.^[15]^[16]
Cryptographic implementation: algorithm, protocol, library, embedded code, certificate, key, keystore, PKI component, enabled service, and application or module managing the key.^[17]
Security function: signature, identity authentication, key transport or establishment, key management, software update, firmware validation, or another public-key use.^[18]^[19]
Protection target: data or business function protected, data state, sensitivity, adversary value, required confidentiality lifetime, and collect-now-decrypt-later exposure.^[20]^[21]^[22]
Dependencies and ownership: upstream and downstream services, clients, protocols, suppliers, cloud providers, processors, accountable owner, operational contact, and risk owner.^[23]^[24]
Risk and status: quantum-vulnerable object, criticality, exposure, compliance driver, certificate lifecycle state, migration state, exception, remediation date, and residual risk.^[25]

3. Prioritise and Select the Target Cryptography

Rank assets by business impact, confidentiality lifetime, collect-now-decrypt-later exposure, migration lead time, hardware or firmware constraints, supplier dependency, protocol complexity, and replacement difficulty. Prioritisation should expose the systems that are both consequential and slow to change, rather than simply counting vulnerable cryptographic objects.^[26]^[27]^[28]

Use the following decision baseline, subject to protocol profiles, implementation support, cryptographic-module validation, interoperability, and applicable regulatory requirements.

Option	Enterprise role	Decision and caveat
ML-KEM, FIPS 203	Primary PQC key-establishment option	Use for new or upgradeable systems that establish encryption keys. Benchmark message size, bandwidth, latency, acceleration, and interoperability.
ML-DSA, FIPS 204	General-purpose PQC signatures	Evaluate for software, certificates, documents, device identities, and similar signing uses. Larger keys and signatures can affect storage, network transactions, certificate handling, throughput, and verification latency.
SLH-DSA, FIPS 205	Alternative hash-based signature family	Use selectively where algorithm diversity, conservative hash-based assumptions, or an assurance decision justifies it. Validate size, performance, and ecosystem support rather than treating it as an automatic ML-DSA replacement.
Hybrid traditional plus PQC	Transition interoperability pattern	Use where endpoints, vendors, protocols, or certificate ecosystems are not ready for pure PQC. Confirm the exact composition, authentication, negotiation, and recording behaviour; RFC 9794 terminology does not mandate one universal enterprise profile.^[29]
HQC	Future key-establishment diversity option	Track for future standards, validated implementations, protocol integration, and vendor roadmaps. It is not the current replacement for the ML-KEM deployment baseline.

4. Run Bounded Pilots Before Production

NIST NCCoE migration work treats discovery, interoperability testing, and benchmarking as laboratory activities intended to expose integration problems before production; the relevant materials are preliminary guidance rather than a complete production cutover method.^[30]^[31]^[32]

Create a representative, non-production lab containing relevant browsers, clients, servers, proxies, load balancers, HSMs, service-mesh components, middleboxes, DevOps tooling, virtual and hardware endpoints, and captured traffic where appropriate.^[33]^[34]
Select two or three bounded services, such as an internal HTTPS API, a browser-facing service, and an administrative SSH path. Record the classical baseline, software versions, configuration hashes, payload sizes, connection rate, and failure rate. These bounded-service choices and recording requirements are proposed operational practice.
Test positive negotiation for supported hybrid and pure-PQC groups, legacy-peer behaviour, unsupported groups, malformed shares, HelloRetryRequest, timeouts, rejected shares, classical-only negotiation, and downgrade-related cases.^[35]^[36]
Measure ClientHello and total handshake size through firewalls, proxies, and middleboxes. IETF application guidance warns that duplicating PQC KEM public-key shares can create packet-size problems.^[37]
Instrument algorithm and peer negotiated, retries, failures, timeouts, rejection reasons, certificate errors, resource saturation, and application errors. Ensure that fallback activation is visible rather than silently misclassified; the monitoring fields and alert thresholds are proposed enterprise controls grounded in the interoperability guidance.^[38]
Rehearse rollback to the last known-good configuration and test fallback before limited production exposure. A rollback runbook should identify the change owner, configuration artifact, approval path, data-preservation steps, health checks, and the condition that ends the rollback. These runbook details are proposed operational controls.

5. Benchmark and Set Service-Specific Gates

NIST identifies laboratory performance benchmarking as a way to optimise implementations toward production readiness and to inform use-case algorithm selection, but the supplied research does not provide validated universal numerical results for PQC latency, CPU, bandwidth, memory, or handshake impact.^[39] Run the same workloads with the classical baseline, each candidate hybrid configuration, and any pure-PQC configuration under consideration, across normal and peak load, high concurrency, small and large payloads, cold and resumed sessions, and representative hardware.^[40]

Measure	Record	Illustrative proposed gate
Handshake latency	Median, p95, and p99 by protocol and algorithm	p95 increase no greater than 20% versus classical baseline. This is an illustrative enterprise threshold, not documented universal guidance.^[41]
Handshake success	Successful, retried, timed-out, and rejected handshakes by peer, algorithm, and reason	At least 99.9% for supported pilot pairs, excluding deliberately negative tests. This is a proposed gate, not a standards requirement.^[42]
Message size	Handshake bytes, fragmentation, retransmissions, and middlebox failures	No unexplained fragmentation or middlebox failure; set a service-specific ceiling from the baseline path.^[43]
Resource cost	CPU, memory, connection rate, and network egress at peak	Retain the service’s existing operational reserve. This is a proposed capacity-control criterion.
Application effect	Request latency, throughput, error rate, and tail latency under PQC	Approve only if service-level objectives remain satisfied. The precise threshold must be set by the service owner.

6. Document Compliance, Risk, and Approval Evidence

Maintain an evidence pack that allows an independent reviewer to reconstruct scope, prioritisation, decision rationale, approvals, testing, and residual-risk treatment. NCSC guidance supports discovery, prioritisation, roadmap development, executive sponsorship, supplier engagement, and sharing progress, but does not prescribe a complete evidence schema.^[44]

Programme charter and accountability record, including sponsor, owners, security, procurement, legal, compliance, and supplier-management contacts.^[45]
Prioritisation record for each service, including impact, data lifetime, lead time, dependencies, exposure, treatment decision, residual risk, and review date.^[46]
Versioned roadmap and investment case with milestones, targets, capability requirements, dependencies, acceptance criteria, and escalation paths.^[47]
Decision and exception register covering deferrals, unsupported platforms, compensating controls, supplier exceptions, and temporary fallbacks. Include owner, evidence reviewed, expiry trigger, renewal conditions, and retirement criteria. This is a proposed enterprise control, not a detailed mandatory requirement in the cited guidance.
Pilot exit pack containing test plan, interoperability results, benchmark data, defects, rollback rehearsal, fallback disposition, and production approver.
Production approval pack containing deployment record, monitoring plan, fallback activation criteria, change approval, and updated inventory. These evidence-pack structures are proposed controls tailored from the cited guidance.^[48]

7. Coordinate Vendors and Procurement

Treat supplier readiness as part of enterprise readiness. CISA identifies cloud services, web software, networking hardware and software, and endpoint security as product categories relevant to PQC-capable investment; NCSC recommends incorporating PQC into supplier security assessments and sourcing.^[49]^[50]

The following are proposed enterprise procurement and contract controls, not authoritative mandatory clauses. Legal, procurement, risk, and regulatory teams should tailor them to the service and jurisdiction.^[51]^[52]

Require suppliers to state whether each product supports PQC now, is upgradeable, or has no committed path, and to identify supported ML-KEM, ML-DSA, SLH-DSA, and hybrid profiles where applicable.^[53]
Request roadmaps, firmware, operating-system, library, HSM, managed-service, and end-of-support dependencies, with notification of material changes.
Require evidence of crypto-agility, defined as the ability to replace or adapt cryptographic algorithms across relevant protocols, applications, hardware, firmware, and infrastructure while preserving secure operation. Exact acceptance tests remain an enterprise decision.^[54]
Coordinate end-to-end testing across supplier products, supported peers, certificate and key migration, configuration export, proxies, load balancers, and managed-service boundaries.
Record supplier test results, unresolved interoperability defects, support dates, upgrade dependencies, lifecycle commitments, and named escalation contacts in the supplier-risk file.^[55]
For renewals and major upgrades, make PQC capability or upgradeability an evaluation criterion, and require a documented transition and support plan. This reflects NCSC and CISA recommendations, while the precise scoring and contractual remedy are proposed controls.^[56]^[57]

8. Control Fallback, Rollout, and Retirement

Choose fallback per dependency rather than applying one enterprise-wide switch. The permitted treatment may be a hybrid configuration, a temporarily retained traditional mechanism, an alternate standardised PQC algorithm, or service isolation and replacement. A classical-only path must never be represented as quantum-safe.

For every fallback, record the affected dependency, reason, owner, risk acceptance, allowed scope, monitoring signal, activation condition, expiry date or trigger, and retirement criteria. These controls implement the research recommendation that fallback be time-bounded and governed by explicit ownership and expiry.
Roll out in waves from pilot services to higher-impact services, using canary exposure and an approved rollback point. The phased roadmap and prioritisation approach are supported by NCSC migration-timelines guidance.^[58]
Monitor negotiated algorithm, fallback frequency, handshake failures, latency, message-size failures, resource headroom, certificate errors, and application-level errors. Alert on unexpected classical-only negotiation, repeated fallback, expiry approach, or regression against the approved baseline. The monitoring design and thresholds are proposed operational controls informed by the pilot guidance.^[59]
Retire a fallback when the dependency supports the approved PQC or hybrid profile, interoperability and performance gates pass, monitoring is stable for the service’s defined observation period, and the service owner and risk authority approve removal. The observation period and approval thresholds are proposed enterprise criteria.
If a supplier cannot meet the migration path, isolate or replace the dependency, retain only the documented time-bounded exception, and escalate before its expiry rather than renewing it silently.^[60]

Conclusion: The Migration Control Loop

The durable operating model is a loop: discover, prioritise, select, test, document, coordinate, deploy, monitor, and retire exceptions. Begin with ML-KEM and ML-DSA as the current planning baseline, use SLH-DSA only for a defined diversity or assurance need, use hybrid profiles to manage interoperability, and track HQC as future diversification rather than a present default.

Success is not merely enabling a PQC option. It is proving that each critical dependency has an accountable owner, an evidence-backed migration decision, a tested protocol path, measured performance against a classical baseline, a visible rollback mechanism, and a time-bounded fallback that cannot become permanent by inaction.^[61]^[62]^[63]