Yes. Waiting for complete standard stability delays the work that makes migration possible. Organisations can already improve inventory quality, centralise certificate control, and remove manual dependencies. That preparation reduces the risk that future algorithm changes will disrupt authentication, trust chains, or service availability.
Why crypto-agility should move now, not after final PQC stability
Crypto-agility is the operational ability to swap algorithms, certificates, trust anchors, and supporting policies without redesigning the whole environment. For PQC, that matters because the hard part is rarely the final algorithm choice, it is making the estate changeable. The organisations that wait for perfect stability usually discover their inventory, renewal, and ownership data are not ready when migration pressure arrives.
A useful way to frame this is that post-quantum readiness for identity and PKI starts with the controls that let change happen cleanly, not with the last standards decision.
That is why inventory quality is foundational. If you cannot reliably locate certificates, keys, token issuers, trust chains, and the systems that depend on them, you cannot estimate migration effort or isolate blast radius. Crypto-agility turns PQC from a one-time replacement exercise into a managed lifecycle problem, where the organisation can stage, test, and retire cryptographic components in a controlled order.
One practical parallel is the certificate lifecycle problem already visible in traditional PKI. Machine identity, PKI and certificate lifecycle guidance shows why automation and ownership clarity matter even before quantum migration becomes urgent.
What preparation reduces the most migration friction
Two preparations matter most: centralising control and removing manual dependencies. Centralised certificate and key governance gives you a current view of what exists, where it lives, and who can change it. Removing manual renewal, hard-coded trust, and one-off exception handling reduces the chance that a future algorithm switch becomes a service outage or a prolonged exception queue.
The architectural goal is not to make every algorithm interchangeable overnight. It is to make the environment capable of controlled substitution. That means shorter renewal cycles where appropriate, explicit ownership for cryptographic assets, testable replacement paths, and dependency mapping for clients, intermediaries, and upstream trust services. The better the substitution path, the less likely a future PQC change will break authentication or availability in production.
NIST SP 800-57 Key Management is relevant here because crypto-agility depends on disciplined key lifecycle handling, not only on choosing a stronger algorithm.
In practice, this also means separating policy from implementation as much as possible. If trust decisions are embedded directly into applications, appliances, or scripts, algorithm transition becomes expensive and error-prone. If trust is managed through a governed control plane, migration can be sequenced by system criticality, certificate class, and external dependency rather than by panic.
What changes for security teams before standards settle
Security teams should treat unsettled PQC standards as a reason to improve readiness, not delay action. The near-term work is to reduce hidden coupling: hard-coded certificate paths, undocumented dependencies, inconsistent renewal ownership, and shadow cryptographic services. Those are the issues that make a later migration brittle. This is also where broader control discipline helps, because strong inventory and access governance often expose the same weak spots that crypto-agility depends on.
CIS Controls v8 supports the inventory-and-control side of the problem, while NIST SP 800-53 Rev 5 aligns with the access, authentication, and configuration controls that make cryptographic change governable.
The decision test is straightforward: if a future algorithm swap would require manual touchpoints across many teams, the organisation is not ready yet. If a future swap can be staged through owned inventories, validated dependencies, and automated rollout paths, then the organisation has moved the hardest work forward. That is the point at which final standards maturity becomes a refinement problem rather than an emergency programme.
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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Crypto-agility and PQC migration depend on key lifecycle and algorithm transition handling. |
| Recommendation — Apply key lifecycle discipline to support algorithm replacement without service disruption. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Crypto-agility begins with knowing where cryptographic assets and dependencies exist. |
| Recommendation — Maintain a current inventory of systems and dependencies that use cryptography. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PQC readiness affects credential, certificate, and authenticator lifecycle management. |
| Recommendation — Automate authenticator and credential lifecycle processes to reduce migration risk. | ||
Practitioner Guidance
What to prioritise: Build the migration prerequisites first, especially complete cryptographic inventory, certificate ownership, renewal automation, and dependency mapping. Those are the controls that convert PQC from a theoretical future project into an executable change programme.
Decision rule: If a system’s trust chain, key rotation, or certificate renewal still relies on manual intervention, treat it as a crypto-agility gap now, even if the final PQC standard set is still moving.
What to verify: Confirm you can identify every production certificate authority, trust anchor, token issuer, and dependent service quickly enough to support phased migration and rollback. If that visibility does not exist, standards finalisation will only compress the timeline, not simplify the work.
Practitioner takeaway: The winning posture is not waiting for perfect certainty, it is removing the operational fragility that would make later cryptographic change dangerous.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- When should organisations prioritise crypto-agility over a full algorithm swap?
- When should organisations prioritise post-quantum migration work over waiting for final standards?
- How should security teams prioritise NHI remediation in cloud environments?