Post-quantum cryptography exposes the scale of cryptographic debt

At a glance

What this is: This is DigiCert's analysis of why post-quantum cryptography is becoming a governance problem, with cryptographic inventory and ownership emerging as the main readiness gap.

Why it matters: It matters because the same visibility, lifecycle, and accountability failures that complicate NHI, autonomous, and human identity programmes also undermine cryptographic migration.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read DigiCert's analysis of cryptographic debt and post-quantum readiness

Context

Post-quantum cryptography readiness is really a visibility problem before it is a migration problem. Most organisations know they use cryptography, but far fewer can map where it lives, who owns it, and which systems depend on long-lived keys, certificates, and embedded secrets. That is why cryptographic debt has become the central governance issue, not a future algorithm choice.

For identity and access teams, the lesson is familiar. Anything that cannot be inventoried, attributed, rotated, or retired at scale becomes an operational liability, whether it is an API key, a service account, or a certificate chain. The article's core claim is that PQC work exposes the same structural weaknesses that already trouble identity governance programmes.

Key questions

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

A: Start with discovery, not algorithms. Organisations should inventory where cryptography exists, who owns each dependency, and which systems cannot tolerate change without disruption. That gives security and engineering teams a realistic migration sequence and prevents PQC planning from becoming a theoretical exercise divorced from operational reality.

Q: Why do long-lived certificates and embedded secrets create PQC risk?

A: Long-lived certificates and embedded secrets create risk because they are difficult to find, update, and retire at scale. If an organisation cannot rotate or replace them cleanly, post-quantum migration becomes a slow, high-friction programme that extends exposure and increases the chance of missed dependencies.

Q: What breaks when cryptography is not documented across the enterprise?

A: What breaks is decision-making. Without documentation, teams cannot tell which systems depend on older algorithms, where ownership sits, or which assets are upgradeable. That leads to guesswork, inconsistent priorities, and a migration plan that stalls when it reaches legacy platforms or vendor-managed dependencies.

Q: Who should own PQC migration in a large organisation?

A: PQC migration should have explicit cross-functional ownership, typically spanning security, infrastructure, application teams, and vendor management. The reason is simple: cryptographic change crosses technical and operational boundaries, so accountability has to be visible if the work is going to progress beyond assessment into execution.

Technical breakdown

Why crypto inventory is the first control for PQC readiness

Crypto inventory means documenting where cryptography exists, which algorithms are used, what assets depend on them, and who owns the change path. In practice, this is closer to configuration governance than to a one-time asset list. Without that map, teams cannot tell which certificates are long-lived, which systems are tied to deprecated libraries, or where asymmetric keys are embedded in applications and devices. PQC planning therefore begins with discovery, not algorithm selection.

Practical implication: build a cryptographic inventory that ties each key, certificate, and algorithm to a named owner and system dependency.

What CBOMs change in cryptographic governance

A Cryptographic Bill of Materials, or CBOM, is a structured record of the cryptographic components a system uses. It gives teams a shared reference for algorithms, key storage, certificate handling, and configuration choices across environments. That matters because cryptography is often buried in cloud services, DevOps pipelines, identity systems, IoT, and legacy platforms where visibility is poor. CBOMs make the migration problem concrete enough to prioritise, rather than leaving it as a broad risk statement.

Practical implication: use CBOMs to identify which systems are upgradeable, which are constrained, and where crypto-agility work should start.

How cryptographic technical debt slows migration

Cryptographic technical debt is the accumulation of design and implementation choices that make change expensive later. Examples include hard-coded keys that cannot be rotated, vendor dependencies with unclear upgrade paths, and older libraries that were never built for algorithm agility. This debt does not just increase PQC effort. It turns migration into a multi-team programme because the problem sits across application code, infrastructure, vendors, and operational ownership boundaries.

Practical implication: classify legacy cryptography blockers by ownership and replaceability before setting PQC timelines.

NHI Mgmt Group analysis

Cryptographic debt is a governance failure before it is a quantum problem. The article correctly shifts attention away from abstract quantum timelines and toward the inventory and ownership gaps that already exist. Teams do not fail at PQC because they picked the wrong future algorithm; they fail because they never built a trustworthy map of where cryptography lives today. The practitioner conclusion is that readiness starts with governance structure, not migration theatre.

