Post-quantum readiness exposes the identity inventory gap

At a glance

What this is: This is a practitioner analysis of a free PQC readiness tester, with the key finding that external TLS posture is only the first, narrow layer of quantum migration risk.

Why it matters: It matters because IAM, PAM, and NHI teams will own much of the cryptographic inventory, lifecycle, and dependency mapping required to move from surface checks to real post-quantum readiness.

By the numbers:

• Gartner's research projects that quantum computing will render conventional asymmetric cryptography unsafe by approximately 2029 and fully breakable by 2034.

👉 Read Axiad's analysis of post-quantum readiness for internet-facing domains

Context

Post-quantum cryptography readiness is the work of finding where classical cryptography lives, which identities depend on it, and how long it will take to replace it. The first problem is visibility, because the algorithms that protect domains, certificates, VPNs, SSH keys, and code signing are spread across systems that identity teams do not always inventory cleanly.

Axiad's tester addresses the external edge of that problem by checking whether a public domain can negotiate quantum-resistant TLS. That is useful as a starting point, but it does not change the underlying migration burden: enterprise crypto inventory, certificate lifecycle control, and machine identity governance still determine whether readiness is real or merely visible.

For IAM practitioners, the article is a reminder that quantum risk is not just a cryptography issue. It is an identity governance issue because the replacement work sits inside certificate estates, service accounts, secret sprawl, and offboarding processes that already struggle with visibility and ownership.

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 internet-facing domains get prioritized in PQC planning?

A: Internet-facing domains are prioritized because they are exposed, measurable, and often easier to upgrade than internal cryptographic dependencies. They provide an early, visible win and reduce harvest-now-decrypt-later exposure, but they do not solve the underlying inventory problem. The edge is only the first tier of the migration sequence.

Q: What breaks when teams treat a PQC scan as full readiness?

A: What breaks is the assumption that external TLS equals enterprise cryptographic readiness. Internal PKI, machine identities, application-layer cryptography, and legacy systems may still be quantum-vulnerable even when public domains negotiate post-quantum key exchange. The scan is a signal, not a completion certificate.

Q: Who is accountable for quantum readiness in identity programs?

A: Accountability sits with the teams that own certificates, machine identities, infrastructure, and cryptographic dependencies. In practice that usually spans IAM, platform engineering, security architecture, and compliance. The best programs assign named owners to each crypto asset and require evidence of migration progress, not just intent.

Technical breakdown

TLS handshake analysis and PQC negotiation

The tester runs a real-time TLS handshake against a public domain and inspects the cryptographic choices negotiated during session setup. In practical terms, it checks whether TLS 1.3 is available and whether post-quantum key exchange appears in the offered groups. That matters because the handshake is where client and server agree on protection for the connection, and the result tells you whether the external edge can already use quantum-resistant methods. The scan is narrow by design. It measures one slice of the cryptographic surface, not the whole enterprise posture.

Practical implication: use external handshake results as an entry point, not as proof of full post-quantum readiness.

Hybrid TLS and transitional cryptography

A hybrid posture supports both classical and post-quantum key exchange groups at the same time. That approach reduces transition risk because modern clients can use quantum-resistant methods while older clients keep working. It is a migration pattern, not a final-state architecture. The value is continuity during a long replacement cycle, especially where public services must serve diverse client populations. Hybrid support also shows why PQC migration is operationally harder than simple policy change: compatibility, rollout sequencing, and edge infrastructure all matter.

Practical implication: validate hybrid support on critical domains before pushing wider cryptographic changes.

Why public-facing domains are only the first phase

Internet-facing domains are easy to reach, easy to measure, and often the quickest assets to upgrade. But the article correctly separates external TLS from the broader cryptographic estate, which includes certificates in PKI systems, machine identities, code signing, and internal services. Those assets are harder to discover and slower to replace, so they usually become the real bottleneck. From an identity perspective, this is where machine identity visibility becomes a prerequisite for PQC planning. Without inventory, you cannot set migration order or prove progress.

Practical implication: pair public-domain scans with a cryptographic inventory of internal identities, certificates, and keys.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Quantum readiness is an identity inventory problem before it is a cryptography problem. The article makes clear that public TLS can be checked quickly, but the real migration challenge sits inside the credential and certificate estate. That estate includes machine identities, code signing, SSH keys, and service accounts that are rarely mapped with enough precision. Practitioners should read this as a governance failure mode, not just a technical migration burden.

