Post-Quantum Cryptography Migration: A Crypto-Agility ADR for 2026

Ask a platform team where their systems use RSA and you will get a confident answer about TLS termination, a vaguer answer about service-to-service mTLS, and silence about the JWT signing key in a vendor SDK, the SSH host keys on the build fleet, and the RSA-2048 root burned into a product shipped in 2021. That silence is the real problem. A post-quantum cryptography migration does not fail because ML-KEM is hard to implement — the libraries already ship it and browsers already negotiate it. It fails because nobody can enumerate the estate, so every remediation estimate is a guess and every deadline slips. Crypto-agility, not cryptography, is the critical path.

This post is written as an architecture decision record: the forces acting on the decision, the options we weighed, the option we chose, and the consequences we accepted.

What this covers: the standards and deadlines that are actually binding, why cryptographic inventory dominates the schedule, the handshake-size economics of ML-KEM versus the certificate-chain economics of ML-DSA, PKI and firmware-signing migration order, and a phased rollout with real rollback points.

Context and Background

The standards question is settled. NIST published three post-quantum standards on 13 August 2024: FIPS 203 specifying ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism derived from CRYSTALS-Kyber, with parameter sets ML-KEM-512, ML-KEM-768 and ML-KEM-1024; FIPS 204 specifying ML-DSA, the Module-Lattice-Based Digital Signature Algorithm derived from CRYSTALS-Dilithium; and FIPS 205 specifying SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm derived from SPHINCS+. In March 2025 NIST selected HQC as a fifth algorithm, a code-based KEM intended as a mathematically independent backup to ML-KEM should lattice assumptions weaken, with a finalized standard expected in 2027.

So the algorithms exist, they are implemented, and in the case of hybrid key exchange they are already the majority case on the public web. What does not exist, in most organisations, is an answer to “where do we use RSA?”

That gap matters because the deadlines are no longer aspirational. NIST IR 8547, Transition to Post-Quantum Cryptography Standards, released as an initial public draft in November 2024, sets out the shape of the retirement: algorithms at roughly the 112-bit classical security level — RSA-2048, ECDSA over P-256, finite-field and elliptic-curve Diffie-Hellman — are slated for deprecation around 2030 and disallowance around 2035 in federal systems. The NSA’s Commercial National Security Algorithm Suite 2.0 is more aggressive for national security systems and, importantly, is staged by system class rather than as a single date: software and firmware signing is expected to support and prefer CNSA 2.0 algorithms from 2025 and use them exclusively by 2030, networking equipment such as VPNs and routers by 2026 and 2030, web browsers, servers and cloud services by 2025 and 2033, operating systems by 2027 and 2033.

The pattern in those dates is worth noticing before we go further. The earliest exclusive-use deadline is not on TLS. It is on signing — because a signature you produce today has to be verified by a device you may never touch again. The same asymmetry runs through this entire decision. It is the reason the boring parts of the migration, code signing and PKI, are on the critical path while the glamorous part, the TLS handshake, is nearly a solved problem. Our earlier analysis of what quantum computing actually does to elliptic curve cryptography covers the cryptanalytic side; this post assumes that argument and deals with the estate.

Decision Record: Sequencing Crypto-Agility Before Algorithm Rollout

Decision. We build a cryptographic inventory and a thin crypto-abstraction layer first, then roll out hybrid key exchange broadly, then migrate signing and PKI on a per-system-class schedule driven by verifier lifetime rather than by data sensitivity. We do not attempt a big-bang algorithm swap, and we do not wait for the abstraction layer to be complete before enabling hybrid TLS, because those two workstreams have entirely different risk profiles.

The reasoning has three parts: the threat model forces action on confidentiality now but permits patience on authentication; the inventory is the long pole no matter which option you pick; and the cost of PQC is concentrated in signatures, not in key exchange, which inverts the intuitive migration order.

Figure 1: The crypto-agility control loop. Discovery feeds a CycloneDX cryptographic bill of materials; risk ranking by data lifetime drives a policy service that names suites rather than hard-coding them; protocol endpoints consume policy through an abstraction layer and emit per-connection telemetry that flows back into the inventory.

