Preparing for post-quantum cryptography: a practical migration plan

Post-quantum cryptography (PQC) is not a future product category to evaluate after a quantum computer appears. It is a change to the public-key machinery that already authenticates systems, establishes session keys, signs software, and protects long-lived records. The practical question for a technology decision-maker is therefore not “When will quantum computing break encryption?” No reliable date answers that question. The useful question is: Which information and trust paths would be exposed by a capable quantum adversary, how long will replacement take, and what evidence will show that the replacement works?

This article is scoped to information available on 20 October 2026. NIST’s first three finalized PQC standards remain the baseline: ML-KEM in FIPS 203 for key establishment, ML-DSA in FIPS 204 for digital signatures, and SLH-DSA in FIPS 205 for digital signatures. NIST says organizations should begin applying them, while additional algorithms such as the Falcon-derived signature and HQC key-encapsulation mechanism are still in the standardization process.NIST PQC project That distinction matters. A vendor’s “quantum-safe” label, a draft protocol, a research implementation, and a final NIST standard are not interchangeable evidence.

The migration should be managed as an enterprise cryptographic transition: discover what exists, rank exposure and dependency risk, test replacement paths, deploy in controlled stages, and keep an auditable record of decisions. The organization that starts with that work can change algorithms without turning every certificate renewal, software release, or network upgrade into an emergency.

The threat model: what changes, and what does not

A quantum computer is not assumed to make every cipher instantly useless. The central public-key concern is that a sufficiently capable, error-corrected quantum computer could run algorithms that undermine the mathematical assumptions behind widely deployed RSA and elliptic-curve systems. Those systems are used for encryption or key agreement, and for signatures that prove identity and software or document integrity. NIST describes the target as a cryptographically relevant quantum computer, while also stressing that the engineering path to one remains uncertain.NIST, What Is Post-Quantum Cryptography?

That uncertainty should shape planning, not postpone it. Quantum-resistant algorithms are designed to run on conventional computers and to resist both conventional and quantum attacks under their current security assumptions. They do not require an organization to own a quantum computer. They also do not make an implementation automatically secure: protocol binding, random-number generation, key protection, certificate validation, side-channel resistance, and operational controls still matter.

The threat is asymmetric across cryptographic functions. Public-key encryption and key agreement are exposed because an attacker may eventually recover a private key or derive a session secret from recorded public exchanges. Public-key signatures are exposed because a future adversary may be able to forge signatures or recover signing keys. Symmetric encryption and hash functions are not treated as equivalent to RSA or elliptic-curve cryptography in the migration plan. They may need appropriate security-strength choices and careful review, but the immediate work is usually to find public-key uses and the systems that depend on them.

Two attacker capabilities should be kept separate:

1. Harvest now, decrypt later (HNDL). An adversary records encrypted traffic or stores encrypted files today, then attempts decryption after obtaining a quantum capability or otherwise compromising the relevant public-key protection. The attack can begin before a cryptographically relevant quantum computer exists. It matters when confidentiality must survive longer than the time needed to collect, retain, and later process the data.
2. Break or forge at attack time. A quantum-capable adversary attacks a live key exchange, certificate chain, software-update signature, or transaction-signing process. This is a future active threat, not the same as HNDL. A past signature does not become a decryption key merely because its algorithm is quantum-vulnerable; its risk concerns authenticity, validation, and the possibility of future forgery or repudiation.

HNDL makes data age a security input. A short-lived public web session containing ordinary, low-value content may have a different priority from a captured diplomatic exchange, design archive, health record, source repository, or private key backup intended to remain confidential for decades. The inventory should record the required confidentiality lifetime and the capture surface, not just the label “encrypted.” A system that encrypts data at rest with a strong symmetric key may still rely on RSA or elliptic-curve cryptography to wrap that key, exchange it, authenticate a peer, or recover it from a key-management service.

Do not turn HNDL into a countdown claim. There is no verified date on which quantum decryption will arrive. A defensible risk statement is conditional: “If a capable quantum adversary becomes available during the confidentiality lifetime of this data, today’s public-key protection may no longer be sufficient.” That statement supports action without pretending to know the hardware roadmap.

What the current NIST standards actually provide

The first standards are deliberately different in role. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism (KEM). A KEM lets one party publish an encapsulation key and another establish a shared secret over a public channel; symmetric cryptography then uses that secret for the data channel. ML-KEM is not a drop-in replacement for AES and is not a digital-signature algorithm. FIPS 203 defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with increasing security strength and decreasing performance across the parameter sets.FIPS 203

