Quantum readiness depends on inventorying cryptographic assets first

At a glance

What this is: This analysis argues that post-quantum migration should begin with a Quantum Bill of Materials, because organisations cannot secure what they have not inventoried.

Why it matters: For IAM and security teams, the identity issue is not just crypto agility but control over the certificates, keys and trust chains that authenticate workloads, services and users.

Context

Quantum risk is not only about future decryption power. It is also about governance failure today, because cryptographic assets are often spread across cloud services, workloads, certificates and libraries without a complete inventory. That is why a Non-Human Identities lens matters here: the same control gap that hides service accounts also hides machine-authentication dependencies.

A Quantum Bill of Materials is a structured inventory of every cryptographic component in an environment, including key exchange methods, signing algorithms, certificates and the systems that use them. In practice, the problem is not the absence of standards, but the absence of operational visibility across complex infrastructure.

The article's starting point is typical for large environments: teams usually know the important algorithms in principle, but not where every instance lives in production.

Key questions

Q: How should security teams start a post-quantum migration program?

A: Start by inventorying where cryptography is actually used, then measure external exposure first. Public domains, certificates, SSH keys, and service accounts should be mapped to owners and replacement paths before standards deadlines force a rushed program. A quick scan is useful, but the real work is governance, sequencing, and lifecycle control.

Q: Why do vulnerable certificates remain a risk after key exchange upgrades?

A: Because key exchange and certificate signing protect different parts of the trust model. A modern key exchange can protect session establishment, but classical certificate signatures can still be forged if the signing algorithm is broken. That leaves server identity, workload identity and service trust exposed even when the transport layer appears modernised.

Q: What are the signs that an organisation is not ready for quantum-safe encryption migration?

A: A common warning sign is that the organisation cannot say where encryption is used, which assets depend on it, or which systems would break if algorithms changed. Another indicator is the absence of a migration roadmap, test plan, or maintenance cycle for cryptographic updates. If discovery is incomplete, readiness is still mostly aspirational.

Q: Which controls should govern cryptographic inventory and migration decisions?

A: Use a control model that ties discovery to lifecycle management, exception handling and dependency review. The governance requirement is not simply to adopt post-quantum algorithms, but to know where they are needed, where legacy dependencies remain and how to prove progress across the environment.

Technical breakdown

Why key exchange fails before symmetric encryption

The article correctly separates asymmetric and symmetric cryptography, which is the key to understanding quantum risk. Shor's Algorithm threatens RSA and elliptic-curve key exchange because it can recover private keys from the public mathematics those systems rely on. That is why session establishment is the first structural weakness, not bulk encryption. By contrast, Grover's Algorithm only reduces the effective strength of symmetric ciphers, which means AES-256 still retains substantial security margin. The operational lesson is that quantum migration must prioritise trust establishment and identity binding first, because once key exchange fails, the rest of the session trust chain collapses. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Practical implication: Prioritise discovery and replacement of vulnerable key exchange mechanisms before treating symmetric encryption as the main migration problem.

Why certificate signing is a separate control plane

Certificate signing and key exchange solve different problems. Key exchange protects how a session key is agreed, while certificate signatures prove who is trusted to speak for a system. A post-quantum key exchange alone does not stop impersonation if the certificate chain still uses classical signing algorithms that quantum computers could forge. That creates a distinct governance issue: identity assurance for servers, services and workloads remains vulnerable even after transport protection changes. In other words, cryptographic modernisation has to cover both confidentiality and authenticity, or the trust model remains incomplete.

Practical implication: Treat certificate-signing migration as a separate workstream from transport and key-exchange upgrades.

How a Quantum Bill of Materials changes governance

A QBOM is effectively the inventory layer for cryptographic governance. It maps where each algorithm, certificate, protocol and library is used, then translates that inventory into a readiness view against NIST post-quantum standards. That matters because many environments contain mixed states: some services can negotiate modern key exchange while still relying on classically signed certificates. Without a QBOM, teams tend to manage crypto as isolated exceptions rather than as a lifecycle problem. With it, they can tie inventory, dependency analysis and upgrade sequencing to a single operational view.

Practical implication: Build a cryptographic inventory that can be refreshed continuously, not just during annual review cycles.

Threat narrative

Attacker objective: The attacker aims to decrypt protected traffic and impersonate trusted systems by breaking the cryptographic assumptions that underpin authentication and key exchange.