The loop matters more than any individual box. Most inventory projects produce a spreadsheet that is stale the week it is delivered. The architecture above closes the loop by making runtime telemetry — the actual negotiated suite on the actual connection — a feed back into the inventory, so drift is detected rather than rediscovered during the next audit.

Context and forces

Harvest-now-decrypt-later is asymmetric across confidentiality and authentication. An adversary can record encrypted traffic today and decrypt it whenever a cryptanalytically relevant quantum computer exists. That threat applies to anything with a long confidentiality horizon: health records, source code, key material in transit, industrial process data with trade-secret value, anything under a multi-decade regulatory retention rule. It does not apply to signatures. You cannot retroactively forge a signature that was verified in 2026 by breaking ECDSA in 2036 — the verification already happened. This single observation is the most useful scheduling tool in the whole migration, and it is routinely ignored by programmes that treat “replace all quantum-vulnerable crypto” as one undifferentiated backlog.

The exception is signatures whose verifier outlives the algorithm. A root of trust fused into silicon in 2026 and verified by a device still in the field in 2042 is, functionally, a long-horizon commitment. So is a long-lived CA root. So is any firmware image that a device will validate for the rest of its service life.

Mandated timelines are staged, not uniform. Because CNSA 2.0 differentiates by system class and IR 8547 differentiates by algorithm strength, an organisation with mixed federal, commercial and embedded exposure has several different clocks running. Treating them as one date produces either wasted urgency on low-risk systems or missed deadlines on signing.

Long-lived device fleets outlive their cryptography. This is the constraint that makes industrial and OT estates qualitatively harder than SaaS estates. A programmable logic controller, a smart meter, a medical infusion pump or a vehicle ECU has a service life of ten to twenty-five years, a ROM-anchored boot chain that cannot be changed after fabrication, and often no field-update path for the trust anchor itself. If the verification root only understands RSA-2048, the device is cryptographically frozen. The decision you make about that device’s root of trust in 2026 is effectively permanent.

Nobody knows what they run. Cryptography enters an estate through at least five doors: application code you wrote, libraries you pulled in, platform defaults you never configured, appliances and SaaS you bought, and hardware roots you cannot change. Only the first is visible to a code search. A grep for RSA finds the easy cases and misses the JWT library that defaults to RS256, the container registry signing its manifests, the database driver negotiating TLS with a pinned cipher list, and the vendor appliance whose firmware you cannot inspect.

Options considered

Option A — Do nothing yet; wait for library defaults to carry us. Genuinely tempting, and partially correct: OpenSSH made mlkem768x25519-sha256 its default key agreement in OpenSSH 10.0 in April 2025, and OpenSSL, Go and recent Apple platforms enable X25519MLKEM768 by default. A meaningful fraction of the migration will happen through upgrades you were going to do anyway. But this option fails on the two hard parts. It does nothing about long-lived signing commitments, where the deadline is earliest, and it leaves you with no inventory — so when a regulator, customer or the 2030 date arrives, you have no ability to attest to anything. Rejected as a whole-estate strategy, accepted as the correct approach for the specific slice of the estate that is modern, frequently updated, and behind a TLS terminator you control.

Option B — Hybrid key exchange at the edge only. Turn on X25519MLKEM768 at the CDN or load balancer, declare the harvest-now-decrypt-later risk addressed, and stop. This is cheap, low-risk and genuinely valuable — it is also where most of the industry currently is. Cloudflare’s measurements illustrate both the progress and the trap: post-quantum-capable key exchange rose from roughly 29% of requests in Q2 2025 to roughly 54% by the close of Q2 2026 on the client-to-edge leg, while the origin-facing leg — the connection from the edge back to the customer’s own servers — remains dramatically lower. The traffic is protected exactly as far as the terminator and no further. Rejected as an endpoint, adopted as phase one.

Option C — Full ML-KEM plus ML-DSA everywhere, now. Migrate key exchange and signatures across TLS, SSH, IPsec, PKI and code signing in one programme. This front-loads the hardest cost — certificate-chain bloat — at the moment when client support is least mature and rollback is least understood, and it does so for the threat that has the least time pressure. It also demands the inventory you do not have, so in practice it degrades into a partial migration with unknown coverage. Rejected.

