Migration succeeds when a service can change its cryptography while preserving its security contract and operational behavior. An algorithm inventory is a starting artifact — ownership, dependencies, testing, and retirement determine whether the change can actually happen. This chapter builds a risk-oriented inventory, maps the dependencies that create ordering constraints no parameter choice can solve, defines rollout evidence with honest denominators, and closes with a five-level maturity model measuring demonstrated capability rather than installed algorithm count.
1. From a working lab to a migration program
Part 15 established a reproducible laboratory. This chapter asks how an organization applies those capabilities across applications, infrastructure, certificates, devices, suppliers, and archived data. You'll build a risk-oriented inventory, identify dependencies, define rollout evidence, and use a maturity model that measures capability rather than counting installed algorithms.
2. Why this is an architecture problem
Cryptography appears in TLS termination, service meshes, SSH, VPNs, database connections, key wrapping, certificates, code signing, firmware boot chains, package metadata, and document archives. Different teams own these layers, and different libraries implement them. A change to one public endpoint leaves many other paths completely untouched.
Fig. 1 — An edge deployment can be hybrid while origin and internal links remain classical. The inventory must trace all the way to termination boundaries and data exposure, not stop at the first certificate visible from the internet.
The same dependency logic applies to signatures. Updating a release signer is ineffective if installed devices cannot verify the new format. Updating devices may itself require an old signing key to authorize the update. These dependencies create ordering constraints that cannot be solved by simply selecting a stronger parameter set.
3. Build an inventory that supports decisions
A cryptographic inventory should identify the asset, purpose, algorithm and parameters, implementation version, protocol or file format, key owner, data lifetime, and evidence source. It should distinguish configured capability from observed use. Record uncertainty explicitly when discovery cannot see a path.
| Field | Example value | Why it matters |
|---|---|---|
| Asset and owner | Billing API / platform team | Assigns migration responsibility |
| Security purpose | Transit confidentiality and server authentication | Separates KEM and signature work |
| Observed mechanism | X25519, ECDSA chain | Establishes current use, not installed capability |
| Implementation | Runtime, TLS library, provider versions | Identifies upgrade dependencies |
| Data lifetime | Business-defined confidentiality period | Supports harvest-now-decrypt-later priority |
| Trust and key lifecycle | CA, rotation, backup retention | Exposes long-lived dependencies |
| Evidence and date | Handshake sample plus configuration review | Makes drift and blind spots visible |
| Target and blocker | Standardized hybrid profile / old client | Converts inventory into work |
Do not store private keys or shared secrets in the inventory. Public-key identifiers, certificate fingerprints, ownership, and metadata are usually sufficient. Access controls may still be necessary because the inventory exposes sensitive architecture and security dependencies even without any secret material in it.
4. Discovery requires several views
Static analysis can find cryptographic API calls and dependencies but may miss dynamically loaded providers, generated code, or runtime negotiation. Network observations can identify active protocol choices but miss dormant services, offline signing, and encrypted inner tunnels. Configuration review reveals intent but can differ substantially from deployed behavior.
Combine these views with package inventories, certificate stores, HSM inventories, infrastructure definitions, and interviews with service owners. Include disaster-recovery systems and maintenance interfaces — a rarely used recovery tunnel can remain a high-impact classical dependency even when daily traffic looks fully modern.
A Cryptography Bill of Materials (CBOM) in CycloneDX can represent cryptographic assets and their relationships to software components. It's a useful interchange model, not a guarantee that discovery found everything. Preserve the tool version, scope, confidence, and timestamps alongside the generated document. See CycloneDX CBOM.
Normalize names carefully. Prestandard Kyber and final ML-KEM, a cipher suite and a key-exchange group, or a certificate's subject key and issuer signature (Part 12 §2), are different inventory entities. Overaggressive normalization can erase the exact distinction needed to decide whether a system has actually migrated.
5. Prioritize by exposure and time to change
Harvest-now-decrypt-later risk depends on information collected today remaining valuable when an attacker can later break the vulnerable key establishment (Part 1 §5, Part 3 §12). Let \(X\) be the required confidentiality lifetime, \(Y\) the time needed to migrate, and \(Z\) a scenario for arrival of a cryptographically relevant quantum capability. The relationship \(X+Y>Z\) is a planning warning, not a prediction of a machine's arrival date.
For a hypothetical service with ten-year confidential records and a three-year migration dependency, even a relatively distant threat scenario can motivate early action. A public static page with no sensitive exchanged data may have different confidentiality urgency, while its software-signing and identity dependencies still need analysis. Avoid assigning priority solely from the word "encrypted" — the actual data lifetime is what matters.
For signatures, consider how long verification must remain meaningful, how widely trust anchors are distributed, and whether old artifacts can be renewed while their authenticity is still established (Part 12 §10). Firmware and archival signatures may require early planning because verifier replacement takes years, not a software release cycle.
Prioritization should combine impact, exposure, lifetime, migration lead time, and readiness of an approved replacement. Document the assumptions and revisit them as standards, vendors, and the estate change. A numerical score can help sorting, but should never hide a critical blocker behind an apparently precise total.
6. Dependency mapping and supplier questions
For every target service, identify the runtime, library, provider, protocol profile, key-management system, certificate authority, client population, and update mechanism. A server library upgrade may be easy while a vendor appliance or embedded verifier sets the actual schedule. Record that dependency explicitly with an owner and evidence.
Ask suppliers for exact supported algorithms and profiles, release versions, interoperability tests, key-management capabilities, validation scope where needed, and end-of-support dates. A statement that a product is "PQC ready" is too broad to determine whether it can negotiate a specific standardized group or verify a specific certificate chain — insist on the specific claim, not the marketing phrase.
Procurement requirements should include upgradeability and evidence, not just an algorithm checklist. Can configuration disable obsolete experiments? Can telemetry report actual negotiation? Can keys be rotated and retired? Can a deployed device receive new verification code without replacing hardware? These capabilities affect future agility as much as the first migration does.
Retain an exit strategy for unsupported components. Options may include upgrading, replacing, isolating, changing the protocol boundary, or retiring a service. A gateway can sometimes protect one exposed link, but it does not automatically remove end-to-end signature or internal confidentiality dependencies behind it.
7. Abstraction without erasing security semantics
A crypto abstraction can centralize provider selection, key access, error handling, and policy. However, a single generic encrypt() function is not a sufficient model for KEMs, AEAD, signatures, and KDFs — they accept different inputs and establish different properties (Part 2's contracts framing applies directly here). Preserve those distinctions in the API rather than flattening them.
Prefer interfaces that express the operation and context: establish key material through a named protocol, verify a signature under a specified scheme and purpose, or encrypt with an AEAD and explicit nonce rules. Algorithm identifiers and versioned formats should be authenticated where the protocol requires it. Agility must never create algorithm-confusion paths in the name of flexibility.
A feature flag can control rollout, but it should select a reviewed policy profile rather than arbitrary combinations of primitives. Separate "prefer hybrid when available" from "require hybrid." Give each setting observable behavior and negative tests so a configuration change cannot silently weaken a required protection without anyone noticing.
Keep deprecated choices out of ordinary defaults. Supporting every historical algorithm forever increases complexity and downgrade surface. Agility includes the ability to retire mechanisms and remove obsolete formats once their compatibility window closes — not just the ability to add new ones.
8. Interoperability before broad rollout
Build a matrix across important clients, servers, proxies, runtimes, devices, and network paths. Include unsupported clients deliberately so fallback or rejection behavior is tested. Verify negotiated groups, certificate paths, hostname checks, status processing, and application authorization separately (Part 12 §12's matrix is the direct template).
Test large messages and constrained buffers. PQ keys, signatures, and certificate chains can exceed assumptions in API gateways, databases, firmware parsers, and inspection devices. Measure handshake retries, failure rates, latency tails, memory, and CPU under representative concurrency. A local success is a capability check, not a production rollout result.
Use the same negative cases as the lab where applicable: wrong keys, modified messages, wrong contexts, malformed encodings, and incompatible groups. Also test operational failures such as unavailable key services, expired certificates, and partially upgraded replicas. These failures reveal whether the system preserves its security contract during change, not just at rest.
9. Staged rollout and useful telemetry
Begin with a controlled environment, then a small representative canary, followed by measured expansion. The canary should include important client types and paths rather than only the newest developer devices. Define success and pause criteria before increasing traffic, not while triaging a live regression.
For TLS, record configured policy, advertised capability, negotiated group, authentication algorithm, handshake result, retry rate, and fresh-versus-resumed status. For signing, record the selected scheme, verification population, rejected formats, and key version. Do not record secret intermediates or internal KEM validity flags (Part 13 §5).
Track migration outcomes rather than only deployments: which vulnerable paths were removed, which clients remain blocked, which old keys are still trusted, and which exception has an expiry date. An installed package version is useful evidence, but it is not the final security outcome.
10. Rollback must preserve an explicit policy
Rollback is a planned response to an identified failure — not an automatic instruction to disable PQC everywhere. If a canary has a buffer-limit problem, the response may be to pause expansion, route a specific client population through a documented compatibility path, or revert a faulty build while retaining the intended security policy for everyone else.
If rollback restores classical-only key establishment for sensitive data, that changes exposure. Record the scope, owner, duration, and compensating measures. Do not let a temporary availability exception become an invisible permanent default. Where policy requires hybrid negotiation, incompatible clients should fail according to the documented contract, not silently degrade.
Key and signature migrations can be harder to reverse than configuration changes. Once new artifacts are signed, old verifiers may not accept them. Once an old trust anchor is removed, recovery must use an already-trusted path (Part 12 §2). Rehearse overlap and rollback before changing trust distribution, not after an incident forces the question.
A recovery exercise should include backups and failover sites. Restoring an old configuration can reintroduce deprecated algorithms or keys that the primary environment already retired. Compare recovered state with the current cryptographic policy as part of disaster-recovery validation — a DR test that skips this check can silently reintroduce a vulnerability the main environment already fixed.
11. Guidance timelines and jurisdiction
The UK NCSC migration guidance sets indicative milestones: discovery and initial planning by 2028, early high-priority migration and a refined roadmap by 2031, and completion by 2035. Those are the NCSC's stated planning targets for its own audience — not evidence that all organizations worldwide share the same legal deadline. See the UK NCSC migration guidance.
The European Commission and Member States have published a coordinated implementation roadmap. Use the current official roadmap and relevant sector requirements when planning an EU deployment — do not substitute a vendor's summary for the applicable policy text. See the EU coordinated implementation roadmap.
NIST's draft transition guidance and final agility guidance support planning in their respective scopes. A compliance team should map actual obligations by jurisdiction, sector, contract, and system classification. The engineering program can then translate those requirements into testable milestones and evidence, while separately prioritizing risks that require earlier action regardless of the legal deadline.
Do not wait for a distant target year to begin inventory and dependency work. Long-lived devices, root distribution, procurement cycles, and archived signatures can consume much of the available lead time on their own. Preparatory work remains useful even when a particular protocol profile is still under standardization (Part 10).
12. A practical migration checklist
Before a work package enters implementation, identify its owner, current mechanism, target profile, affected data, dependencies, client population, and acceptance tests. Confirm that the replacement is appropriate for the actual security purpose and that its status is accurately labeled (selected vs. finalized, Part 10 §2).
Before rollout, verify functional and negative tests, interoperability, resource budgets, observability, key lifecycle, and rollback behavior. Ensure the operations team can distinguish a capability failure from a certificate or trust-policy failure. Document who can approve an exception and when it expires.
Before declaring completion, verify actual production use, residual fallback, old-key retirement, updated recovery environments, supplier dependencies, and documentation. Keep monitoring for drift and new assets. A completed migration is a maintained state, not a one-time package installation.
13. A maturity model based on demonstrated capability
| Level | Demonstrated capability | Evidence to advance |
|---|---|---|
| 0: Unknown | Cryptography is largely undocumented | Named owners and scoped discovery |
| 1: Visible | Inventory and exposure are recorded | Prioritized targets with current evidence |
| 2: Tested | Representative replacements work in a lab | Interoperability and failure tests |
| 3: Controlled | Canary rollout and rollback are exercised | Production negotiation and reliability evidence |
| 4: Managed | High-priority paths migrate with tracked exceptions | Retirement and recovery verification |
| 5: Adaptable | Cryptographic change is a repeatable capability | Rehearsed upgrades, policy enforcement, drift detection |
This is an educational model, not an official certification framework. An organization may be at different levels for public TLS, firmware signing, and internal PKI simultaneously. Assess those domains separately to avoid letting one advanced team mask an unowned legacy dependency sitting elsewhere in the same organization.
14. Budget for retirement as well as deployment
A migration budget should include removing old algorithms, updating recovery documentation, rotating affected keys, and supporting the remaining client population. Otherwise, the organization can finish the visible deployment while carrying two permanent systems and an expanding compatibility burden indefinitely.
Assign an expiry date to every temporary exception and define the evidence needed to close it. An unsupported device may require replacement; an old SDK may require an application release; a retained signing root may require an archival policy decision. These are different work items and should not share a vague "vendor dependency" label indefinitely — that label is where exceptions go to become permanent.
After retirement, test that the obsolete path is actually rejected and cannot be restored by ordinary configuration drift. Preserve any required historical verification capability in an explicitly controlled archival workflow (Part 12 §10). Removing active trust and preserving historical evidence are separate decisions, each with an owner and a documented purpose.
Does "90% hybrid coverage" mean the migration is nearly done?
It depends entirely on the denominator (§9) — 90% of all fresh handshakes, 90% of capable clients, or 90% of a small canary are three very different claims. Always report the population and the failed attempts alongside the percentage.
Should rollback always fully disable the new algorithm everywhere?
No (§10). Rollback should be scoped to the identified failure — pause expansion, route the affected population through a documented path, or revert a faulty build — while preserving the intended policy for everyone else. A blanket rollback with no expiry date becomes an invisible permanent default.
Is a higher maturity-model level in one area (e.g. public TLS) evidence the whole organization is ready?
No (§13). Assess public TLS, firmware signing, and internal PKI as separate domains — an advanced team in one area can mask a completely unowned legacy dependency in another.
Takeaways
- An inventory needs observed use, not just installed capability — a library supporting an algorithm and a service actually negotiating it are two different facts, and conflating them is the most common inventory error.
- Dependency ordering can't be solved by a stronger parameter set — an old verifier can block a signer upgrade, and an old signing key can block a verifier upgrade, creating a real chicken-and-egg constraint.
- Prioritize by \(X+Y>Z\) exposure math, not by the word "encrypted" — confidentiality lifetime and migration lead time are the levers you actually control.
- Coverage metrics need an explicit denominator and the failed-attempt count — excluding failures from a percentage is how a problematic rollout gets reported as a success.
- Rollback needs a scope, owner, and expiry date — an unscoped rollback restoring classical-only key establishment for sensitive data is a policy change, not a neutral safety net.
- Maturity should be assessed per domain, not organization-wide — public TLS, firmware signing, and internal PKI can sit at genuinely different levels at the same company.
References & further reading
- NIST IR 8547 (draft transition guidance) · NIST CSWP 39upd1 (final agility guidance) — §1, the two guidance documents this chapter builds on.
- CycloneDX CBOM — §4, inventory interchange format.
- UK NCSC migration guidance · EU coordinated implementation roadmap — §11, jurisdictional timelines.