Post-quantum readiness exposes the identity inventory gap

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Axiad's blog post: External TLS checks are only a starting point, not a full view of cryptographic risk.

Why it matters: IAM, NHI and infrastructure teams need to treat post-quantum readiness as an inventory and governance problem, because the hardest exposures sit in machine identities and long-lived cryptographic assets that external scans cannot fully see.

Context

Post-quantum readiness is not just a cryptography question. It is an identity inventory problem because the algorithms, certificates, keys and service credentials that need replacement are spread across human, machine and application environments.

Axiad's article argues that external TLS checks can show whether a public domain negotiates post-quantum key exchange, but that result does not expose the full cryptographic estate. The gap matters because migration work is driven by what teams can find, classify and govern across infrastructure and identity systems.

The practical issue is not whether quantum risk is distant. It is whether organisations can build a complete enough view of their cryptographic assets to plan replacement before the migration window collapses.

Key questions

Q: What should teams do first when public domains are not yet PQC ready?

A: Start with a baseline scan of the public domains that matter most to the business, then group the results by hosting platform, CDN or application owner. That gives you a prioritised starting point and shows where remediation depends on a third party rather than your own configuration.

Q: Why do post-quantum checks on public sites not prove full migration readiness?

A: Because they only measure one connection path. A public TLS result does not tell you whether internal PKI, service accounts, SSH keys, code signing certificates or embedded libraries still depend on classical cryptography. Full readiness requires inventory, ownership and lifecycle visibility across the broader estate.

Q: What are the signs that a PQC programme is too narrow?

A: If the programme tracks only external websites, reports only TLS versions and cannot name the owners of certificates or machine identities, it is too narrow. That usually means the organisation is measuring perimeter posture while leaving the highest-value internal crypto assets unmapped.

Q: How should IAM and infrastructure teams prioritise post-quantum migration?

A: Prioritise internet-facing assets, then move to the cryptographic assets with the longest replacement lead times and the weakest inventory. That sequencing reduces exposure quickly while avoiding the mistake of treating every system as equally urgent.

Technical breakdown

TLS handshake scanning and PQC negotiation

A TLS readiness scan tests what algorithms a public domain can negotiate during session setup. The server and client agree on key exchange, cipher suite and certificate parameters, so the result tells you whether the endpoint can use post-quantum key exchange today. That is useful, but it is still only a handshake view. It does not inspect private infrastructure, internal PKI, embedded libraries or machine credentials behind the domain. In other words, the scan is a signal about exposure at the edge, not a full cryptographic inventory.

Practical implication: Use TLS scanning as a baseline for public domains, not as evidence that the organisation is ready for PQC migration.

Why the crypto estate is bigger than public web traffic

The article correctly separates internet-facing TLS from the broader cryptographic estate. Certificates live in PKI systems, cloud services, HSMs and endpoints. Service accounts, SSH keys, API keys and code signing certificates also carry cryptographic dependencies, but they are rarely mapped with the same rigour as web-facing domains. This creates an inventory gap: teams can see the handshake on a website while missing the credentials and trust anchors that actually control internal systems and software supply paths. That gap is the real migration blocker.

Practical implication: Build a cryptographic inventory that includes certificates, service identities and code signing assets, not just internet-facing domains.

Hybrid post-quantum and classical TLS during transition

The article describes hybrid post-quantum TLS as the transition state that supports both PQC and classical key exchange. That matters because it preserves backward compatibility while giving capable clients quantum-resistant options. The model is pragmatic, but only for the outer connection layer. It does not solve certificate signature migration, internal PKI renewal, or the replacement of long-lived machine credentials. Organisations that mistake hybrid TLS for full readiness will under-scope the work and overstate their posture.

Practical implication: Treat hybrid TLS as a transition mechanism and keep the internal cryptographic migration plan separate.

Threat narrative

Attacker objective: The objective is to preserve access to currently protected communications and credentials until they can be decrypted or abused later.