FIPS 204 specifies ML-DSA, a lattice-based digital-signature algorithm. Signatures provide integrity and authentication: a verifier checks that a message was signed by the holder of the private key and was not altered. ML-DSA is therefore relevant to certificates, software and firmware updates, signed documents, device identity, tokens, and any protocol that verifies a public-key signature.FIPS 204

FIPS 205 specifies SLH-DSA, a stateless hash-based signature algorithm derived from SPHINCS+. It uses a different mathematical approach from ML-DSA and is part of NIST’s portfolio for signature use cases and algorithm diversity.FIPS 205 “Different” does not mean “use both everywhere.” It means that architecture and assurance teams can assess an alternative failure mode, implementation profile, or long-lived signing use case instead of assuming that one family must serve every purpose.

These standards are algorithm specifications, not a complete deployment profile. They do not, by themselves, define a PQC certificate ecosystem for every browser, CA, HSM, operating system, database, messaging protocol, or industrial controller. A product can implement a FIPS algorithm without being a validated cryptographic module, and a product can advertise a hybrid mode whose exact combiner, certificate behavior, fallback rules, or support matrix is vendor-specific. Ask for the standard name, parameter set, protocol specification, module boundary, validation status where required, and documented interoperability constraints.

NIST’s transition material uses terms such as acceptable, deprecated, disallowed, and legacy use to describe the status of existing algorithms in particular standards and contexts. It also notes that estimating post-quantum security strength has uncertainty because future quantum hardware cost, speed, and memory cannot be predicted precisely.NIST IR 8547 initial public draft Treat NIST’s transition plan as a standards and policy input, not as a universal instruction to rip out every classical algorithm on one date. National, sectoral, contractual, and product-specific requirements can add constraints; they should be recorded as requirements with an owner and an effective date.

Build a cryptographic inventory that can drive decisions

A list of algorithms is not enough. An inventory must connect a primitive to a system, a data flow, a key, a certificate, and an owner. NIST’s National Cybersecurity Center of Excellence describes cryptographic assets broadly: algorithms, keys, certificates, protocols, libraries, hardware security modules (HSMs), and other components that provide or depend on cryptographic protection.NCCoE Migration to PQC That definition prevents a common failure mode in which a team finds “RSA” in source code but misses the certificate authority, backup key, device firmware, or third-party endpoint that makes the change operationally difficult.

Start with an inventory record for each material cryptographic use. Useful fields include:

• system, service, product, environment, and data owner;
• algorithm, parameter set, library, provider, hardware boundary, and mode of use;
• purpose: key agreement, encryption-key wrapping, signature, certificate, authentication, integrity, or random-number generation;
• protocol and wire format, including TLS, SSH, IPsec, S/MIME, code signing, a proprietary device protocol, or an application API;
• keys and certificates, including generation, storage, rotation, expiration, revocation, recovery, escrow, and trust anchors;
• data classification, confidentiality and integrity lifetime, internet exposure, number of relying parties, and likely HNDL value;
• dependencies on browsers, operating systems, firmware, HSMs, appliances, cloud services, suppliers, partners, and managed certificate services;
• change owner, replacement candidate, test environment, rollback method, support end date, and evidence link.

Use more than one discovery method. Code and configuration scanning can find library calls and algorithm names. Certificate and HSM exports can reveal issued keys and trust relationships. Network telemetry can identify protocol handshakes and endpoints, but encrypted traffic inspection must follow the organization’s legal and privacy rules. Procurement records, software bills of materials, firmware manifests, architecture diagrams, and vendor questionnaires fill gaps that scanners cannot see. Ask suppliers whether the product supports a standardized ML-KEM, ML-DSA, or SLH-DSA mode, which parameter sets, which protocol versions, and what happens when peers do not support it. “PQC-ready” is not a sufficiently precise answer.

Record confidence and evidence. “Observed in production,” “declared by supplier,” “inferred from a library,” and “not yet verified” are different states. An inventory that preserves uncertainty is more useful than a clean spreadsheet that hides it. Give every record an owner and review date. Export a machine-readable form so that asset management, vulnerability management, PKI operations, and change management can share the same identifiers.

Open the full-size diagram

Prioritize by exposure, lifetime, and dependency

A practical priority model can be simple. Score each use on five dimensions: the value and confidentiality lifetime of the protected data; whether an attacker can capture or influence the traffic; whether a quantum-vulnerable public-key operation is on the critical path; the replacement lead time; and the consequence of failure during migration. Add a dependency multiplier for systems whose change requires a supplier, hardware refresh, protocol standard, safety assessment, or coordinated trust-store update.

