Use a control model that ties discovery to lifecycle management, exception handling and dependency review. The governance requirement is not simply to adopt post-quantum algorithms, but to know where they are needed, where legacy dependencies remain and how to prove progress across the environment.
What controls should govern cryptographic inventory and migration?
cryptographic inventory and migration should be governed as a control problem, not a one-time algorithm swap. The right model ties discovery to lifecycle management, exception handling, and dependency review so teams can see where cryptography exists, where legacy dependencies still bind them, and where migration progress can actually be evidenced across the environment.
That means the inventory has to cover certificates, keys, protocols, libraries, embedded dependencies, and the business processes that rely on them. Migration decisions should then follow from that inventory, with risk-based prioritisation for customer-facing systems, long-lived dependencies, and places where cryptographic change could break availability or trust relationships.
Governance also has to distinguish between what can be changed quickly and what needs a staged path. A control model that only records “PQC adopted” misses the harder work of proving coverage, tracking exceptions, and making sure dependent systems, vendors, and integrations are updated in a controlled sequence.
Why inventory quality determines migration success
A cryptographic migration fails when the organisation cannot answer three questions: where the cryptography is, what it protects, and what depends on it. Without that baseline, teams tend to over-focus on headline algorithms and under-focus on hidden uses such as certificates in automation, signing in build pipelines, or embedded crypto in third-party products.
Good inventory governance therefore needs ownership, classification, and periodic refresh. The inventory should be detailed enough to distinguish high-value external interfaces from internal-only usage, because migration urgency is usually not uniform. It should also be treated as a living control, since new services, vendors, and code paths can reintroduce outdated cryptography after an apparently successful migration.
For organisations managing non-human identities and machine-to-machine trust, lifecycle visibility matters as much as algorithm selection. NHIMG’s Post-Quantum Cryptography Migration Guide is useful here because it connects inventory, crypto-agility, and migration planning to the practical reality of discovering where cryptographic dependencies live.
What the governance model should require before migration begins
Before migration starts, governance should require a dependency review that maps each cryptographic use to its operational role, owner, and replacement path. That review should identify where a new algorithm can be introduced in parallel, where hybrid operation is needed, and where a migration cannot proceed until an upstream or downstream dependency changes first.
Exception handling is equally important. Not every dependency can move on the same schedule, so the control model needs an explicit way to approve time-bounded exceptions, track compensating controls, and assign a remediation date. The point is not to allow indefinite delay, but to prevent unmanaged exceptions from becoming permanent technical debt.
Progress should be proven with evidence, not declarations. Useful evidence includes inventory coverage, exception registers, migration milestones, dependency test results, and rollback plans for systems that cannot tolerate a failed cryptographic change. NHIMG’s Post-Quantum Readiness for Identity and PKI is a good companion for this because it anchors the discussion in certificates, signing, authentication, and inventory discipline.
How to judge whether a cryptographic migration is actually under control
A migration is under control when the organisation can show that discovery is current, high-risk dependencies are ranked, exceptions are visible, and the remaining legacy footprint is shrinking over time. If any of those signals is missing, the programme may be busy without being governed.
The strongest programmes also maintain a clear distinction between cryptographic policy and implementation reality. Policy may declare the target state, but operational control must show which systems have been upgraded, which remain constrained by vendor support, and which require dual-running or staged cutover to avoid service disruption. That is the difference between a roadmap and an enforceable control.
When cryptography is embedded in certificates, tokens, signing flows, or trust chains, migration has to be coordinated with certificate lifecycle and key management, not treated as a separate project. NHIMG’s Lifecycle Processes for Managing NHIs helps frame that lifecycle discipline, because migration work often succeeds or fails based on whether the underlying trust material is managed as a lifecycle rather than as an isolated artefact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management Recommendations | Cryptographic inventory and migration depend on key lifecycle, rotation, and transition planning. |
| Recommendation — Use key lifecycle controls to govern discovery, rotation, retirement, and migration of cryptographic material. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Crypto inventory and migration protect sensitive data through governed cryptographic use. |
| Recommendation — Inventory where encryption and signing protect data, then verify legacy dependencies before changing controls. | ||
| NIST CSF 2.0 | GV.SC-02 — Cyber Supply Chain Risk Management Strategy | Migration decisions depend on vendor and dependency review across the cryptographic supply chain. |
| Recommendation — Assess supplier and dependency risk before approving cryptographic migration exceptions. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The topic directly concerns governing cryptographic use and transition decisions. |
| Recommendation — Define approved cryptographic use, inventory coverage, and migration criteria under cryptography controls. | ||
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Inventory and migration governance must control key establishment, lifecycle, and transition planning. |
| Recommendation — Apply key establishment and management controls to track cryptographic assets through migration. | ||
Practitioner Guidance
What to prioritise: Start with cryptographic discovery and dependency mapping in the systems that would create the highest operational or trust impact if they failed. If an algorithm change could break production authentication, signing, or secure communications, that dependency deserves earlier attention than low-value internal uses.
Decision rule: If a dependency cannot be upgraded cleanly, treat it as an exception with an owner, expiry date, and compensating control. If it can be upgraded in parallel, prefer a staged migration path that preserves service continuity and proves interoperability before cutover.
What good looks like: The inventory is refreshed, exceptions are time-bound, dependency chains are visible, and leadership can see a credible reduction in legacy exposure rather than just a target date for future migration.
Practitioner takeaway: Cryptographic migration is a governance exercise in visibility and dependency control first, and an algorithm choice second; if you cannot prove where crypto is used and who depends on it, you do not yet have a migration control.