They should treat it as a continuing governance programme. Standards, vendor support, and adversary capability will keep changing, so the control objective is ongoing cryptographic agility, not a single migration milestone. Organisations that lock in one architecture too early risk creating new constraints that are expensive to unwind later.
Why PQC is a programme, not a project
Post-quantum cryptography is not a one-and-done migration because the threat model, standards landscape, and product ecosystem are still moving. The practical objective is to keep cryptographic choices replaceable over time, so the organisation can swap algorithms, certificates, libraries, and protocol settings without redesigning every dependent system. That is a governance problem as much as a technical one.
Teams that treat PQC as a single implementation milestone usually optimise for “done” instead of “adaptable”. That works only if every dependency, vendor, protocol, and key-management path remains stable, which is unlikely in long-lived environments. The better framing is post-quantum readiness for identity and PKI: build inventory, plan migration paths, and keep the architecture flexible enough to absorb future cryptographic changes.
What governance has to keep changing
A continuing programme needs recurring decisions about where cryptography is used, which assets depend on it, and which systems can tolerate change first. That includes certificates, signing workflows, authentication paths, and any service that embeds algorithm assumptions into code or hardware. If those choices are made once and then left alone, the organisation can accumulate hidden coupling that becomes expensive to unwind later.
Governance also has to track the lifecycle side of cryptography, not just the choice of algorithms. Machine identity, PKI and certificate lifecycle management matters because certificate renewal, key protection, and rollout automation are where many “future-proof” plans succeed or fail. If the migration path cannot be operated repeatedly, it is not really a programme yet.
For that reason, one-time migration thinking should give way to ongoing policy for cryptographic inventory, vendor review, and change windows. The programme should be able to answer which systems still depend on legacy algorithms, which products can absorb a future algorithm swap, and which interfaces need compensating controls until support catches up.
How to avoid painting yourself into a corner
The biggest failure mode is locking an architecture around a single algorithm choice, certificate profile, or library version and then discovering that a downstream product cannot move with the rest of the estate. This is especially common when procurement, platform engineering, and security each assume someone else will absorb the eventual change. The result is a brittle estate with a narrow set of upgrade paths.
In practice, the safer approach is to treat cryptographic agility as a design requirement. That means keeping algorithm dependencies visible, separating policy from implementation where possible, and avoiding custom integrations that make replacement harder than necessary. It also means expecting different migration tempos across internal systems, SaaS platforms, and third-party services, rather than demanding a single cutoff date for everything.
Teams should also remember that PQC migration affects trust chains and operational behaviour, not just cryptographic strength. If a change breaks issuance, validation, or token flows, the business impact can arrive before the security benefit is realised. The right programme manages both timelines at once.
Risk and Threat Considerations
PQC creates a real exposure window if teams assume the first approved migration is the final state. Standards will evolve, vendor support will lag unevenly, and some assets will stay on older algorithms longer than planned, which can leave organisations with a mixed estate that is hard to govern consistently.
Failure mechanism: Early choices can hard-code algorithm, certificate, or library assumptions into applications and infrastructure, making later swaps disruptive, slow, or operationally risky. That can freeze weaker dependencies in place or force emergency redesigns when support changes.
Impact: Organisations can end up with fragmented crypto policy, delayed upgrades, higher recovery cost, and avoidable downtime if a future algorithm or platform change cannot be absorbed cleanly.
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 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | 3.1 — Key management lifecycle | PQC migration depends on ongoing key and algorithm lifecycle decisions. |
| Recommendation — Govern key lifecycles so algorithm and material changes remain replaceable over time. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | PQC agility relies on repeatable configuration and software change across systems. |
| Recommendation — Standardise cryptographic configuration so future algorithm changes can be rolled out consistently. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management Strategy | Vendor support and dependency changes make PQC a governance and third-party coordination issue. |
| Recommendation — Track supplier crypto roadmaps and align migration plans to external support timelines. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptography governance needs repeated policy review, not a single implementation event. |
| Recommendation — Review cryptographic use and required changes on a recurring governance cycle. | ||
Practitioner Guidance
What to prioritise: Build an inventory of where cryptography is actually used, then rank systems by dependency depth, exposure, and replacement difficulty. That gives you a migration sequence that reflects operational reality rather than abstract asset criticality.
What to verify: Confirm that the organisation can rotate algorithms, certificates, and libraries without rewriting applications or reworking every integration. If a dependency cannot be replaced in a controlled way, treat it as a governance issue, not just a technical backlog item.
Common mistake: Declaring success when a pilot migration works in one environment. A pilot proves feasibility, not durability, and it does not tell you whether the programme can survive vendor change, protocol updates, or a second migration wave.
Practitioner takeaway: PQC succeeds when teams govern for change over time, not when they declare a single migration complete.
Related resources from NHI Mgmt Group
- Should organisations treat AI agent governance as a one-time rollout or an ongoing programme?
- What mistakes do teams get wrong when they treat OTT consent as a one time banner instead of an ongoing governance process?
- How should organisations treat GDPR compliance as a continuing programme rather than a one-time project?
- Should IAM teams treat directory governance and IGA as one programme?