Start with uses that combine high HNDL value and long confidentiality life: inter-site links, sensitive archives, key-wrapping services, long-lived device communications, private partner channels, and backups that retain old ciphertext. Then address public-key uses that can enable future impersonation or malicious updates: root and intermediate signing, firmware and software signing, identity credentials, administrative access, and high-value transaction authorization. A publicly reachable TLS endpoint may be easy to update but still deserve early testing because it is common, exposed, and dependent on many clients.

Do not rank only by algorithm. Rank the cryptographic path. A service may use an elliptic-curve certificate for authentication, an elliptic-curve key exchange for the session, AES-GCM for bulk data, an HSM for private-key operations, and a separate signature for a token. Replacing only one element may leave a high-value path exposed or create an incompatible handshake. The inventory should show the path from producer to consumer and identify which part carries confidentiality, authentication, integrity, and recovery risk.

A useful decision record answers four questions: What is the asset? What is the plausible quantum failure? What is the earliest acceptable migration state? What evidence permits the next stage? This turns “we support PQC” into a testable claim such as “these clients negotiate the named hybrid group, the certificate chain remains valid in the target trust stores, and rollback is safe.”

Use hybrid deployment as a controlled bridge

Hybrid key exchange combines a classical key exchange with a PQC KEM and feeds both results into a defined key schedule. The aim is to retain security if one component later fails, subject to the protocol’s security analysis and correct implementation. In 2026, RFC 10024 defines three PQ/T hybrid key-agreement mechanisms for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.RFC 10024 The RFC specifies, among other details, the wire encoding and the relationship between ML-KEM and ephemeral elliptic-curve Diffie–Hellman.

Hybrid is not a synonym for “two independent encryptions.” In the TLS framework described by RFC 9954, component public values and shared secrets are combined in a defined way and inserted into the existing TLS 1.3 key schedule.RFC 9954 The construction depends on fixed encodings, independent randomness, correct failure handling, and the security properties of the protocol transcript. RFC 10024 explicitly cautions that its security analysis should not be assumed to transfer unchanged to another protocol. A vendor’s generic “hybrid” switch is not evidence that an application’s custom protocol has the same properties.

Use hybrid modes when they solve a real transition problem: the peer population is mixed, the classical path is widely deployed, the PQC implementation is new, or the organization needs a reversible rollout while it measures performance and interoperability. Define the allowed groups centrally, prefer a documented standard group, and decide what a client or server does when negotiation fails. A silent downgrade to classical-only may preserve availability while defeating the migration objective. A hard failure may protect policy while denying service. The choice belongs in the threat model and exception process, not in an undocumented library default.

Measure the costs in the organization’s own traffic. PQC public keys, ciphertexts, and signatures can be larger than their classical counterparts. RFC 10024, for example, specifies a 1,216-byte client share for X25519MLKEM768 and notes that a ClientHello may exceed a single packet for some groups. That can expose assumptions in proxies, load balancers, firewalls, MTU handling, telemetry, rate limits, and embedded parsers. Do not copy a benchmark from a blog and call it a capacity plan. Capture handshake latency, CPU, memory, bandwidth, connection failure rate, retries, and tail behavior on representative hardware.

Hybrid key exchange does not solve signature migration. A TLS session can use a hybrid KEM while the server certificate, certificate authority chain, device credential, or software update still uses a quantum-vulnerable signature. Plan key establishment and authentication as related but separate workstreams, then test the combined path.

PKI and protocol dependencies are the hard middle

Public-key infrastructure (PKI) is the system of certificate authorities, trust anchors, certificates, validation rules, revocation mechanisms, and relying parties that binds keys to identities. Changing a leaf certificate can affect the CA, issuance profile, chain length, signature algorithm, key-usage bits, validation library, trust store, certificate transparency service, OCSP responder, CRL distribution, device clock, and every client that parses the certificate. The dependency graph is larger than the web server configuration.

The WebPKI has an additional coordination problem. The UK National Cyber Security Centre identifies the ecosystem of roots, CAs, Certificate Transparency log providers, and revocation providers as a reason that post-quantum certificate migration cannot be sequenced like a local software update.NCSC, Timelines for migration to post-quantum cryptography As of this article’s scope date, do not claim that one universal PQ certificate profile is already accepted by every browser and relying party. Track the standards and browser or platform deployment guidance that apply to the audience you actually serve.

