Post-quantum cryptography readiness starts with discovery, not migration

At a glance

What this is: This is Commvault’s analysis of why post-quantum cryptography readiness is blocked first by cryptographic discovery and inventory, not by migration mechanics.

Why it matters: For IAM, NHI, and security teams, the practical issue is finding every cryptographic dependency before long-lived data, supplier systems, and policy timelines turn PQC into a reactive scramble.

Context

Post-quantum cryptography is the transition from today’s widely deployed public-key algorithms to quantum-resistant alternatives. The governance problem is not just algorithm replacement, but understanding where cryptography is embedded across applications, certificates, cloud services, APIs, code signing, and third-party platforms.

Commvault’s position is that organisations are still earlier in the journey than they think. The central blocker is cryptographic discovery, because without a complete inventory teams cannot judge exposure, prioritise dependencies, or sequence migration for data that must remain confidential for years.

Key questions

Q: How should organisations start migrating to post-quantum cryptography without replacing everything at once?

A: Start with the links that carry long-lived sensitive data and high-value administrative traffic, then use hybrid cryptography where classical and post-quantum methods can coexist. This lets teams gain quantum-safe exposure reduction while preserving compatibility. The key is to treat PQC as a staged architecture change, not a single cutover event.

Q: Why does Harvest Now, Decrypt Later change the PQC timeline?

A: Because the risk begins when encrypted data is collected, not when quantum decryption becomes practical. If sensitive information has a long retention life, it may still be valuable when future capabilities arrive, so delay increases exposure even if today’s encryption remains strong.

Q: What breaks in practice when organisations do not maintain a complete inventory of cryptographic assets?

A: Without a complete inventory, teams lose visibility into where certificates, keys, and other cryptographic assets live, who owns them, and when they expire. That creates blind spots in renewal, revocation, and policy enforcement. In practice, hidden assets are more likely to become expired, misused, or unmanaged, which can disrupt trust chains and weaken CMMC compliance.

Q: What is the difference between crypto agility and one-time migration?

A: One-time migration replaces a specific algorithm once. Crypto agility is the ability to change cryptographic dependencies repeatedly as standards, suppliers, and threats evolve. It is a programme capability, not a single project milestone.

Technical breakdown

Why cryptographic discovery comes before migration

PQC programmes fail if they start with replacement planning before inventory. Cryptography is not a single control surface, it is distributed across software, infrastructure, certificates, signing chains, APIs, and supplier integrations. That means the first technical task is not swapping algorithms, but identifying where public-key cryptography is implemented, how it is consumed, and which business services depend on it. Until those dependencies are mapped, migration plans are guesses rather than engineering decisions. The article’s core point is that the operational burden sits in discovery because organisations often cannot see the full blast radius of their cryptographic estate.

Practical implication: Build a cryptographic inventory before setting migration milestones.

Harvest Now, Decrypt Later changes the threat timeline

Harvest Now, Decrypt Later is an exposure model in which an attacker steals encrypted data today and stores it for future decryption. The risk begins at exfiltration, not at the moment quantum decryption becomes practical. That matters because data retention periods, archival systems, and regulated records can extend far beyond the current cryptographic lifespan of the algorithms protecting them. In other words, encrypted data is not automatically safe just because the present-day cipher is intact. For long-lived information, confidentiality now has to be judged across future capability, not only present-day resilience.

Practical implication: Classify long-retention data by future confidentiality exposure, not just current encryption state.

Crypto agility is a governance problem as much as an engineering one

Crypto agility means an organisation can change cryptographic algorithms and dependencies without a full programme reset. Technically, that requires abstractions, dependency visibility, and vendor coordination. Governance-wise, it requires prioritisation because not every system can move at once and not every asset has the same confidentiality horizon. The article frames PQC as a risk sequencing problem, not a one-time swap. That is important for identity and access teams because certificates, code signing, and federated trust chains often sit inside broader IAM and workload-identity dependencies. If those dependencies are not identified early, migration order becomes reactive.