1. Entry occurs when an adversary can observe public-facing encrypted traffic or identify long-lived cryptographic dependencies in externally exposed systems.
2. Credential harvesting continues through collection of encrypted sessions, certificates and long-lived machine identity material that may remain usable until PQC migration is complete.
3. Impact emerges later if today’s captured traffic or weak cryptographic inventory becomes decryptable or exploitable once quantum-capable attacks mature.

Breaches seen in the wild

• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.

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

NHI Mgmt Group analysis

Identity inventory, not just cryptography, is the real readiness gap: The article makes clear that PQC migration fails when teams can see public TLS posture but cannot see the full set of identities and assets that depend on classical cryptography. Certificates, service accounts, SSH keys and code signing live in different control planes, so the migration problem becomes one of discovery and ownership before it becomes one of algorithm replacement. Practitioners should treat cryptographic visibility as part of identity governance, not a separate technical project.

Public-facing PQC checks create a false sense of completeness: A domain that negotiates PQC key exchange is not the same thing as an organisation that is ready for post-quantum migration. That result only proves one path at the edge, while the hardest work sits in internal PKI, workload credentials and software signing dependencies. The implication is that programme leaders must separate edge compliance from estate readiness and avoid using the external result as a proxy for the whole environment.

Long-lived machine identities are the migration bottleneck: The article points to certificates, SSH keys and code signing as the assets most likely to slow down the transition because they are difficult to inventory and replace at enterprise scale. That is a classic NHI governance problem: assets persist longer than the teams that issued them can remember, and the cryptographic estate outlives the operational context that created it. Practitioners should focus on ownership, inventory and lifecycle control before they focus on algorithm selection.

Post-quantum readiness turns into a lifecycle issue once the asset count is known: NIST and CISA guidance matter here because the problem is no longer abstract research, it is operational sequencing. Once organisations know what they have, the real challenge becomes prioritisation across vendors, legacy systems and internal identity stores. The governance question is not whether to migrate, but which identity-bound cryptographic dependencies must move first to reduce long-tail exposure.

Named concept: identity cryptographic visibility gap: This article exposes the gap between what external TLS tools can see and what a programme must actually govern across certificates, service identities and application cryptography. The concept matters because PQC migration can look mature at the perimeter while remaining largely unmeasured inside the estate. Practitioners should use that distinction to challenge any readiness claim that stops at public-domain scanning.

What this signals

Identity cryptographic visibility gap: PQC migration becomes manageable only when teams can tie certificates, keys and service accounts to owners and lifecycle states. Without that mapping, the organisation can claim edge readiness while the real exposure remains hidden inside machine identity estates and legacy application paths.

The practical shift for programme owners is to move from point-in-time domain checks to inventory-led cryptographic governance. That means treating post-quantum readiness as part of IAM, PKI and machine identity lifecycle management rather than as a one-off technical validation exercise.

For practitioners

• Map the public-to-private crypto boundary Separate external TLS readiness from the internal cryptographic estate so that public scan results are never treated as full migration evidence.
• Inventory machine identities and code signing assets Build a register of service accounts, SSH keys, API keys, certificates and code signing certificates, then tie each item to an owner and lifecycle state.
• Test critical domains after every TLS change Run readiness scans on internet-facing domains after CDN, hosting or TLS configuration changes to confirm the negotiated key exchange actually changed.
• Prioritise high-exposure external assets first Sequence remediation for public portals, APIs and partner-facing services before long-tail internal systems, because exposed assets carry the highest immediate interception risk.
• Use scan outputs for board and vendor reporting Document the negotiated algorithms, TLS version and certificate details as objective evidence for governance discussions and third-party due diligence.

Key takeaways

• Public-domain PQC checks are useful, but they do not measure the full cryptographic estate that enterprises must actually migrate.
• The hardest readiness work sits in machine identities, certificates and code signing assets because those dependencies are distributed and often poorly inventoried.
• Organisations that cannot map cryptographic ownership and lifecycle state will struggle to sequence PQC migration before the transition window tightens.

Key terms

• 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.
• 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.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Hybrid Key Exchange: A transitional cryptographic setup that supports both classical and post-quantum key exchange during session negotiation. It reduces compatibility risk while improving resilience, but it is not a final endpoint because the surrounding certificate and identity estate may still rely on quantum-vulnerable components.

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.