The same discipline applies outside web traffic. Inventory SSH host and user keys, VPN and IPsec profiles, S/MIME and document-signing certificates, directory and identity protocols, service-mesh identity, API token signing, database replication, backup key wrapping, code-signing chains, secure boot, and device provisioning. Industrial-control and operational-technology systems deserve special treatment: firmware may be fielded for years, maintenance windows may be rare, and a parser or key-store change can become a safety and availability issue. NCSC notes that some legacy industrial-control protocols require architectural changes, not just a new algorithm identifier.NCSC guidance

For each protocol, ask five questions. Where is confidentiality established? Where is peer identity authenticated? Which signature is verified, by whom, and for how long? Which fields have fixed-size or maximum-size assumptions? What happens if a peer, trust store, HSM, or intermediary supports only the classical path? The answers should lead to a protocol-specific migration profile. They should not be inferred from a product brochure or from the fact that a general-purpose cryptography library exposes an API.

Test the migration, not just the algorithm

Begin in a lab with known-answer tests and independent implementations where available. Verify key generation, encapsulation and decapsulation, signing and verification, error paths, malformed inputs, randomness failure behavior, serialization, and zeroization. Keep test vectors and implementation versions as evidence. For high-assurance or regulated environments, include the applicable cryptographic-module validation and supply-chain review; an algorithm name alone does not establish module assurance.

Then test interoperability. Build a matrix of client and server versions, parameter sets, certificate chains, trust stores, HSMs, proxies, load balancers, service meshes, operating systems, and partner endpoints. Include a classical-only peer, a PQC-only test peer where supported, and the intended hybrid path. Test negotiation failure, unsupported groups, certificate rejection, key rotation, revocation, clock skew, reconnect storms, and rollback. Add negative tests that verify the system does not accept a malformed or unauthenticated hybrid message merely because it can parse part of it.

Performance testing should use production-shaped workloads. Measure median and tail handshake latency, CPU saturation, memory pressure, bandwidth, packet fragmentation, connection establishment under loss, certificate issuance and validation time, signing throughput, HSM queue depth, and device battery or thermal behavior where relevant. Test at the smallest appliance and oldest supported client, not only on an oversized server. Establish an organization-specific acceptance threshold and document why it is appropriate; there is no universal “PQC overhead” number that fits every protocol or workload.

Security testing must include downgrade and configuration drift. Confirm that a policy requiring hybrid exchange cannot be bypassed by a client preference, an alternate port, a legacy virtual host, a backup endpoint, or a cloud failover path. Alert on newly observed quantum-vulnerable public-key operations. Exercise key compromise and revocation drills. Review side-channel protections and remote timing behavior for implementations that perform KEM or signature operations with attacker-controlled inputs. Test update and rollback packages as signed artifacts, including what happens if a device receives a new signature type before its boot chain understands it.

Use canaries and staged exposure. A sensible sequence is an isolated lab, internal services, a small production cohort, selected partners, then broader rollout. Define stop conditions before deployment: unacceptable handshake failures, queue growth, certificate validation errors, or evidence of a downgrade. Preserve a safe rollback path, but do not let rollback become a permanent exception. Every rollback should create a record, a new owner, and a date for remediation.

Govern the transition as a continuing program

Assign an executive sponsor, a technical program owner, a PKI owner, an enterprise-architecture representative, a procurement lead, and risk owners for high-value data. A cryptography steering group need not approve every certificate, but it should own the approved algorithms and profiles, exception criteria, evidence requirements, standards watch, and escalation route. Security engineering can run tests; product, legal, privacy, safety, and operations owners must decide whether the risk and disruption are acceptable for their systems.

Make suppliers part of the plan. Ask for support dates and end-of-life dates, named standards and parameter sets, protocol profiles, certificate behavior, HSM and module implications, performance data from comparable hardware, update mechanisms, and documented downgrade behavior. Put migration requirements in new contracts and renewal reviews. Distinguish a supplier roadmap from an available, supported, tested capability. Record the exact product version and configuration that was assessed.

Maintain two linked risk registers. The first tracks quantum exposure: long-lived confidentiality, capture opportunities, vulnerable key establishment, signing and trust-chain risk, and migration lead time. The second tracks change risk: interoperability, outage, performance, safety, recovery, and supplier dependency. This prevents the organization from “solving” quantum risk by accepting an untested configuration that creates a more immediate operational failure.

