Post-quantum cryptography readiness starts with discovery, not migration

At a glance

What this is: This is an analysis of why post-quantum cryptography readiness now hinges on discovery, inventory, and crypto agility rather than waiting for quantum systems to mature.

Why it matters: IAM, PAM, and NHI teams should care because the same lifecycle discipline used for secrets, certificates, and workload identities will determine whether cryptographic dependencies can be found, prioritised, and replaced before they become exposure points.

👉 Read Commvault's STRIVE episode on post-quantum cryptography readiness

Context

Post-quantum cryptography creates an identity and access governance problem because cryptography is embedded across applications, certificates, cloud services, APIs, code signing, and third-party platforms. The first failure is not algorithm choice, it is not knowing where cryptography exists or which systems depend on it.

For IAM and NHI practitioners, this is a lifecycle issue as much as a technical one. Cryptographic assets behave like other non-human dependencies: they are distributed, inherited, and easy to lose track of unless discovery and ownership are explicit.

The article’s core argument is that preparation has to start before quantum certainty arrives. That is typical of large identity and security transitions: the organisations that wait for a clean trigger usually discover their inventory problem too late.

Key questions

Q: How should organisations start preparing for post-quantum cryptography?

A: Start with discovery, not migration. Organisations need an inventory of where cryptography exists, which systems depend on it, who owns each dependency, and which data has a long confidentiality horizon. Once that baseline is clear, teams can prioritise the highest-risk assets and build a sequenced transition plan instead of guessing where to begin.

Q: Why is harvest now, decrypt later a current risk?

A: Because the attacker does not need quantum capability today to create value from stolen ciphertext. If encrypted data can be exfiltrated and stored now, it may become readable later when quantum techniques mature. That means the risk window already exists for long-lived sensitive information, especially where retention periods are measured in years.

Q: What gets organisations stuck in PQC planning?

A: The biggest blocker is incomplete visibility into cryptographic dependencies. Many enterprises do not know where cryptography is used across applications, certificates, cloud services, APIs, code signing, and supplier environments. Without that map, teams cannot judge what to migrate first or what business services would be affected by change.

Q: Who should own PQC readiness in an enterprise?

A: PQC readiness is an identity, infrastructure, and risk governance issue, so ownership should be shared across security architecture, platform teams, application owners, and third-party risk. If no one is assigned responsibility for discovery, prioritisation, and migration sequencing, the programme stays theoretical and the organisation carries avoidable exposure.

Technical breakdown

Why cryptographic inventory is the first control gap

Post-quantum readiness begins with discovery because most organisations cannot replace what they cannot enumerate. Cryptography is not confined to one vault or one application layer. It appears in certificates, service integrations, APIs, code signing, cloud services, and external platforms, which means the inventory problem crosses infrastructure, application, and identity ownership boundaries. The technical issue is not only asset count, but also dependency mapping: which systems use which algorithms, where key material resides, and which business services would fail if a dependency changed. Without that map, PQC migration is guesswork.

Practical implication: Build an authoritative cryptographic inventory that ties each dependency to an owner, system, and business process.

What crypto agility really means for identity and security teams

Crypto agility is the ability to change cryptographic algorithms, implementations, or trust dependencies without redesigning the environment from scratch. In practice, this matters because a PQC migration will not be a single switch flip. Organisations will need to operate mixed cryptographic states for a period, with legacy and post-quantum methods coexisting across internal systems and external partners. That creates governance pressure on certificates, token flows, signing chains, and vendor integrations. If the environment cannot tolerate cryptographic change, the migration becomes a business continuity problem rather than a security project.

Practical implication: Treat algorithm change as a controlled lifecycle event and test whether critical systems can absorb cryptographic replacement without service disruption.

Why harvest now, decrypt later changes the retention model

Harvest now, decrypt later attacks break the old assumption that encrypted data is safe simply because it is unreadable today. The attacker’s objective is persistence of the ciphertext, not immediate decryption. That makes long-retention data, such as intellectual property, regulated records, and government information, more exposed than short-lived operational data. The risk also extends to data handled by suppliers and hosted services, because once encrypted material leaves the environment, its future exposure is no longer purely under internal control. PQC planning therefore intersects with data classification, retention policy, and third-party dependency management.

Practical implication: Prioritise migration for data and workloads whose confidentiality horizon extends beyond the expected lifetime of current cryptography.

NHI Mgmt Group analysis

Crypto inventory debt is now the limiting factor in PQC readiness. The article is right to put discovery ahead of replacement because most enterprises do not yet know where cryptography is embedded, much less who owns each dependency. That makes post-quantum planning an inventory and governance exercise before it is an algorithm exercise. Practitioners should treat unknown cryptographic dependencies as an active risk surface, not a documentation gap.

