Organisations should begin planning now, even before every standard detail is final, because migration across certificates, validation software, and application ecosystems can take years. Waiting creates a larger backlog once production deadlines tighten. The sensible sequence is inventory, lab testing, and dependency mapping first, then staged rollout as standards and interoperability guidance stabilise.
Why organisations should not wait for final post-quantum details
Post-quantum migration is not a single control change, it is a programme that touches cryptographic inventory, certificate lifecycles, dependency owners, validation tooling, and application compatibility. The delay is often in discovery and coordination, not in selecting algorithms. That is why the right decision point is usually to start the work that is standards-agnostic now, then swap in final parameter choices as guidance stabilises.
For teams that manage certificates and machine trust, the migration problem is especially close to lifecycle automation and crypto agility. The practical lesson from Machine Identity, PKI and Certificate Lifecycle Guide is that long-lived certificate estates are already operationally fragile, so waiting for perfection just increases the eventual change set.
What work is safe to start before standards are final
The earliest work should focus on identifying where public-key cryptography exists and how it is consumed. That includes certificates, signing services, TLS termination points, hardware-backed key stores, libraries, protocols, and applications that hard-code algorithm assumptions. Once those dependencies are visible, organisations can separate what must change immediately from what can be handled later through staged replacement.
This is also the point to test interoperability in a lab rather than in production. Lab validation lets teams discover whether a dependency only supports a narrow set of key sizes, whether a library upgrade breaks application behaviour, or whether a partner integration needs an exception path. In practice, the migration sequence is inventory first, then controlled testing, then phased rollout.
That sequencing aligns well with general control discipline in CIS Controls v8, especially where asset inventory and secure configuration support planning for large-scale technology change. It also fits governance models such as ISO/IEC 27001:2022 Information Security Management, which expects organisations to manage security change through defined controls rather than ad hoc upgrades.
How to decide when migration should move from planning to execution
The trigger is not “all standards are final”; it is whether the organisation can still absorb the change without compression risk. If certificate renewal windows, application release cycles, or supplier dependencies mean the work will collide with a production deadline later, migration should begin now. The earlier the inventory and compatibility testing start, the more room there is to absorb implementation surprises without emergency replacement.
For organisations with cloud and third-party dependencies, the decision should also reflect platform concentration risk. When one platform, one library family, or one certificate authority path is deeply embedded, the migration is slower because every downstream integration has to be checked. Frameworks that emphasise secure architecture and operational resilience, such as CSA Cloud Controls Matrix and the NIST Cybersecurity Framework 2.0, support that kind of dependency-aware planning.
Risk and Threat Considerations
Waiting too long concentrates migration into a smaller operational window, which raises outage risk, compatibility failure risk, and the chance of rushed cryptographic choices. The larger the certificate and software estate, the more likely it is that some components will be overlooked until production pressure exposes them.
Failure mechanism: Legacy cryptography remains embedded in certificates, libraries, appliances, and application code until the organisation is forced to replace them at speed, often before interoperability testing is complete.
Impact: The result can be service disruption, delayed remediation, vendor exception sprawl, and a backlog that is much harder to execute once deadlines or external interoperability requirements become fixed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Cryptographic migration starts with knowing where certificates and dependent systems exist. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | PQC migration depends on compatible software, libraries, and configuration changes. | |
| Recommendation — Inventory cryptographic assets and owners before scheduling any PQC rollout. Validate cryptographic configuration changes in lab environments before production cutover. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | PQC migration is a cryptography lifecycle and transition issue covered by cryptographic controls. |
| Recommendation — Plan cryptographic transitions under defined policy and technical control. | ||
| NIST CSF 2.0 | PR.DS-10 — Cryptographic Protection | The subject is about replacing current cryptography with stronger post-quantum protection. |
| Recommendation — Track where cryptography is used and replace vulnerable algorithms in stages. | ||
| CSA Cloud Controls Matrix | CEK — Encryption and Key Management | PQC migration affects key and certificate handling across cloud and application environments. |
| Recommendation — Map key and certificate dependencies before updating cryptographic mechanisms. | ||
Practitioner Guidance
What to prioritise: Build a cryptographic asset inventory that covers certificates, libraries, protocols, and any application or infrastructure component that makes algorithm assumptions. If you cannot name the owners of those dependencies, you are not ready to plan the rollout.
Decision rule: If replacement work will require coordination across multiple teams or suppliers, start lab testing now rather than waiting for final wording on every standard detail. The standard can mature while your dependency map and validation results mature with it.
What good looks like: You have a staged migration plan with owners, test coverage, and replacement order defined for the highest-risk dependencies first, so final standards only change the target configuration rather than the entire programme.
Practitioner takeaway: Post-quantum readiness is mainly a change-management problem disguised as a cryptography problem, and the organisations that start dependency discovery early will have the most options when the standards firm up.
Related resources from NHI Mgmt Group
- When should organisations prioritise migration over waiting for a better contract?
- When should organisations prioritise quantum risk work over other security projects?
- When should organisations prioritise post-quantum upgrades over routine certificate maintenance?
- How should organisations begin planning post-quantum encryption migration now that NIST has released primary standards?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