Review the program at a fixed cadence. Recheck NIST publications and errata, IETF standards, platform and browser support, module-validation status, supplier commitments, and the inventory’s completeness. Date every conclusion. A 2026 protocol capability may be absent, renamed, or revised later; the record should say what was true, where it was verified, and when it must be revisited. Avoid unsupported countdown claims in board reporting. Report measurable states instead: percentage of high-priority assets inventoried, number with an approved target profile, number tested, number migrated, number blocked by a supplier, and age of unresolved exceptions.

A staged implementation and decision framework

Stage 1: establish visibility. In the first planning cycle, appoint owners, define scope, and create the inventory schema. Discover public-key operations across applications, endpoints, PKI, code signing, backups, identity, network links, devices, and suppliers. Mark data with confidentiality and integrity lifetimes. Identify systems that cannot be patched, have long hardware lives, or require external coordination. Freeze no algorithm prematurely; first make the dependencies visible.

Stage 2: choose target profiles. For each priority path, select a target profile based on the current NIST standards and the protocol ecosystem. For key establishment, decide whether a documented hybrid TLS profile such as one defined by RFC 10024 is appropriate, whether the endpoint supports the required module assurance, and what the policy is for classical-only peers. For signatures, choose ML-DSA or SLH-DSA by use case, considering certificate and artifact size, verification environment, signing-key protection, update cadence, and algorithm diversity. If the target is not yet standardized or interoperable, record it as an experiment rather than a production control.

Stage 3: make systems crypto-agile enough to change. Replace hard-coded algorithm identifiers and key-size assumptions with versioned configuration and policy. Separate certificate issuance from application deployment where possible. Ensure keys can rotate, trust stores can update, and protocol negotiation can be observed. Put cryptographic provider selection behind tested interfaces, but do not confuse an abstraction layer with security. The goal is a controlled change boundary, not a promise that every future algorithm is a plug-in.

Stage 4: prove the path. Implement the smallest useful pilot. Exercise issuance, negotiation, validation, logging, monitoring, HSM operations, failure handling, performance, and rollback. Include partner and legacy cases. Have an independent reviewer examine the protocol profile and test evidence. Approve a production cohort only when the owner can explain both the security gain and the operational failure modes.

Stage 5: migrate by risk and dependency. Move high-HNDL and high-impact paths first when their target profile is production-ready. Migrate signing roots and update chains with controlled overlap and key ceremonies; migrate session establishment using staged negotiation; update device and firmware fleets alongside recovery procedures. Keep a dated exception for each blocked system, with compensating controls, vendor action, next review, and an explicit statement of what remains vulnerable. “Waiting for the ecosystem” is not an exception unless someone owns the wait.

Stage 6: verify and retire. After migration, sample traffic and artifacts to confirm the old path is no longer being used unintentionally. Revoke or retire obsolete certificates and keys according to retention and recovery requirements. Remove unsupported protocol groups only after downstream impact is understood. Preserve evidence of tests, approvals, rollbacks, and residual risk. Then repeat discovery: cryptography changes when teams deploy new services, acquire vendors, replace firmware, and add a second cloud region.

A useful go/no-go decision can be written on one page: target asset and data lifetime; threat and dependency statement; chosen standard and parameter set; protocol and certificate profile; test evidence; performance and capacity result; rollback and recovery; residual classical exposure; owner and review date. If those fields cannot be completed, the system is not ready for a broad rollout, regardless of how attractive the vendor demo looks.

Conclusion

PQC migration is a multi-year engineering and governance program, not a one-time library upgrade and not a race to a dramatic “quantum day.” The immediate work is concrete: inventory public-key dependencies, rank data by lifetime and capture risk, use finalized NIST standards as the baseline, deploy documented hybrid key exchange where it fits, treat PKI and signatures as separate dependencies, and test the full operational path. Organizations should make progress measurable and reversible while staying honest about what is standardized, what is vendor-specific, and what remains uncertain. That is how a future quantum threat becomes a managed change program rather than a surprise outage or a last-minute security exception.

References and further reading

• NIST Post-Quantum Cryptography project
• NIST: What Is Post-Quantum Cryptography?
• NIST: Releases first three finalized post-quantum encryption standards
• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• FIPS 204: Module-Lattice-Based Digital Signature Standard
• FIPS 205: Stateless Hash-Based Digital Signature Standard
• NIST NCCoE: Migration to Post-Quantum Cryptography
• NIST IR 8547 initial public draft: Transition to Post-Quantum Cryptography Standards
• CISA, NSA, and NIST: Quantum-Readiness—Migration to Post-Quantum Cryptography
• RFC 9954: Hybrid Key Exchange in TLS 1.3
• RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3
• UK NCSC: Timelines for migration to post-quantum cryptography