Option D — Abstraction layer first, then rollout. Build the crypto-abstraction layer and complete the inventory before enabling anything. Architecturally the cleanest, and it is the option most likely to be proposed in a design review. It is also the one that leaves harvest-now-decrypt-later exposure open for the eighteen months it takes to instrument a large estate, in exchange for elegance. Rejected as sequenced, accepted as a parallel workstream.

Chosen: a hybrid of B and D run concurrently. Enable hybrid key exchange immediately wherever it is free — it is a configuration change on modern stacks, it is already the majority case on the public internet, and it directly reduces the only risk that is accumulating in real time. In parallel, build the inventory and abstraction layer, because they gate everything else. Then migrate signing and PKI on a schedule ordered by verifier lifetime, longest-lived first.

What the Migration Actually Costs

The direct answer: in TLS 1.3, adding ML-KEM to key exchange costs roughly one extra kilobyte in each direction and is largely absorbed by existing congestion windows, while replacing certificate-chain signatures with ML-DSA can push handshake authentication data past ten kilobytes and reliably costs extra round trips. Key exchange is cheap and mostly deployed. Signatures are expensive and mostly not. Budget accordingly.

ML-KEM in the handshake: one extra kilobyte, mostly absorbed

The concrete numbers for ML-KEM-768, the parameter set used in the widely deployed X25519MLKEM768 hybrid, are an encapsulation key of 1,184 bytes and a ciphertext of 1,088 bytes. Combined with X25519’s 32 bytes, the client’s key share is 1,216 bytes and the server’s response is 1,120 bytes. Compare that to a bare X25519 share at 32 bytes and the multiplier looks alarming — roughly 38× — but the absolute number is what matters.

A ClientHello that was comfortably one TCP segment becomes two. That is the single most consequential effect, and it is consequential for a reason that has nothing to do with cryptography: a two-segment ClientHello exercises code paths that a one-segment ClientHello never did. TLS implementations that assumed the ClientHello arrives whole, middleboxes that inspect only the first segment, and DTLS or QUIC paths with path-MTU assumptions all become relevant. The failure mode is not slow; it is a hung or reset connection, which is why the deployment risk here is a tail-latency and availability problem rather than a throughput problem.

On the server side the ML-KEM ciphertext rides along with the ServerHello and the certificate chain. With a conventional ECDSA chain at roughly two to three kilobytes, the server’s first flight still fits inside a standard initial congestion window of ten segments. That headroom is precisely what gets consumed when you migrate the certificates, which is the next section and the actual problem.

Figure 2: A hybrid TLS 1.3 handshake. The 1,216-byte client key share splits the ClientHello across two segments; the server’s flight still fits the initial congestion window with a classical chain. Substituting an ML-DSA chain pushes authentication data past ten kilobytes and forces an additional round trip before the client can complete.

The lesson from the diagram is that the KEM and the signature interact through a shared budget. Neither is fatal alone. Together they exceed the initial window, and once you exceed it you are waiting for an ACK — which converts a bandwidth cost into a latency cost that scales with round-trip time. On a 15 ms intra-region path nobody notices. On a 250 ms satellite or cellular path in an industrial deployment, it is a visible regression in connection setup, and connection setup is what constrained devices do constantly because they sleep between transmissions.

Certificate chains: why ML-DSA hurts more than ML-KEM

ML-DSA signatures range from roughly 2,420 bytes at ML-DSA-44 to around 4,600 bytes at ML-DSA-87. Public keys are 1,312 to 2,592 bytes. A single certificate that was about one kilobyte with ECDSA becomes four to five kilobytes with ML-DSA-65.

Then multiply. A TLS 1.3 handshake does not carry one signature — it carries the leaf certificate’s signature, the intermediate’s signature, the CertificateVerify signature over the transcript, and typically two OCSP or Certificate Transparency signatures stapled alongside, plus two public keys. Replacing that entire set with ML-DSA equivalents pushes authentication material past ten kilobytes for a routine connection. Independent measurement work on post-quantum certificate chains consistently finds the effect shows up in time-to-first-byte rather than in bulk transfer, and that it is worst on constrained and lossy links — exactly the profile of the device fleets that are hardest to migrate for other reasons.