Harvest now, decrypt later is a retention-policy problem disguised as a cryptography problem. The attack only works against data that remains valuable long enough to be decrypted later, which means long-lived sensitive data becomes the priority set. That shifts emphasis from blanket migration to retention-aware prioritisation, where confidentiality horizon matters as much as technical exposure. Practitioners should align PQC planning with data classification and retention ownership.

Crypto agility is becoming a core resilience requirement for identity-adjacent systems. Certificates, signing chains, API trust paths, and vendor integrations are all part of the cryptographic dependency graph. If those components cannot be changed without major service redesign, the organisation has already accumulated cryptographic debt. Practitioners should evaluate whether their identity and platform layers can survive algorithm transition without breaking trust relationships.

Third-party cryptography extends PQC governance beyond the enterprise boundary. The article correctly notes that suppliers, cloud providers, and software partners shape the readiness timeline as much as internal systems do. That means procurement, assurance, and lifecycle governance now belong in the same conversation as technical migration planning. Practitioners should treat ecosystem readiness as part of their own exposure model.

Post-quantum readiness will reward programmes that can sequence change, not just approve it. The organisations that start now gain options to phase migration around risk, dependency, and operational tolerance. Those that wait will inherit a compressed decision window with fewer safe paths. Practitioners should build a sequenced roadmap that starts with discovery, then prioritisation, then controlled transition.

From our research:

• 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to The 2024 State of Secrets Management Survey.
• Only 44% of organisations are currently using a dedicated secrets management system, which shows how often discovery still precedes disciplined control.
• For a broader lifecycle lens, read Ultimate Guide to NHIs , Static vs Dynamic Secrets for how long-lived credentials create the same governance debt that cryptographic inventory now exposes.

What this signals

Post-quantum readiness will strain programmes that still treat cryptography as an implementation detail rather than a governed dependency. The practical consequence is that certificate, key, and algorithm ownership will need to be visible in the same way service account ownership is visible today.

Cryptographic dependency debt: the environments most at risk are not the ones with the newest cryptography, but the ones with the least complete map of where it is used. That means the next control conversation is about inventory quality, supplier assurance, and retirement timing, not algorithm theory.

With 62% of secrets duplicated and stored in multiple locations, per The 2025 State of NHIs and Secrets in Cybersecurity, the same sprawl problem will surface in cryptographic assets unless ownership and lifecycle discipline are tightened now.

For practitioners

• Create a cryptographic inventory across all systems Map certificates, APIs, code signing, cloud services, and third-party platforms to owners, dependencies, and renewal dates so PQC work starts from facts rather than assumptions.
• Prioritise long-lived sensitive data first Classify intellectual property, regulated records, and other information with long retention horizons before deciding which systems need earlier PQC migration.
• Test crypto agility in critical trust paths Validate whether certificates, signing flows, and identity integrations can change algorithms without breaking authentication or service availability.
• Include suppliers in the readiness roadmap Require vendors and cloud providers to disclose their PQC planning, migration assumptions, and dependency timelines before they become blockers.
• Tie PQC planning to retention governance Use data retention policy to decide which encrypted assets must be protected farthest into the future and therefore need earlier attention.

Key takeaways

• Post-quantum cryptography is now a governance problem because discovery, ownership, and prioritisation matter before algorithm migration does.
• Harvest now, decrypt later turns long-lived encrypted data into an immediate planning concern, especially where retention horizons extend for years.
• Organisations that can map cryptographic dependencies and prove crypto agility will have far more options when transition timelines tighten.

Key terms

• Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from quantum computers. In practice, PQC is less about replacing every control immediately and more about planning a controlled transition for the data, systems, and trust relationships that must stay confidential for years.
• Crypto Agility: The ability to change cryptographic algorithms, implementations, or trust dependencies without rebuilding the environment. For practitioners, crypto agility is a resilience property: if systems cannot tolerate algorithm change, migration becomes a business continuity problem instead of a security change.
• Cryptographic Inventory: A structured record of where cryptography is used, who owns each dependency, and what business service it supports. It is the starting point for PQC planning because organisations cannot prioritise migration, assess exposure, or sequence change without knowing where cryptographic controls exist.
• Harvest Now, Decrypt Later: An attack pattern where adversaries collect encrypted data today and store it for future decryption when quantum capability improves. The key governance issue is retention horizon, because only data that remains valuable long enough is exposed to this delayed confidentiality failure.

What's in the full article

Commvault's full episode covers the operational detail this post intentionally leaves for the source:

• The discussion of how to start a PQC programme without waiting for certainty on Q-Day.
• The segment on cryptographic inventory scope across applications, certificates, cloud services, and APIs.
• The explanation of crypto agility and why algorithm change has to be planned as a lifecycle event.
• The episode’s treatment of supplier readiness and how third-party dependencies affect migration timing.

👉 Commvault's full episode covers the discovery challenge, crypto agility, and supply chain implications in more detail.

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 identity security programme, it is worth exploring.