up:: The Transition MOC
Migration Architecture
Migration architecture is how an organization replaces the cryptography inside a running system without breaking it, and it breaks into three jobs that run roughly in order: find every place cryptography actually lives (a CBOM, built through discovery), make it swappable so the next algorithm change is a configuration edit rather than a rebuild (crypto-agility), and bridge the gap safely while the classical and post-quantum worlds coexist (hybrid cryptography, composite certificates, and cross-certification).
Map of content
A short overview of migration architecture, and the index that routes you to every note in this section. Skim it to get oriented, then follow the links to go deep.
The short version:
- The discipline rests on a single ratio. Swapping the algorithm is the easy 20%. Finding every place it hides and rolling out the replacement safely is the other 80%, and that’s where real programs succeed or stall.
- Discovery comes first, because a migration replaces specific algorithms across a whole estate, and the scope of that replacement is unknown without a CBOM.
- Crypto-agility is the enabler. With it, replacing a vulnerable algorithm is one central change that propagates everywhere; without it, every application that touches cryptography has to be found, opened, and rewritten one at a time.
- The bridges keep you safe during the switchover. Hybrid key exchange protects confidentiality, while composite certificates and cross-certification carry trust and identity across.
- Every bridge is temporary by design. The classical component is the exact thing a quantum computer breaks, so each one needs an exit plan and a retirement date, not permanent residence.
Think of re-keying a large building while people keep working inside it. Cutting a new key blank is trivial. The real work is finding every door (including the ones no one documented, the ones a contractor controls, the ones welded shut years ago), and then changing each lock without locking anyone out mid-shift. Migration architecture is that survey and that careful rollout, applied to an organization’s cryptography.
What is migration architecture?
Migration architecture is the practice-and-method layer of the post-quantum transition, the answer to “we know we have to move to the new NIST standards, so how do we actually do it in production.” It sits between the standards (what to deploy) and the mandates (by when), and it covers the sequence, the enabling properties, and the transitional structures that let a live system change its cryptography without an outage or a trust gap.
The reason it deserves its own discipline is that the cryptography is the small part. The algorithms are standardized, well-studied, and increasingly shipped by default in TLS, SSH, and IPsec. What isn’t handed to you is knowledge of your own estate, the ability to change it centrally, and a way to keep old and new software trusting each other during the years the two coexist. Those three gaps are exactly what discovery, agility, and the bridges close.
What are the phases of a post-quantum migration?
A migration runs in phases, and each one depends on the phase before it, which is why skipping ahead to the algorithm swap is the classic way to stall:
| Phase | The job | The core artifact or property | Grounding |
|---|---|---|---|
| 1. Discover | Find every place cryptography lives across the estate, at parameter-set granularity, with an evidence grade on each entry | A CBOM built through scanning, static analysis, configuration review, and vendor inquiry | Inventory framed as a migration prerequisite |
| 2. Make it agile | Move algorithm choice into configuration so the next change is a setting, not a redevelopment project | Crypto-agility (algorithm agility, and the harder architectural agility) | Agility treated as a design objective, not a protocol feature |
| 3. Bridge the gap | Run classical and post-quantum together so confidentiality and trust survive while the ecosystem is split | Hybrid key exchange, composite certificates, cross-certification | The IETF hybrid and PQ/T standards |
| 4. Retire the classical half | Remove the quantum-vulnerable component once verifiers support post-quantum directly and the timeline demands it | Standalone post-quantum algorithms | CNSA 2.0 drives toward standalone PQC |
Source: NIST, “Transition to Post-Quantum Cryptography Standards,” NIST IR 8547; Bertino et al., “Quantum-Resistant Networks,” arXiv:2605.04129, §10.2; NSA, “Commercial National Security Algorithm Suite 2.0,” CNSA 2.0.
The phases overlap in practice (you keep discovering as you go, and agility work continues through the bridge phase), but the dependency order holds: prioritization needs discovery, a cheap swap needs agility, and a safe switchover needs a bridge.
How do I find all my cryptography?
You build a CBOM, the structured inventory of every algorithm, key, certificate, and protocol configuration in the estate. It’s the foundational deliverable, because until you know which systems use which cryptography, you can’t know what’s quantum-vulnerable, what’s already safe, what a vendor controls, or where to begin. A useful entry is granular: not “we use RSA,” but “RSA-2048 protecting the TLS certificate key on application X, managed in this HSM, guarding this data class.”
Discovery combines four methods, because no single one sees the whole estate:
- Active scanning inspects live traffic, TLS handshakes, and certificate stores to find configurations in use.
- Static analysis surfaces library calls, hardcoded parameters, and key-management patterns that never appear in a handshake.
- Configuration review reads server configs, application settings, and infrastructure-as-code to capture what a system actually permits.
- Vendor inquiry documents the cryptography inside third-party products, the part internal scans can’t see.
Two disciplines separate a defensible inventory from a reassuring one:
- Grade every entry by evidence. Verified evidence is proven from a technical artifact like a handshake capture or certificate export; documented evidence is asserted by a diagram or a vendor datasheet but unproven, and it can be wrong because systems don’t always run the way the paperwork claims.
- Source the transport layer from configuration files, not handshake observation alone. One 2026 corpus study of real-world TLS found 21.8% of TLS-enabled contexts still permitted TLS 1.0 or 1.1 as configured even though most would negotiate a modern version in a single probe, so a scanner-only inventory misses fallbacks that a downgrade attack can still reach.
Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).
The single most common gap is vendor cryptography. A first pass that only surveys internally-managed systems leaves much of the real footprint uncounted, because vendor-controlled surfaces are invisible to internal scans and only surrender their details to structured inquiry.
How do I make my cryptography swappable?
You build crypto-agility, the architectural property that lets a system change its algorithms through configuration instead of a redesign. An agile system treats the choice of algorithm as a settings decision rather than a baked-in assumption, so swapping one primitive for another reaches everywhere at once from a central point. That’s the difference between a migration you run once cleanly and a migration that means locating and rewriting thousands of individual implementations.
Agility shows up as a handful of patterns, and most real deployments combine several:
- An abstraction API layer, where applications call generic operations like
sign(message)and a central module resolves the actual algorithm from policy at runtime. - Crypto-as-a-service, where a dedicated internal service, KMS, or HSM-backed API performs all operations and applications stay algorithm-unaware, the most scalable pattern for a large estate.
- A provider or plugin architecture, where a new algorithm loads into an existing framework (a Java provider, an OpenSSL provider, 11 via an HSM) without recompiling the application.
- Protocol negotiation, where the protocol picks the algorithm at connection time and configuration decides what’s allowed, which is how agility already lives inside TLS, SSH, and IPsec.
A distinction the agility conversation usually skips is that swapping a primitive and evolving the surrounding design are two different capabilities. Algorithm agility (replace ML-KEM with another KEM, rotate a hash) is well-understood and standards-driven. Architectural agility (move from centralized PKI to distributed or threshold trust, shift from multi-year certificates to short-lived credentials, add a recovery mechanism for a compromised CA) is significantly harder and rarely advertised, and it’s the real difference between a network that’s quantum-ready and one that stays brittle even after adopting post-quantum algorithms.
Speed matters too. A system that can technically reconfigure a primitive but takes 18 months to do it in production keeps its exposure window open the whole time, so the practical target is a rotation measured against a disclosure, rather than against a hardware refresh cycle.
Source: NIST IR 8547; Bertino et al., arXiv:2605.04129, §10.2; Balaji et al., arXiv:2605.17955.
One caution worth stating plainly: agility is a migration enabler, not a security control. It gives you the ability to change the algorithm; it doesn’t make the new algorithm strong, and it doesn’t decide to actually make the change. Governance has to ride alongside it, including a minimum-floor policy so a negotiated system can’t be downgraded to a weak option.
How do I migrate without breaking things?
You run the old and new cryptography together during the transition, using a small set of bridging structures so confidentiality and trust survive while the ecosystem is only half-upgraded. Each bridge combines a classical and a post-quantum mechanism so that defeating the pair requires breaking both at once, and each one solves a different layer of the problem:
| Structure | What it combines | Layer it works at | What it protects |
|---|---|---|---|
| Hybrid key exchange | A classical KEM and a post-quantum KEM, combined in the key schedule | Key establishment in the handshake | Session confidentiality against harvest-now-decrypt-later |
| Composite certificate | A classical and a post-quantum key and signature fused under one identifier | Certificate format | Identity and trust, forgeable only if both algorithms break |
| Dual or parallel signatures | Two independent certificates or signatures, one per algorithm | Certificate and chain topology | Identity, with each algorithm legible to older software |
| Cross-certification | Two separate certificate authorities, joined by a vouching certificate | PKI trust topology | Early trust for a new post-quantum root before trust stores update |
Sources: Stebila, Fluhrer, Gueron, “Hybrid key exchange in TLS 1.3,” IETF, draft-ietf-tls-hybrid-design; RFC 9370, Multiple Key Exchanges in IKEv2; Gray, Ounsworth, Fluhrer et al., “Composite ML-DSA for use in X.509 PKI,” IETF LAMPS, draft-ietf-lamps-pq-composite-sigs; Driscoll, Parsons, Hale, “Terminology for Post-Quantum Traditional Hybrid Schemes,” RFC 9794; RFC 5280; RFC 4158.
These compose rather than compete. A real migration can put a post-quantum root behind a bridge with cross-certification, issue composite certificates under it, and separately turn on hybrid key exchange in TLS, because each move addresses a different layer of the same transition. The reason confidentiality gets bridged first is harvest now, decrypt later: traffic recorded today can be decrypted once a machine exists, so hybrid key exchange closes that window on new sessions immediately, while signatures and PKI move on a slower track because they only fail once a quantum computer is actually real.
The trap that breaks bridge rollouts is size. A hybrid key share carrying a post-quantum key is over a kilobyte, and that inflation lands in the first message of a handshake that decades of middleboxes assumed would stay small. Cloudflare, testing hybrid at scale, found sharp cliffs where connections failed once the handshake grew past certain sizes, because a legacy box on the path (one neither endpoint controls) drops the larger message. Two perfectly configured hybrid endpoints still fail if a device between them refuses the bigger handshake, which is the load-bearing lesson of the whole bridge phase: a protocol is only as safe as the weakest endpoint on its path.
Source: Cloudflare, “Defending against future threats: Cloudflare goes post-quantum”.
Why is finding it the hard 80%?
Because the algorithm swap is the well-understood part and the estate is the unknown part. NIST standardized the replacements, the IETF wired them into the major protocols, and browsers and servers increasingly ship them by default, so the cryptographic move itself is a solved problem with a known answer. What no one hands you is a complete, current picture of where your cryptography lives, who controls each instance, and what each one protects.
That’s where the weight sits. Cryptography hides inside vendor products you can’t scan, inside firmware with multi-year replacement cycles, inside forgotten systems no one mapped, and inside configurations that permit weak fallbacks a single probe never reveals. Organizations that try to migrate without an inventory consistently discover new vulnerable systems all the way through the project, systems that were never in scope. This is why migrations stall first on visibility and ownership rather than on cryptography, and why who owns each surface is as load-bearing a question as which algorithm replaces which. The discovery and the safe rollout are the 80%; the primitive swap is the 20%.
When does the classical half come out?
Every bridge is a transition mechanism with a built-in expiration, because the classical component is the exact thing a quantum computer breaks. Once a cryptographically relevant quantum computer exists, the classical half of a hybrid handshake, a composite certificate, or a cross-certificate bridge contributes nothing against that adversary and becomes dead weight in the trust path. The endgame of the migration is the classical component retiring and the post-quantum algorithm standing alone, on the schedule the mandates set. CNSA 2.0, for example, drives national security systems toward standalone post-quantum algorithms rather than permanent hybrids.
The discipline this demands is an exit plan, and it’s the part organizations most often skip. A bridge earns its complexity during the window when a quantum computer might not exist yet and the post-quantum algorithms are still young. As those algorithms accumulate scrutiny and the timeline sharpens, the hedge stops paying for itself.
At that point the classical half should come out before the deadline rather than lingering because no one owns the decision. A bridge with no retirement plan quietly becomes permanent technical debt and hides an unfinished migration behind a reassuring word.
Source: NSA, “The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ,” CSI CNSA 2.0 FAQ.
Common misconceptions
- “The migration is swapping the algorithm.” The algorithm swap is the easy fifth of the work. Finding every place cryptography lives and rolling the replacement out safely across a running estate is the other four-fifths, and it’s where programs actually succeed or fail.
- “Our asset inventory is our CBOM.” An asset inventory lists systems; a CBOM enumerates the cryptography inside them. Conflating the two is the most common starting error, and it leaves the vendor-controlled surfaces uncounted.
- “Crypto-agility means we’re migrated.” Agility makes the migration feasible; it isn’t the migration. An agile system with no plan and no execution is still running vulnerable algorithms.
- “Hybrid buys us more time.” Hybrid closes the harvest-now-decrypt-later window on new data sooner, so it gets you to the starting line earlier, but the classical half still has to be removed before Q-Day. It moves the start, not the finish.
- “If both endpoints support hybrid, we’re done.” A middlebox neither endpoint controls can drop the oversized handshake. Support at the two ends is necessary and not sufficient; the whole path has to tolerate the larger messages.
- “A composite end-entity certificate makes my chain quantum-safe.” The whole chain has to carry post-quantum protection. A composite certificate that chains up to a classical-only intermediate or root still hangs from a quantum-forgeable trust anchor.
Questions people ask
Where do I start? With discovery, on the crown-jewel and highest-risk systems first. A CBOM doesn’t have to be complete to be useful, and trying to inventory everything at once is a common way to never ship. Completeness grows in phases while the highest-exposure systems get attention immediately.
Do I need a complete inventory before I begin migrating? No. You need enough of one to prioritize, then you migrate the top risks while discovery continues. Treat the CBOM as a living document, because an inventory produced once is stale within roughly six months as systems, algorithms, and vendor products change.
Do I have to use hybrid, or can I go straight to post-quantum? Both are valid depending on your risk posture and your regulator. Hybrid is the widespread commercial default because it hedges an undiscovered flaw in the young post-quantum algorithms, while CNSA 2.0 permits going straight to standalone post-quantum and doesn’t require the hybrid step.
What’s the difference between hybrid key exchange and a composite certificate? They protect different things. Hybrid key exchange combines two KEMs to protect the confidentiality of a session against later decryption. Composite certificates combine two signatures to protect identity and trust against forgery. A full migration needs both, on their own timelines.
How is cross-certification different from a composite certificate? They operate at different layers. A composite certificate fuses two algorithms inside one certificate, while cross-certification links two separate certificate authorities so a trusted classical root can vouch for a new post-quantum one. Large migrations commonly use both together.
Can I do this without breaking production? Yes, which is the entire point of migration architecture. Agility lets you change algorithms centrally instead of touching every application, and the bridges keep old and new software interoperating during the switchover, so the change is incremental rather than a flag day.
How long does a migration take? Long enough that the deadlines are measured in years. For an estate with little crypto-agility the work is redevelopment rather than reconfiguration, which is why building agility first compresses the timeline for everything downstream. The mandates set the outer bounds.
Go deeper
Find it: Cryptographic Bill of Materials (CBOM), the inventory of where cryptography actually lives, the discovery methods that build it, and the discovery tooling (source and binary scanners, network and certificate discovery, and vendor inquiry) that does the finding.
Sequence by data, and manage the keys: Data at Rest, in Motion, and in Use (migration is sequenced by which data must stay secret and for how long), Key Management (the key lifecycle where the real migration friction lives), and HSM (Hardware Security Module) (the hardware whose firmware has to add the new algorithms before keys held there can move).
Make it swappable: Crypto-Agility, the property that turns the next algorithm change from a rebuild into a configuration edit, and Certificate Lifecycle Management for PQC, the automated issuance, renewal, and rotation engine (ACME, and the CA/Browser Forum drive toward 47-day certificates by 2029) that makes agility real at scale for the certificate estate.
Bridge the gap safely: Hybrid Cryptography for confidentiality, KEM Combiners for securely joining a classical and a post-quantum KEM so the session key holds if either half survives, Composite Certificates for identity fused in a single certificate, Dual Signatures for identity carried as two separable, backward-compatible signatures, and Cross-Certification for getting a new post-quantum root trusted early.
Prove it works: Testing as the Control Surface, why deploying the new algorithm is the claim and validating the deployment is the security, and the failure modes (interoperability, oversized-message fragmentation, data-flow truncation, side-channel leakage, and silent downgrade) that only testing catches. ACVP and PQC Validation is the formal side of it: how ACVP-driven CAVP algorithm testing and CMVP module validation under FIPS 140-3 turn “uses ML-KEM” into federally recognized proof.
Learn from history: Lessons from Past Crypto Migrations, what the MD5, SHA-1, DES-to-AES, and RC4 deprecations show about why a broken algorithm takes a decade or more to remove and why migrations stall on deployment rather than on the math.
Cost, storage, and production reality: What a PQC Migration Costs (the cost drivers, why the algorithms are free and the labor is the bill, and the $7.1 billion federal anchor), Re-Encrypting Data at Rest for PQC (whether you have to re-wrap stored archives, key rotation versus full re-encryption), PQC for Databases and Data-at-Rest Key Wrapping (the envelope-encryption DEK/KEK model, TLS-to-database as the harvestable channel, and TDE key rotation), and PQC Performance and Size Overhead (why the cost is size not speed, the oversized handshake, and what actually breaks in production).
Key management and its standard: Key Management (the key lifecycle where migration friction lives) and NIST SP 800-57 (Key Management) (the standard behind it, cryptoperiods, the comparable-security-strength tables, and the key-state lifecycle that HNDL and Mosca sizing rest on).
The deadlines that force the schedule are in the mandates; why programs stall on the organizational side is in Why Post-Quantum Migrations Stall and Cryptographic Ownership; the algorithms you’re migrating to are in The New Standards.
Everything here is the map, given freely. When your team needs this turned into a migration sequenced against your own systems, with the inventory built, the agility gaps closed, and the bridges rolled out and retired on plan, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.