Post-quantum cryptography readiness depends on cryptographic inventory

At a glance

What this is: This is an analysis of why post-quantum cryptography readiness depends on complete cryptographic inventory across identity and infrastructure estates.

Why it matters: It matters because PQC migration touches human IAM, machine identities, and lifecycle processes at once, so teams need visibility before they can govern risk, sequence remediation, or prove control effectiveness.

By the numbers:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Axiad’s analysis of PQC readiness and cryptographic inventory

Context

Post-quantum cryptography readiness is the programme discipline of finding every place an organisation relies on algorithms that will not survive a quantum computing shift. The problem is not abstract: most teams do not know where cryptography is deployed, which systems depend on it, or which identities are tied to it, so migration plans start with blind spots rather than scope.

For identity and access teams, that visibility gap spans certificates, keys, federated authentication, service accounts, and the systems that issue or consume them. The article’s central point is that PQC planning fails when cryptography is treated as a point tool issue instead of an identity and dependency mapping problem.

That starting position is common, not exceptional. Enterprises usually discover that their cryptographic estate is distributed across PKI, applications, network tooling, cloud services, and machine identities, which makes inventory the controlling step rather than a paperwork exercise.

Key questions

Q: How should organisations start PQC migration when they do not know where cryptography is used?

A: Start with a cryptographic inventory that maps algorithms, keys, certificates, and the identities that depend on them. Without that dependency map, migration planning becomes guesswork, and teams cannot estimate blast radius, prioritise vulnerable systems, or sequence changes safely. Inventory is the control that turns PQC from a theoretical deadline into an executable programme.

Q: Why does post-quantum readiness matter for machine identities as well as human IAM?

A: Machine identities often carry the certificates, API keys, and federated trust relationships that hold enterprise systems together. If those dependencies are invisible, PQC migration can break authentication or leave weak cryptography in place. Human IAM and machine identity governance need to be planned together because the trust fabric is shared.

Q: How do teams know whether crypto-agility is actually working?

A: Crypto-agility is working when algorithms can be changed without major re-engineering and the inventory shows which systems will be affected before the change is made. Signs of failure include unknown embedded libraries, orphaned certificates, and long manual remediation cycles. If the estate cannot absorb algorithm change predictably, the architecture is not agile enough.

Q: Who should own PQC migration across identity, infrastructure, and applications?

A: Ownership should sit with a cross-functional crypto centre of excellence that includes IAM, PKI, platform, application, and risk stakeholders. PQC migration crosses identity lifecycle, software engineering, and infrastructure management, so a single team cannot safely drive it alone. Shared ownership is essential, but accountability must be explicit.

Technical breakdown

Why cryptographic inventory is the first control gap in PQC migration

PQC migration begins with inventory because organisations cannot replace what they cannot enumerate. Cryptographic assets are scattered across certificate authorities, identity providers, applications, VPNs, cloud services, endpoints, and machine identities. Traditional tools see only fragments of that estate, so risk remains hidden even when individual systems appear compliant. The technical challenge is not simply finding RSA or ECC usage, but tracing where each key, certificate, or algorithm is embedded, who depends on it, and what breaks if it changes. Without that dependency map, the programme cannot estimate blast radius, prioritise remediation, or set credible timelines.

Practical implication: Build one cryptographic inventory that links algorithms, certificates, keys, and owning identities before approving any migration schedule.

How identity systems and cryptography become coupled in practice

Cryptography in enterprises is rarely isolated from identity. A certificate authenticates a user, device, or service; an API key identifies an application; federation protocols bind identity to trust decisions; and lifecycle events can leave stale credentials behind. That coupling matters for PQC because replacing an algorithm without understanding identity ownership creates operational breakage and orphaned trust. The article is right to stress that visibility must span human identities, machine identities, and the credentials that secure them. In practice, cryptographic change management is an identity governance problem with security implications, not a standalone crypto project.

Practical implication: Map each certificate or key to an accountable identity owner so renewal, replacement, and offboarding can be coordinated.

What crypto-agility changes for enterprise architecture

Crypto-agility means systems can swap algorithms without major re-engineering, but that only works when cryptographic dependencies are already known. New post-quantum algorithms will not behave like RSA or ECC, so organisations need to test performance, key sizes, and signature sizes before broad rollout. The architectural issue is that many applications, libraries, and devices were built on fixed assumptions about cryptographic primitives, which means migration will expose hidden coupling. Teams that treat PQC as a simple patch will underestimate the engineering effort and the need for staged validation across environments.

Practical implication: Test candidate post-quantum algorithms in representative environments before mandating replacement across all applications and endpoints.

NHI Mgmt Group analysis

Cryptographic inventory is the governance bottleneck, not algorithm selection: PQC programmes fail when leaders treat migration as a standards decision before they know the estate they are protecting. Cryptography is embedded across identity systems, applications, cloud services, and machine identities, so scope is the first hard problem. The implication is that PQC readiness should be run as an identity and dependency discovery programme, not as a narrow crypto upgrade.