CBOMs are the missing control plane for cryptographic change. The value of a CBOM is not the document itself but the fact that it gives security, engineering, and operations a common source of truth. That matters in environments where cryptography is embedded in APIs, identity systems, DevOps pipelines, mobile platforms, and operational technology. The practitioner conclusion is that migration planning without structured dependency visibility will remain guesswork.

Hard-coded keys and legacy libraries are the real PQC blockers. The article makes clear that the hardest work sits in technical debt, not in standards tracking. Systems that cannot rotate keys, absorb library changes, or tolerate algorithm swaps will dictate the migration schedule regardless of policy urgency. The practitioner conclusion is to identify non-agile cryptography as a programme constraint, not a future optimisation target.

Ownership is the control that turns PQC from intention into execution. The Department of War guidance cited in the article matters because it recognises that cryptographic change crosses security, IT, engineering, and vendor boundaries. Without explicit ownership, remediation gets diffused across teams and no one carries the backlog. The practitioner conclusion is that PQC readiness should be managed as an ongoing operating capability with named accountability.

Identity teams should read PQC as a trust-governance warning, not a niche cryptography update. The same enterprises that struggle to inventory secrets, lifecycle service accounts, and retire stale credentials will struggle to retire obsolete cryptography. This is why post-quantum planning belongs alongside identity governance, PAM, and secrets management rather than in a separate technical silo. The practitioner conclusion is to treat crypto-agility as part of broader trust lifecycle management.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why governance programmes fail when ownership and inventory are weak.
• Read the Ultimate Guide to NHIs for the control patterns that make inventory, rotation, and offboarding operational rather than theoretical.

What this signals

Cryptographic agility will increasingly be judged like identity agility. Teams that cannot inventory, rotate, or retire cryptographic assets will find PQC projects colliding with the same operational blind spots that affect NHI governance. With NHIs outnumbering human identities by 25x to 50x in modern enterprises, control-plane discipline is already a prerequisite for scale.

The likely programme shift is from isolated cryptography tasks to cross-domain trust lifecycle management. That means security leaders should expect PQC work to pull in secrets management, certificate lifecycle, vendor dependency tracking, and exception handling as one operating model.

A useful concept here is cryptographic debt visibility: if you cannot see where cryptography is used, you cannot know which systems can move first. The organisations that solve visibility first will treat PQC as an achievable migration, not an indefinite risk discussion.

For practitioners

• Build a cryptographic inventory with named ownership Catalogue where asymmetric keys, certificates, embedded secrets, and algorithm dependencies exist across applications, platforms, and third-party services. Assign a business and technical owner to each item so remediation can be prioritised and tracked.
• Create a CBOM for critical systems first Start with systems that carry the most business risk, then document algorithms in use, key storage locations, certificate lifecycles, and upgrade constraints. Use the CBOM as the baseline for PQC sequencing and dependency mapping.
• Separate agile from non-agile cryptography Classify systems that can tolerate algorithm changes from those bound to legacy libraries, embedded certificates, or vendor-locked dependencies. Treat the non-agile set as a migration bottleneck that needs exception handling and programme-level planning.
• Tie PQC readiness to identity and secrets governance Review the same teams, controls, and lifecycle processes that already manage service accounts, secrets, and certificates. Reuse ownership, rotation, and offboarding disciplines so cryptographic change is governed as part of trust lifecycle management.

Key takeaways

• Post-quantum cryptography is exposing a wider governance problem: organisations often cannot see, own, or change the cryptography already embedded in their environments.
• The evidence points to scale and complexity, not just future quantum risk, because inventory gaps and technical debt make migration a multi-year operational effort.
• The practical response is to build inventory, define ownership, and use CBOMs to separate agile systems from legacy constraints before setting migration timelines.

Key terms

• Cryptographic Debt: Cryptographic debt is the accumulated cost of old design choices that make modernising encryption, keys, certificates, or libraries difficult. It shows up when hard-coded dependencies, legacy algorithms, or undocumented ownership turn a security upgrade into a long-running operational programme.
• Cryptographic Bill of Materials: A Cryptographic Bill of Materials is a structured record of the cryptographic components used by a system. It lists algorithms, key and certificate dependencies, storage locations, and configuration details so teams can assess upgradeability and prioritise post-quantum migration work.
• Crypto-agility: Crypto-agility is the ability to change cryptographic algorithms, keys, or configurations without major disruption. In practice, it depends on clean dependencies, lifecycle ownership, and systems that were built to tolerate cryptographic change rather than resist it.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: What the Dept. Of War’s PQC Push Reveals about Cryptographic Debt. Read the original.