This is why the industry response has not been “ship ML-DSA certificates.” It has been to attack the size problem structurally. Let’s Encrypt announced in June 2026 that rather than issuing conventional ML-DSA certificates it is pursuing Merkle Tree Certificates, targeting a staging environment in late 2026 and production in 2027, precisely because the naive approach does not fit the wire budget at web scale. Meanwhile the plumbing is landing: RFC 9881 specifies ML-DSA in X.509, and Chrome has been shipping ML-DSA trust anchor support for private PKI in TLS 1.3.

Note the phrase private PKI. That is the near-term reality. Your internal mTLS mesh, where you control both endpoints and the trust store, can migrate to ML-DSA well before the public web can, because you are not constrained by a decade of client diversity. Internal PKI is the sensible first place to exercise PQC signatures at scale — it is where you learn what breaks before it matters.

The inventory problem, concretely

Discovery has to run at four layers, and each one finds things the others miss.

Static analysis over source and dependencies finds direct API calls and algorithm constants. It is the cheapest layer and the most misleading, because it systematically under-reports: configuration-driven algorithm choice, dynamic provider selection and vendored binaries are all invisible to it.

Binary and artifact scanning over container images, firmware blobs and installed packages finds embedded certificates, hard-coded keys and statically linked crypto libraries. This is where the surprises live — an expired-but-trusted CA cert baked into a base image, an RSA key in a config map, a bundled OpenSSL three major versions behind.

Network observation — capturing negotiated parameters at load balancers, service mesh sidecars and egress points — is the only layer that tells you what is actually used rather than what is available. A server may support ten cipher suites and negotiate one. Availability is a compliance question; negotiation is the security question.

Key and certificate store enumeration across HSMs, cloud KMS, secret managers and CA databases finds the material itself, with the algorithm, key size and — critically — expiry, which is your natural migration schedule.

The output should be a machine-readable cryptographic bill of materials, not a spreadsheet. CycloneDX v1.6 added native CBOM support, standardised as ECMA-424, with an object model covering four categories of cryptographic asset: algorithms with their key sizes, modes and curves; keys and certificates; protocols such as TLS and SSH; and the libraries or providers that implement them. Its most useful modelling feature is the distinction between implements and uses dependencies, which lets you express that a library implements ECDH while an application uses TLS 1.3 which uses ECDH over P-256. That distinction is what turns an inventory into an impact analysis: when a primitive is deprecated, you can traverse the graph to every affected application instead of guessing.

Generate the CBOM in CI, store it as a build artifact alongside the SBOM, and diff it between builds. A crypto inventory that is not regenerated automatically is a document, and documents go stale. The same supply-chain discipline we argued for in AI model supply chain security and provenance applies here with less ambiguity, because cryptographic assets are far more structured than model weights.

Migration Order: PKI, Protocols, and Firmware

PKI first, because everything else depends on trust anchors

You cannot deploy a PQC certificate to a client that does not trust a PQC root, and you cannot revoke a mistake in a root that has already propagated to a million devices. Trust anchor distribution is therefore the long-lead item, and it must run ahead of everything that depends on it.

Figure 3: PKI migration order. Trust anchors go out first and are verified before any PQC certificate is issued. Dual-chain issuance with capability-based selection is the steady state for an extended period; the dotted paths are the rollback points, and they are the reason the phase ordering is what it is.

The critical property of that sequence is that capability-based chain selection is a stable state, not a transitional one. Teams plan for a cutover and discover they need to serve both chains for years because some client population never updates. Design the selection mechanism as production infrastructure with its own monitoring, not as scaffolding you intend to delete. The selection signal can come from the ClientHello’s signature-algorithm extensions, from SNI-based routing, or from a separate endpoint for legacy clients — but it needs to exist, be observable, and be reversible per-client-class rather than globally.

The rollback paths deserve emphasis. In every other kind of migration, rollback means reverting a deployment. In PKI, rollback means serving a different chain to a population you have already identified as broken, without disturbing the population that is working. If you cannot do that selectively, your only rollback is a global revert, which means one broken client class blocks the entire migration.