Identity-linked cryptography needs ownership before replacement: A certificate, key, or API credential is only actionable when it is tied to a specific service, user, or platform owner. Without that relationship, remediation becomes a guessing game and renewal decisions can break authentication or leave stale trust in place. Practitioners should treat ownership attribution as the control that turns inventory into governance.

Crypto-agility will expose weak lifecycle discipline: The organisations most likely to struggle with PQC are the ones that already lack visibility into certificate lifecycles, secret storage, and renewal dependencies. Migration does not create those weaknesses, it reveals them at scale. The practitioner takeaway is that PQC readiness is a stress test for identity hygiene across the estate.

Machine identity is where quantum risk becomes operational: Human logins are visible and usually governed, but machine identities often sit across scripts, services, and integrations that no one reviews end to end. That makes them the first place hidden cryptography accumulates. The field should treat machine identity discovery as a prerequisite for quantum-safe trust, not a side task.

Cryptographic visibility: This is the specific failure mode the article exposes, where an organisation cannot answer where its cryptography lives, who depends on it, or what will break when it changes. That gap is not merely technical debt, it is a governance blind spot that invalidates any confident PQC timeline. The implication is that programmes must re-baseline from visible estate to managed migration before they can claim readiness.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why discovery and ownership mapping remain foundational governance tasks.
• As identity estates expand, revisit 52 NHI Breaches Analysis for the breach patterns that appear when hidden credentials and weak lifecycle control meet operational scale.

What this signals

The practical signal is that PQC readiness will increasingly be judged as an identity visibility problem, not a cryptography procurement problem. Teams that cannot map certificates, keys, and owning identities will not be able to prove migration progress, no matter how strong their policy language is. This is where the control plane and the trust plane finally converge.

Cryptographic dependency debt: enterprises have accumulated hidden trust relationships between identities, applications, and embedded algorithms that will become expensive to unwind under PQC pressure. The organisations that surface those dependencies early will control migration sequencing, while the rest will discover them during failure conditions.

With 97% of NHIs carrying excessive privileges in our research, the quantum transition should also trigger a privilege review for machine identities, not just a crypto inventory. If the same service accounts that hold weak trust also hold broad access, migration risk and blast radius compound together. Start with the identities that can break the most systems if they are left untouched.

For practitioners

• Build a cryptographic inventory with identity linkage Catalogue every certificate, key, algorithm, and embedded library, then tie each item to an application, service, or accountable owner. Include PKI, cloud KMS, code signing, VPN, federation, and machine identity use cases so the inventory reflects real operational dependencies.
• Prioritise high-value identity dependencies first Rank remediation by data sensitivity, privilege level, and business criticality rather than by discovery order. High-privilege machine identities, federation components, and long-lived certificates should move to the top because they concentrate trust and blast radius.
• Test crypto-agility before setting migration dates Validate post-quantum candidates in representative environments, focusing on key size, signature size, latency, and compatibility with older systems. Use pilot migrations to identify protocol breakage and implementation constraints before the broader rollout.
• Tie renewal and offboarding to lifecycle events Make certificate replacement, secret rotation, and credential revocation part of joiner-mover-leaver and system-change workflows. If an identity changes, the cryptographic trust attached to it should be reviewed at the same time, not left for a separate programme.

Key takeaways

• PQC readiness is blocked first by poor cryptographic visibility, not by lack of standards or urgency.
• Identity-linked certificates, keys, and machine credentials are the operational boundary that makes migration manageable or impossible.
• Teams that cannot inventory and prioritise cryptographic dependencies should treat PQC as a governance recovery programme before it becomes a technology migration.

Key terms

• Cryptographic inventory: A cryptographic inventory is the complete record of where an organisation uses algorithms, keys, certificates, and related trust dependencies. It is more than an asset list because it connects each cryptographic object to an application, identity, owner, and lifecycle state so migration can be planned safely.
• Crypto-agility: Crypto-agility is the ability to change cryptographic algorithms or parameters without redesigning the underlying system. In practice, it depends on modular architecture, clear dependency mapping, and testing across identity and application boundaries so changes do not break authentication or trust.
• Machine identity: A machine identity is a non-human identity used by software, services, or infrastructure to authenticate and exchange trust. It typically relies on credentials such as certificates, keys, or tokens, and it becomes a governance issue when ownership, rotation, or dependency mapping is unclear.
• Post-quantum cryptography: Post-quantum cryptography refers to encryption and signature schemes designed to resist attacks from quantum computers. For practitioners, the main challenge is not the new algorithms themselves but the effort required to discover, classify, and replace existing quantum-vulnerable cryptography across the enterprise.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or maturing governance across human and non-human identities, it is worth exploring.

This post draws on content published by Axiad: Risk Experts Say Quantum Will Break Today’s Encryption by 2029. Read the original.