1. Entry occurs through long-lived classical cryptography embedded across infrastructure, where RSA and ECDH remain present in session setup and trust chains.
2. Credential and trust material are exposed when an attacker can exploit quantum-capable decryption or signature forgery against those classical algorithms.
3. Impact follows as session confidentiality fails and certificate-based impersonation becomes possible across services, workloads and users.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cryptographic shadow IT is now a governance problem, not just a technical debt issue. The article's central insight is that teams cannot secure post-quantum migration until they can see every cryptographic dependency, including the hidden ones inside services, libraries and certificate chains. That is the same governance pattern NHIMG sees across identity programmes: if inventory is incomplete, control design is fictional. Practitioners should treat cryptographic discovery as a prerequisite control, not an administrative task.

Certificate identity is the real trust boundary in many enterprise environments. Once key exchange is modernised, the remaining weak point is often the identity proof embedded in certificate signing and validation. That is why this topic intersects with machine identity governance: certificates are not just transport artefacts, they are workload identities that establish trust between systems. Teams that do not manage certificate lifecycle as an identity control will inherit a false sense of post-quantum readiness.

Post-quantum readiness will be measured by lifecycle control, not algorithm awareness. Many organisations already know the names of the standards, but the operational challenge is sequencing, dependency mapping and exception management across heterogeneous infrastructure. The market will increasingly reward inventory-led approaches because they expose where modernisation is blocked by legacy systems, unmanaged libraries or weak certificate oversight. Practitioners should expect quantum readiness to become a continuous governance discipline, not a one-time upgrade project.

NIST alignment is necessary, but visibility is what makes it actionable. The article grounds its roadmap in NIST post-quantum standards, but standards alone do not tell a team where risk sits in production. The practical value comes from matching those standards to actual assets and dependencies, which is why a QBOM becomes the control layer that turns policy into execution. Security teams should use the standard as the target and the inventory as the proof of progress.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Machine Identity, PKI and Certificate Lifecycle Guide

What this signals

Quantum readiness will become a discovery discipline. The teams that move first will not be the ones with the most algorithm knowledge. They will be the ones that can continuously inventory cryptographic assets, tie them to business services and prove where classical dependencies still sit inside production trust paths.

Certificate lifecycle and machine identity will stay central even in a post-quantum programme. Quantum-safe transport is only one side of the problem. Organisations also need to govern the identities represented by certificates, because trust chains are the mechanism that will either preserve or collapse authenticity during migration.

Cryptographic shadow IT: unmanaged keys, certificates, libraries and protocol dependencies that sit outside a current inventory and create hidden migration risk. That hidden layer is what makes post-quantum transformation a control challenge, not just a standards exercise.

For practitioners

• Inventory cryptographic assets continuously Map every certificate, key exchange method, signing algorithm and cryptographic library across cloud, container and host environments so migration decisions are based on real exposure, not assumptions.
• Separate key exchange and signing remediation Track transport protection and certificate identity as distinct upgrade streams, because a system can support modern key exchange while still relying on classically signed certificates.
• Prioritise high-exposure trust chains Focus first on externally facing services, workload-to-workload trust paths and any certificate chains that support critical authentication flows, then sequence the rest by business dependency.
• Use NIST security levels to rank migration Assign algorithm families to the appropriate post-quantum security level so teams can compare risk consistently and avoid treating every cryptographic dependency as equally urgent.
• Test compatibility before production cutover Validate protocol compatibility, performance impact and fallback behaviour in staging before changing production trust chains, especially where certificate validation depends on legacy clients.

Key takeaways

• The article's core warning is that quantum migration starts with visibility, because organisations cannot protect cryptographic assets they have not inventoried.
• The practical exposure is not limited to encryption strength, since vulnerable key exchange and classically signed certificates create different but linked failure modes.
• A governed QBOM gives security teams a way to sequence migration, prove readiness and avoid treating post-quantum change as a purely theoretical exercise.

Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Guide to SPIFFE and SPIRE · Ultimate Guide to NHIs: What are Non-Human Identities · Cloud Security Guide

Key terms

• Quantum Bill of Materials: A Quantum Bill of Materials is an inventory of the cryptographic components an organisation uses, including algorithms, certificates, keys, libraries and protocols. It helps security teams identify where quantum exposure exists and which dependencies must be modernised first.
• 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.
• Cryptographic Shadow IT: Cryptographic shadow IT is the hidden use of keys, certificates, libraries or protocols that are not fully captured in inventory or governance processes. It creates migration blind spots because teams cannot protect, replace or retire what they cannot see.
• Certificate Signing Algorithm: A certificate signing algorithm is the cryptographic method used to prove that a certificate was issued by a trusted authority and has not been altered. If that algorithm is weak or outdated, certificate-based identity can be forged even when other protections remain intact.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It gives practitioners a shared control language for identity, trust and lifecycle risk across modern security programmes.