Practical implication: Sequence PQC work by data sensitivity, dependency complexity, and supplier readiness.

NHI Mgmt Group analysis

Discovery debt is now the dominant PQC risk: Organisations are treating post-quantum planning as an algorithm decision when the harder problem is still inventory. Cryptography is embedded in applications, certificates, APIs, code signing, cloud services, and vendor platforms, so the first failure is blind scope. Until teams can see where cryptography lives, they cannot judge exposure or build a credible migration sequence.

Harvest Now, Decrypt Later turns data retention into a security control: The issue is not when quantum systems become practical, but whether the data stolen today is still valuable when they do. That shifts the control problem toward retention, classification, and dependency mapping. Long-lived records create a future confidentiality liability even when current encryption looks sound.

Crypto agility is the named capability that matters: The field does not need a one-time quantum project, it needs a repeatable ability to change cryptographic dependencies as standards evolve. That means the organisation must understand where algorithms are used, how replacements propagate, and which third parties control pieces of the trust chain. Practitioners should treat agility as a governance capability, not a product feature.

Third-party cryptography makes PQC an ecosystem issue: No enterprise controls every dependency that matters. Cloud providers, software partners, and upstream vendors all shape the cryptographic surface, which means procurement and vendor risk processes become part of quantum readiness. The practical implication is that cryptographic readiness must be managed across the supply chain, not just inside internal infrastructure.

Identity teams are already in the blast radius: Certificates, federated trust, and code-signing dependencies sit close to IAM, workload identity, and machine trust architecture. That makes PQC relevant to identity governance now, not later, because trust relationships and certificate lifecycles are where quantum transition work will surface first. Practitioners should expect PQC to land inside the identity programme before it is finished anywhere else.

What this signals

Crypto agility is becoming an identity-adjacent governance requirement: Certificate lifecycles, code-signing trust, and federated dependencies sit close to IAM and workload identity, so PQC planning should be folded into identity architecture rather than handled as a separate cryptography task. When trust chains change, access and assurance changes with them.

The practical turning point is inventory quality. Once organisations can see where cryptography is used and which data depends on it, prioritisation becomes a governance decision instead of a debate about quantum timelines.

For practitioners

• Map cryptographic dependencies first Inventory where public-key cryptography exists across applications, certificates, cloud services, APIs, code signing, and third-party platforms before choosing migration targets.
• Prioritise long-lived data classes Rank information by retention period, regulatory sensitivity, and business value so Harvest Now, Decrypt Later exposure is addressed before short-lived data paths.
• Build a crypto-agility roadmap Document which platforms can swap algorithms, which require refactoring, and which depend on suppliers so transition sequencing is realistic.
• Extend supplier reviews to cryptography Ask vendors and cloud providers what PQC planning they have in place, because third-party cryptographic readiness affects your own migration timing.
• Align identity and certificate owners Bring IAM, PKI, platform, and application owners into the same plan so trust chains, certificates, and federated dependencies are not changed in isolation.

Key takeaways

• Post-quantum risk is now a planning problem, not a distant research topic, because encrypted data can already be harvested for later decryption.
• The biggest blocker is incomplete cryptographic visibility across applications, certificates, APIs, code signing, cloud services, and third-party platforms.
• Organisations that build discovery and crypto agility first will have more room to sequence migration around data retention and supplier readiness.

Key terms

• Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. In practice, PQC is a migration problem as much as an algorithm problem because organisations must replace trust anchors, certificates, and secrets without breaking identity-dependent systems.
• Harvest now, decrypt later: An attacker strategy where encrypted traffic or stored data is collected today and decrypted later when better computing power becomes available. It matters to NHI governance because machine identities often protect the data paths and secrets most worth preserving over time.
• Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
• Cryptographic Inventory: A cryptographic inventory is a continuously updated record of keys, certificates, algorithms, libraries and trust anchors across an organisation. It is not a spreadsheet or one-time audit output. In practice, it links each asset to ownership, usage, lifecycle state and risk so teams can make remediation decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.