Post-quantum migration exposes the same visibility gaps that already weaken NHI governance. The article's own distinction between internet-facing domains and internal cryptographic assets mirrors the gap between what security teams can see externally and what they can actually govern internally. When certificates, keys, and workload identities are distributed across platforms, inventory becomes the control plane. Teams that cannot enumerate those assets will not be able to sequence remediation or prove readiness.

Cryptographic lifespan is now an access-lifecycle issue. Certificates, keys, and machine identities do not become risky at the moment a standard changes. They become risky when their ownership, validity, and replacement path are unclear. That makes lifecycle governance central to PQC programs, because the hardest part is not the handshake test but the offboarding, renewal, and dependency mapping behind it.

Identity visibility across human, machine, and crypto assets is the named capability PQC programmes now need. The article points to a unified view that correlates cryptographic artifacts with the identities and services they secure. That framing is more useful than treating PQC as a standalone cryptography project. Practitioners should treat quantum readiness as part of identity governance architecture, not a separate security initiative.

Readiness dashboards can accelerate action, but they can also create false confidence. A clean external-domain result is a useful milestone, yet it says little about the long-lived credentials and legacy systems that typically carry the highest remediation cost. The lesson is that visible progress at the edge does not equal programme completeness. Teams should avoid equating a few compliant domains with a finished migration.

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 cryptographic inventory work so often stalls before migration begins.
• For the broader breach and exposure pattern behind machine identity risk, see 52 NHI Breaches Analysis for the failure modes that repeat across identity estates.

What this signals

Identity visibility will become the pacing item for PQC programmes. The organisations that can enumerate certificates, keys, and machine identities will move first, while everyone else will keep running proof-of-concept scans without a credible migration sequence. That is why crypto readiness is converging with NHI governance, not replacing it.

The most useful next step is to treat post-quantum work as a dependency map, not a tool rollout. If a service account, certificate, or signing key cannot be tied to an owner and a rotation path, it is already a migration risk even if its external domain looks compliant.

Quantum readiness is becoming a governance signal, not a technical checkbox. Teams that can prove inventory, ownership, and replacement sequencing will have better board and auditor conversations than teams that only show external test results. That distinction will matter more as standards and customer requirements tighten.

For practitioners

• Scan critical public domains first Use the external TLS check to establish a baseline on customer portals, APIs, and partner endpoints, then compare subdomains rather than assuming the main site represents the whole estate.
• Build a cryptographic inventory beyond the edge Map certificates, SSH keys, code signing assets, service accounts, and API dependencies so the PQC programme has an asset list to work from. Link each item to an owner, rotation path, and replacement priority.
• Separate hybrid support from final-state readiness Treat hybrid TLS negotiation as a transitional control. Confirm that the domain can support both classical and post-quantum groups while maintaining compatibility, but do not stop the programme there.
• Tie PQC reporting to governance evidence Document what was scanned, what is still outside the scan, and which internal identities remain unassessed. That evidence helps with board reporting, vendor due diligence, and regulatory conversations.

Key takeaways

• The article shows that post-quantum readiness starts with visibility into public domains, but the real migration challenge sits in internal identity and certificate estates.
• The scale of the problem is driven by long replacement cycles, harvest-now-decrypt-later risk, and standards that are already moving from guidance to mandate.
• The control that changes the outcome is cryptographic inventory tied to ownership and lifecycle, not a one-time external scan.

Key terms

• Post-Quantum Cryptography: Cryptographic algorithms designed to resist attacks from both classical computers and sufficiently capable quantum computers. In practice, PQC is a migration program as much as a technical standard, because enterprise systems must replace embedded algorithms across certificates, transport, signing, and identity dependencies.
• 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.
• Cryptographic Inventory: A structured record of where cryptographic assets live, who owns them, what they secure, and how they are rotated or replaced. For PQC work, inventory is the control that turns an abstract threat into a sequenced migration plan across human, machine, and application identities.
• Harvest Now, Decrypt Later: An attack pattern in which adversaries capture encrypted traffic or data today with the expectation that future computing capabilities will make decryption possible. It matters most for long-lived confidentiality, because the value of the collected data can outlast the security of the algorithms protecting it.

Deepen your knowledge

Post-quantum readiness and cryptographic inventory are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a migration plan from a similar starting point, it is worth exploring.

This post draws on content published by Axiad: Is Your Domain Ready for the Post-Quantum Era? Check Now Quantify Your Identity Risk in Minutes. Read the original.