Start with a cryptographic inventory. You cannot plan a credible migration until you know where RSA, certificate-based trust, signing, and encrypted archives exist. Once the inventory is complete, classify each use by data sensitivity, business lifetime, and dependency criticality so the highest-risk trust anchors are addressed first.
Why the first step is a cryptographic inventory
The first practical move is to build a complete inventory of where cryptography is actually used, not where teams assume it is used. Post-quantum planning starts with finding every RSA trust anchor, certificate chain, signing workflow, encrypted archive, and dependency that would fail if today’s public-key assumptions stopped holding.
That inventory should be asset-level, not policy-level. Teams need to know which systems depend on certificates for trust, which services verify signatures, which archives must remain decryptable for years, and which integrations would break if an algorithm or key length changed.
A useful way to scope the inventory is to classify each cryptographic use by business lifetime, data sensitivity, and dependency criticality. A short-lived internal token does not need the same migration treatment as a root trust anchor, a signing key used for distributed software, or an archive that must stay confidential for a decade.
What the inventory must capture to be migration-ready
The inventory should identify the cryptographic primitive, the system or application using it, the trust relationship it supports, and the operational owner. That includes certificates, key hierarchies, code-signing paths, TLS endpoints, document signatures, backups, and any long-retention data protected by asymmetric cryptography.
It should also record whether the cryptography is externally visible, embedded in third-party products, or hidden inside libraries and managed services. Hidden uses are often the hardest to migrate because the dependency exists in code or platform defaults rather than in a visible architecture diagram.
For certificate and PKI-heavy environments, the inventory should distinguish trust establishment from encryption at rest. The migration urgency is often driven less by raw encryption volume and more by the places where certificates, signatures, and chained trust assertions underpin authentication or software integrity. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is useful here because it frames certificates as lifecycle-managed trust assets, not static configuration.
How to prioritise the first wave of post-quantum work
After inventorying, prioritise the highest-risk trust anchors first. Long-lived data, externally trusted signatures, and systems with deep third-party dependency chains should move ahead of low-impact or easily replaceable uses. The question is not just “where is RSA used?” but “where would compromise of this trust relationship create the longest-lived or broadest damage?”
Teams should also separate immediate replacement candidates from transition candidates. Some uses can be swapped early with limited business disruption, while others require compatibility planning, vendor coordination, or staged dual-stack support before any algorithm change is safe.
That prioritisation is exactly where cryptographic inventory becomes a risk tool rather than a spreadsheet exercise. Post-Quantum Readiness for Identity and PKI is a useful companion because it ties inventory to crypto-agility, migration sequencing, and the practical impact on certificates and signing.
Risk and Threat Considerations
The main risk is not only future decryption, but hidden dependency failure. If teams do not know where RSA, certificate trust, or signing is embedded, they cannot judge which systems are vulnerable to harvest-now-decrypt-later exposure or which trust paths would fail during an abrupt algorithm transition.
Failure mechanism: Incomplete inventories miss embedded or third-party cryptography, so high-value trust anchors remain unclassified, unprioritised, and unplanned for until migration work is already under time pressure.
Impact: Organisations can leave long-life confidential data exposed to retrospective decryption risk, delay remediation of critical trust chains, and discover too late that a business-critical integration depends on a quantum-vulnerable algorithm.
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, NIST SP 800-57 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Cryptographic inventory and migration planning depend on knowing key and algorithm dependencies. |
| SC-13 — Cryptographic Protection | The question concerns where cryptographic protection exists and how it should be transitioned. | |
| Recommendation — Inventory cryptographic dependencies and plan key migration before replacing algorithms. Catalog protected assets and assess where algorithm changes affect confidentiality and trust. | ||
| NIST SP 800-57 | Key Management | PQC planning hinges on key lifecycle and algorithm transition considerations. |
| Recommendation — Track key lifecycle dependencies and align migration timing to key retirement and replacement. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptographic inventory directly supports governance over where cryptography is used. |
| Recommendation — Document cryptographic use cases and assign migration owners for each protected system. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Inventorying encrypted archives and protected data maps to control over sensitive information. |
| Recommendation — Identify sensitive data locations and rank them by retention and exposure risk. | ||
Practitioner Guidance
What to prioritise: Start with trust anchors, long-retention data, and signatures that other systems depend on. Those are the places where migration failure creates the widest blast radius and the least recovery flexibility.
What to verify: Confirm that the inventory includes code, infrastructure, vendor services, and archives, not just obvious certificate stores. If a cryptographic dependency is only visible in a library default or a managed platform, treat it as inventory debt until it is explicitly owned.
What good looks like: Each cryptographic use has an owner, a business-lifetime classification, a sensitivity rating, and a migration dependency label. That lets teams sequence post-quantum work by business impact instead of by technical convenience.
Practitioner takeaway: The first real PQC decision is not which algorithm to adopt, but which cryptographic dependencies matter enough to move first.
Related resources from NHI Mgmt Group
- Should organisations prioritise discovery or algorithm support first in quantum-readiness planning?
- Why does post-quantum planning matter for IAM teams and not just PKI owners?
- Why do long-lived secrets and exposed systems need to be prioritised first in post-quantum planning?
- When should security teams move from planning post-quantum cryptography to active deployment?