Protocols: mostly a configuration change, with sharp edges

TLS 1.3 hybrid key exchange via X25519MLKEM768 is the most mature path and, on current stacks, mostly a matter of enabling it and confirming negotiation in telemetry. The sharp edge is the two-segment ClientHello and the middlebox behaviour it provokes.

SSH is further along than most people assume. OpenSSH 9.9 introduced mlkem768x25519-sha256 and OpenSSH 10.0 made it the default key agreement in April 2025, with the older sntrup761x25519-sha512 hybrid still available. Both are hybrids by construction, so a flaw in either the classical or the post-quantum component leaves the other protecting the session. The practical friction is version skew: bastion hosts, CI runners, git servers and embedded management interfaces all move at different speeds, and a strict algorithm policy pushed to clients before servers are ready produces connection failures rather than downgrades.

IPsec and IKEv2 have a well-specified path but less deployment. RFC 9370 defines a framework for multiple key exchanges in IKEv2, permitting up to seven additional KEMs alongside the original ECDH, with the shared secret combined such that an attacker must break every component. RFC 8784 provides a simpler intermediate step — mixing a pre-shared key into IKEv2 for post-quantum protection — which is often the pragmatic option for site-to-site VPNs between endpoints you fully control, because it requires no new algorithm support at all. The IETF’s IPsec working group has an active draft specifying ML-KEM in IKEv2 built on the RFC 9370 framework, negotiated in IKE_INTERMEDIATE or IKE_FOLLOWUP_KE exchanges. For VPN appliances that will not see a PQC firmware release before their support window closes, RFC 8784 pre-shared keys are frequently the only available mitigation, and it is worth deploying on that basis alone.

Firmware and secure boot: the hardest problem

Here the constraint is brutal and unfamiliar to most platform engineers: the verifier may be immutable. A boot ROM that verifies the first-stage bootloader is fixed at fabrication. If it only understands RSA-2048, no amount of software work changes that.

Figure 4: Firmware signing decision flow. Where the verifier cannot be updated and the signing key is under tight operational control, stateful hash-based signatures are approved and mature — at the cost of state management that has no analogue in conventional signing.

NIST SP 800-208 approves two stateful hash-based schemes, XMSS and LMS along with their multi-tree variants, as specified in RFC 8391 and RFC 8554 respectively, with approved parameter sets using SHA-256 or SHAKE256. Their appeal for firmware is that security rests solely on hash function properties — no lattice assumptions, no structured-algebra risk — and verification is cheap enough for a boot ROM.

The cost is state, and it is a genuinely unusual hazard. Each one-time key in the tree may be used exactly once. Reusing an index does not degrade security gracefully; it can enable forgery. This breaks assumptions that are load-bearing throughout modern infrastructure practice. You cannot back up the signing key and restore it, because restoring rewinds the counter. You cannot run two signing service replicas against a shared key without strict distributed consensus on index allocation. You cannot snapshot the HSM. You cannot treat the signer as stateless and horizontally scalable. Standard disaster-recovery procedure — restore from last known good — is precisely the operation that destroys security.

SP 800-208 accordingly requires that key generation and signature generation happen in hardware cryptographic modules that do not permit export of secret keying material. That requirement exists to make the dangerous operations physically impossible rather than merely prohibited by policy, and it should be read as a strong hint about how easy the mistake is to make.

The other constraint is exhaustion. An LMS tree has a fixed number of signatures. Sizing it requires forecasting your firmware release cadence across the device’s entire service life — including emergency patches, per-variant builds, and the re-signing you will do for reasons you have not anticipated. Undersize it and you exhaust the tree mid-life with an immutable verifier that trusts only that tree. Oversize it and you pay in signature size and verification time on hardware that has neither to spare.

Where the verifier can be updated, ML-DSA is the better choice: stateless, faster, and with signatures small enough for most update payloads. SLH-DSA is the conservative fallback, stateless and hash-based, but its signatures range from roughly 7,900 to nearly 50,000 bytes, which is prohibitive for constrained flash and slow to verify. Reserve it for cases where a lattice hedge genuinely matters and the size can be absorbed — long-lived root signing rather than routine image signing.

