Start with cryptographic inventory, not with algorithm selection. Teams need a complete map of certificates, keys, algorithms, dependencies and owning identities before they can scope exposure or sequence migration. Without that baseline, PQC planning becomes speculative and remediation priorities will be wrong.
Why PQC Readiness Starts with Cryptographic Inventory
pqc readiness is a migration-planning problem before it is an algorithm-choice problem. Security teams need to know where cryptography exists, who owns it, what it protects, and which systems depend on it before they can decide what must change, what can wait, and where the highest exposure sits. That is the only reliable way to scope risk and avoid chasing the wrong workstream.
A useful inventory goes beyond a list of certificates. It should capture keys, protocols, libraries, hard-coded dependencies, external trust anchors, and the identities that issue, consume, renew, or rotate cryptographic material. That matters because the migration path for a public-facing TLS estate, an internal service mesh, a signing pipeline, and a long-lived embedded system will not look the same.
For teams already managing machine identity and certificate lifecycles, this is where PQC planning becomes concrete: certificates, key protection, renewal automation, and algorithm agility all intersect. A good reference point is Machine Identity, PKI and Certificate Lifecycle Guide, which helps connect the inventory to lifecycle reality rather than treating certificates as isolated artifacts.
What a PQC Inventory Needs to Capture
The minimum useful inventory is a cryptographic bill of materials, even if the implementation starts with spreadsheets or CMDB enrichment rather than a dedicated platform. The point is to make cryptography visible in operational terms: where it lives, how it is used, which algorithms are in play, what breaks if it changes, and which owners can act on it.
At a practical level, teams should record at least these fields for each item:
- Asset or service name, environment, and business owner
- Cryptographic purpose, such as TLS, code signing, data-at-rest protection, authentication, or token signing
- Algorithm, key size, certificate type, and library or protocol dependency
- Issuer, renewal path, storage location, and rotation mechanism
- Owning identity, service account, workload, or team responsible for change
- External dependencies, including vendors, managed services, HSMs, and third-party integrations
This is also where crypto agility becomes measurable. If you cannot identify where an algorithm is embedded, you cannot estimate the cost of replacing it, detect where dual-stack support is needed, or determine which systems require accelerated remediation. Post-Quantum Readiness for Identity and PKI is a useful companion because it ties the inventory directly to migration sequencing, certificates, signing, authentication, and the need to map dependencies before choosing a target algorithm.
How to Turn Inventory into a Migration Sequence
Once the inventory exists, prioritisation should be based on exposure, dependency, and replacement difficulty, not on whichever system is easiest to modernise first. Public trust services, long-lived certificates, signing systems, and high-value authentication paths usually deserve earlier attention because they create broader downstream dependency and longer remediation lead times.
A sensible sequence is to classify each cryptographic use case by its failure impact. For example, loss of confidentiality risk may matter most for data at rest and archived data, while integrity and authenticity risk may dominate for code signing, firmware signing, and software distribution. Authentication paths are different again, because breakage there can stop access even if the underlying data remains intact.
That sequencing also needs lifecycle realism. Some systems can accept a phased dual-algorithm transition. Others, especially embedded, regulated, or vendor-managed environments, may need full replacement windows, contract changes, or architectural refactoring. Security teams should therefore treat the inventory as the input to a dependency graph, not a reporting exercise.
Risk and Threat Considerations
PQC programmes fail when they underestimate hidden cryptographic dependency. The main risk is not choosing the wrong future algorithm, it is discovering too late that critical services, certificates, or signing chains cannot be changed safely because ownership, dependency, or update paths were never mapped.
Failure mechanism: Missing inventory data leaves blind spots in algorithm usage, embedded certificates, and downstream dependencies, so migration plans understate blast radius and overstate how quickly replacement can happen.
Impact: Teams can end up with uneven exposure, delayed remediation, broken authentication or signing paths, and forced emergency changes when a vulnerable or obsolete cryptographic dependency finally has to be replaced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-57 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of keys, certificates and other authenticators central to PQC inventorying. |
| IA-9 — Service Identification and Authentication | Applies where workload, service and machine identities rely on cryptographic material affected by PQC. | |
| CM-8 — System Component Inventory | Supports building an accurate inventory of cryptographic assets, dependencies and owning systems. | |
| Recommendation — Inventory authenticators and define rotation, replacement and retirement paths before planning PQC migration. Map service-to-service cryptographic dependencies and identify which authentication paths need PQC transition. Extend your component inventory to include cryptographic dependencies, owners and replacement constraints. | ||
| NIST SP 800-57 | Recommendation for Key Management Part 1 | Directly addresses cryptographic key lifecycle, cryptoperiods and algorithm transition planning. |
| Recommendation — Use key lifecycle policy to sequence cryptographic replacement and manage cryptoperiod transitions. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Covers governance of cryptographic use, selection and operational controls relevant to readiness planning. |
| Recommendation — Document cryptographic use cases and control the transition path under cryptography governance. | ||
Practitioner Guidance
What to prioritise: Start with the highest-consequence cryptographic uses, especially authentication, signing, and externally exposed trust paths. Those are the areas where an incomplete inventory most often turns into an urgent operational problem.
What to verify: Every inventory record should have an accountable owner, a current algorithm, and a clear retirement or replacement path. If any of those three are missing, treat the item as not yet understood enough for PQC planning.
Common mistake: Treating certificate discovery as the whole job. Certificates are visible, but keys, libraries, protocols, embedded trust stores, and service dependencies are what usually determine whether migration succeeds.
Practitioner takeaway: The first deliverable in a PQC readiness programme is not a target algorithm, it is a trustworthy inventory that lets you rank exposure, dependencies, and migration effort with evidence rather than guesswork.