For the transitional period, dual signing is the reliable pattern: attach both a classical and a PQC signature, and let the verifier accept whichever it understands. Old devices verify the classical signature and ignore the unknown one; new devices verify both, or prefer the PQC one. It costs payload size and build complexity, and it is worth both, because it decouples the signing migration from the fleet-update migration. Those two schedules are independent and pretending otherwise is how programmes stall.

Trade-offs, Gotchas, and What Goes Wrong

Hybrid is not free and is not permanent. Hybrid key exchange means running both algorithms and combining the secrets, so you pay both computational costs and both wire costs, and you inherit both implementations’ bug surfaces. It is the right choice now because ML-KEM’s security has less field exposure than X25519’s, but it is a hedge with an expiry. If your abstraction layer cannot express “drop the classical component” as a configuration change, you have built in a future migration.

Downgrade and negotiation failures are silent. A client that supports X25519MLKEM768 talking to a server that does not will negotiate classical X25519 and complete successfully. Nothing logs, nothing alerts, and your dashboard shows a healthy connection. Without per-connection telemetry on the negotiated group, you will substantially overestimate coverage. Instrument the negotiated parameter, not the offered one, and alert on the ratio rather than on individual failures.

Middlebox intolerance is a tail problem, which makes it hard to catch. Larger ClientHellos break a small percentage of paths — enterprise TLS-inspecting proxies, older load balancers, DPI appliances. A small percentage is invisible in aggregate health metrics and catastrophic for the specific customers behind those devices. Roll out by client population with the ability to disable per-population, and watch handshake failure rates segmented by network, not globally.

The abstraction layer becomes a monoculture risk. Centralising algorithm selection is the whole point, and it also means a bug in the policy service can misconfigure every endpoint simultaneously. Version the policy, canary it like application code, and give endpoints a safe fallback when they cannot reach the policy service — one that fails to the last known good configuration rather than to a hard-coded default that may be wrong by then.

Stateful signature state loss is unrecoverable. Worth repeating because it violates a reflex. If you lose the LMS state counter and restore from backup, you must treat the key as compromised and rotate the tree — which on immutable verifiers may mean the device can no longer receive updates. Every runbook, backup job and DR drill that touches the signing HSM needs an explicit exception, and that exception needs testing.

“Crypto-agile” often means “configurable, but only in ways we anticipated.” Many implementations parameterise the algorithm while hard-coding key sizes, buffer lengths or wire formats. ML-KEM keys are an order of magnitude larger than ECDH keys, and code that allocates a fixed 256-byte buffer for a public key is not agile regardless of how many constants are in a config file. Test agility by actually changing an algorithm to one with different size characteristics — not by reading the config schema.

Compliance theatre displaces engineering. Attestation demand will arrive before the migration is complete, and there is a strong pull toward producing documents rather than changing systems. A CBOM generated in CI from real artifacts is evidence. A questionnaire response is not, and the effort spent on the second is subtracted from the first.

Practical Recommendations

Start with discovery, because every subsequent estimate depends on it and because it is the step that reliably takes longer than planned. Get a CycloneDX CBOM generated in CI within a quarter, even if coverage is partial — partial and automated beats complete and manual, because the automated one stays true.

Enable hybrid key exchange wherever it costs a configuration change, and instrument the negotiated group so you can prove coverage rather than assume it. Prioritise the origin-facing leg, not just the edge, since that is where the industry’s coverage gap actually sits.

Order signing migration by verifier lifetime, longest first. Roots of trust in devices shipping now are the most urgent decision you will make, because they are the least reversible. Internal PKI is the right place to exercise ML-DSA at scale before it matters externally, and it aligns naturally with the segmentation work in a zero-trust network architecture implementation, where internal certificate issuance is already under central control.

A phased checklist:

Phase 0 — Inventory. CBOM in CI; network capture of negotiated parameters at every termination point; key and certificate store enumeration with expiry dates.
Phase 1 — Free wins. Hybrid TLS key exchange at edge and origin; OpenSSH 10.x defaults across the fleet; RFC 8784 pre-shared keys on VPN tunnels that will never get PQC firmware.
Phase 2 — Agility. Policy service naming suites rather than hard-coding them; endpoints consuming policy through an abstraction layer; agility validated by an actual algorithm swap, not by inspection.
Phase 3 — Signing. PQC or dual-signed roots of trust for new hardware designs; LMS or XMSS where the verifier is immutable, with HSM-held state and explicit backup exceptions; ML-DSA where verifiers are updatable.
Phase 4 — PKI. Trust anchor distribution; verification that clients accept PQC chains; dual-chain issuance with capability-based selection as a permanent capability.
Phase 5 — Retirement. Classical algorithms disabled by client class as tails drain, tracked against the 2030 deprecation and 2035 disallowance horizons.

Do not skip Phase 0 to reach Phase 1 faster. Phase 1 is easy enough that it does not need the schedule relief, and Phase 0 is what determines whether Phases 3 through 5 are plannable at all.

Frequently Asked Questions

Is post-quantum cryptography migration urgent if quantum computers do not exist yet?

For confidentiality, yes — harvest-now-decrypt-later means traffic recorded today is decryptable whenever a capable machine appears, so anything with a long secrecy requirement is already exposed. For authentication, the urgency is different: signatures verified today cannot be retroactively forged. The genuine urgency in signing comes from verifier lifetime — a root of trust burned into hardware shipping now must remain valid for the device’s entire service life, which is why NSA CNSA 2.0 puts firmware signing on the earliest exclusive-use deadline.

Should I deploy pure ML-KEM or hybrid X25519MLKEM768?

Hybrid, for now. It combines X25519 with ML-KEM-768 so that breaking the session requires defeating both, which hedges against implementation flaws or unexpected cryptanalysis in a comparatively young lattice scheme. It is also what is actually deployed — recent browsers, OpenSSL, Go and Apple platforms enable it by default, and it accounts for the majority of post-quantum-capable connections measured on the public web. Pure ML-KEM becomes reasonable once field experience accumulates, provided your configuration can express the change.

Why do ML-DSA certificates cause more trouble than ML-KEM key exchange?

Because signatures multiply through the chain while the KEM appears once. ML-KEM-768 adds roughly a kilobyte in each direction. A TLS handshake, by contrast, carries a leaf signature, an intermediate signature, a CertificateVerify, and typically stapled transparency or revocation signatures — replacing all of them with ML-DSA pushes authentication data past ten kilobytes, exceeding the initial congestion window and forcing extra round trips. That is why Let’s Encrypt is pursuing Merkle Tree Certificates rather than issuing conventional ML-DSA chains.

What is a cryptographic bill of materials and do I need one?

A CBOM is a machine-readable inventory of cryptographic assets — algorithms with their parameters, keys and certificates, protocols, and the libraries implementing them — plus the dependency relationships between them. CycloneDX v1.6 standardised it as part of ECMA-424. You need one because impact analysis is otherwise impossible: when a primitive is deprecated you want to traverse a graph to every affected system, not run a keyword search and hope. Generate it in CI so it reflects real artifacts.

Can I use SLH-DSA instead of dealing with stateful signature state management?

Sometimes, and it is the right instinct where you can afford it. SLH-DSA is stateless and hash-based, so it avoids the state hazard entirely and shares the conservative security assumptions. The problem is size — signatures run from roughly 7,900 to nearly 50,000 bytes, which is prohibitive for constrained flash and slow to verify on small microcontrollers. It fits long-lived root signing where signatures are rare, not routine firmware image signing where every byte of the update payload counts.

What happens to devices already in the field that cannot be updated?

They stay vulnerable, and the honest engineering answer is to manage that at the network layer rather than pretend otherwise. Wrap their traffic in a post-quantum-protected tunnel terminated by infrastructure you can update, segment them so a compromise is contained, shorten the confidentiality horizon of the data they carry where you can, and set a replacement date. For site-to-site links, RFC 8784 pre-shared keys give quantum resistance to IKEv2 without requiring any new algorithm support on the appliance.

Post-Quantum Cryptography Migration: A Crypto-Agility ADR (2026)