Public-facing domain PQC readiness exposes the deeper crypto gap

At a glance

What this is: This is Axiad’s analysis of a free PQC readiness tester for public-facing domains and the limits of treating TLS readiness as the whole quantum migration story.

Why it matters: It matters because IAM, NHI, and infrastructure teams need to distinguish between visible TLS posture and the harder work of inventorying machine identities, certificates, and cryptographic dependencies across the enterprise.

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 public-domain PQC readiness and cryptographic inventory

Context

Post-quantum cryptography readiness is a governance problem before it is a cryptography problem. Public-facing domains may be easy to test, but the underlying risk sits across TLS, certificates, machine identities, and long-lived application dependencies that most programmes do not inventory cleanly today.

The primary challenge for identity teams is that quantum exposure spans both external-facing trust paths and the internal identity estate. That makes PQC migration part of identity governance, not just a network or platform upgrade, because the systems most likely to break are often the ones that security teams can least see end to end.

Key questions

Q: How should security teams prioritise PQC migration for internet-facing systems?

A: Start with public domains, APIs, and partner-facing services because they are easiest to observe and most exposed to interception. Use TLS handshake results to identify where post-quantum key exchange is already possible, then rank remediation by exposure, replacement effort, and the business value of the data protected.

Q: Why do machine identities make PQC migration harder than TLS scanning suggests?

A: Machine identities often sit outside the tidy certificate view that external scans provide. Service accounts, API keys, SSH keys, and code signing certificates can persist for years, span multiple owners, and depend on legacy libraries or vendor systems that are difficult to replace quickly.

Q: How do organisations know whether a domain is truly PQC ready?

A: A domain is not fully ready just because it negotiates a post-quantum key exchange at the edge. Teams also need to confirm certificate strategy, internal cryptographic dependencies, and the identity lifecycle for any machine credentials tied to that service.

Q: Who should own post-quantum cryptography readiness across the enterprise?

A: Ownership should sit across identity, infrastructure, application, and risk functions, with a named lifecycle owner for certificates and machine credentials. PQC readiness fails when it is treated as a one-team project, because the exposure lives across multiple control planes.

Technical breakdown

How PQC readiness is measured in public TLS handshakes

A public-domain PQC readiness test works by observing the TLS handshake a browser negotiates with a server. The server advertises supported key exchange groups, and the client selects from that set. A PQC-capable result means the server can negotiate TLS 1.3 with at least one post-quantum key exchange algorithm, while a non-compliant result means only classical algorithms are available or TLS 1.3 is absent. This is a useful signal because it reflects what external users and adversaries can actually see on the wire, but it does not inspect internal PKI, application-layer cryptography, or non-TLS credentials.

Practical implication: Use external TLS scanning as a baseline control, not as proof of full quantum readiness.

Why internet-facing assets are first in the PQC migration queue

Internet-facing domains are prioritised because exposure is high and interception is easy. Traffic to public APIs, portals, and partner integrations can be harvested at scale, creating classic harvest-now-decrypt-later exposure. That makes these domains the most measurable early wins in a PQC programme, especially where CDN and cloud providers already support hybrid post-quantum negotiation. But the scoring changes when you consider cost to fix and replacement timelines, because the hardest crypto migrations are usually not the public ones. They are the internal, long-lived, and poorly inventoried identity credentials.

Practical implication: Treat public TLS as the first migration wave, then move immediately to the internal crypto estate.

What a complete cryptographic inventory has to include

A complete inventory must go beyond certificates on public endpoints. It needs to cover machine identities such as service accounts, API keys, SSH keys, code signing certificates, cloud key stores, and embedded cryptographic libraries inside applications. These are often the assets with the longest lifetimes and the weakest replacement visibility, which is why they create the most difficult remediation paths. The distinction matters operationally: a TLS scan tells you what a browser can negotiate, while inventory tells you what still depends on quantum-vulnerable primitives anywhere in the identity stack.

Practical implication: Build a crypto inventory that correlates identities, credentials, and algorithms before setting remediation priority.

NHI Mgmt Group analysis

Public-domain PQC testing solves visibility at the edge, not cryptographic readiness across the estate. A browser-level handshake scan tells teams whether an external domain can negotiate post-quantum key exchange, but it says nothing about internal PKI, embedded libraries, or machine identity credentials. That is a visibility gain, not a governance conclusion. The practical implication is that teams must stop treating the external scan result as a programme milestone.

Hybrid PQC posture is a transition control, not an end state. Supporting both classical and post-quantum key exchange preserves compatibility while reducing exposure, which makes sense during migration. But hybrid support still leaves certificate ecosystems, application code, and internal identity credentials on separate timelines. Practitioners should view hybrid negotiation as a bridge that buys time, not as evidence that the cryptographic estate is modernised.

Cryptographic inventory is now an identity discipline, because machine credentials carry the longest tail of quantum exposure. Service accounts, API keys, SSH keys, and code signing certificates are the assets most likely to remain outside tidy certificate dashboards. They are also the identities that typically outlive application teams, vendor refresh cycles, and even infrastructure generations. That means PQC planning must be tied to lifecycle governance, not only cryptographic standards work.

Quantum readiness exposes a new identity risk surface: trust assumptions built around static credentials and slow refresh cycles. The article’s central value is not the scan itself but the reminder that identity programmes still rely on inventories they do not fully possess. Once a credential or certificate can persist for years, the gap between what is reachable and what is governed becomes the real risk boundary. The implication is that security leaders must reframe PQC as a lifecycle and visibility problem, not a one-time technical upgrade.

External-facing crypto often looks easier because it is more observable, which can distort prioritisation. Security teams can move quickly on domains, CDNs, and public TLS settings, but that should not be confused with completing the quantum migration. The harder work sits where accountability fragments across platform, application, and identity owners. Practitioners should use the easy win to justify deeper inventory work, not to declare progress complete.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For the broader identity inventory needed here, see Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Cryptographic readiness is becoming a visibility problem as much as a standards problem. Teams can scan public domains quickly, but the real question is whether they can trace the identity estate behind those endpoints. The strongest programmes will pair external TLS checks with a live inventory of certificates, service accounts, API keys, and embedded crypto libraries, then route remediation through a named lifecycle owner.

Public-domain PQC wins can hide deeper crypto debt. A compliant external handshake may satisfy an initial checkpoint, but it does not remove the long tail of machine identity exposure or the vendor dependencies that often slow migration. Security leaders should use those early wins to justify board-level prioritisation for the harder internal work.

PQC migration will increasingly sit inside identity programmes, not outside them. The organisations that move fastest will treat cryptographic inventory and credential lifecycle control as one problem. That means linking scanning data to ownership data, then using the inventory to decide where the next remediation dollar has the most leverage.

For practitioners

• Baseline every public domain with a PQC handshake scan Start with the internet-facing domains that carry the highest exposure, including subdomains used for APIs, authentication, and partner access. Capture TLS version, supported algorithms, and certificate details so you can compare current state across the portfolio.
• Inventory machine identities that outlive the network edge Map service accounts, API keys, SSH keys, and code signing certificates to the applications and teams that own them. Prioritise long-lived credentials and systems with unclear replacement paths, because those are the assets most likely to remain quantum-vulnerable after the first wave of external fixes.
• Validate hybrid negotiation before declaring a domain ready Confirm that critical public endpoints can negotiate both classical and post-quantum key exchange during the transition period. Use that result as a migration checkpoint, then trace dependencies that still rely on classical-only behaviour in internal tooling or vendor-managed services.
• Tie PQC remediation to lifecycle ownership Assign explicit ownership for certificate replacement, cryptographic library upgrades, and third-party dependency review. Without a lifecycle owner, quantum-readiness work will fragment across infrastructure, app teams, and vendors, which leaves the highest-risk assets unchanged.

Key takeaways

• Public-facing PQC scans are useful, but they only show whether a domain can negotiate quantum-safe TLS at the edge.
• The main migration risk sits in machine identities, long-lived certificates, and poorly inventoried cryptographic dependencies.
• Teams should use external readiness results to trigger full cryptographic inventory, lifecycle ownership, and phased remediation.

Key terms

• Post-quantum cryptography: Post-quantum cryptography is a family of algorithms designed to resist attacks from sufficiently capable quantum computers. In practice, it is the replacement path for RSA, ECC, and related schemes that protect internet traffic, certificates, and identity flows today.
• Hybrid key exchange: Hybrid key exchange combines classical and post-quantum algorithms in the same connection. It lets organisations preserve backward compatibility while introducing quantum resistance during transition, which makes it a practical bridge rather than a final state.
• Cryptographic inventory: A cryptographic inventory is a structured record of where algorithms, certificates, keys, and other cryptographic dependencies exist across the environment. For identity teams, it must include machine identities, ownership, lifecycle state, and replacement priority, not just public certificates.
• Machine identity: Machine identity is the non-human identity that a workload, service, application, or automated process uses to authenticate and communicate. In PQC planning, these identities matter because they often carry long-lived credentials and hidden cryptographic dependencies that external scans cannot see.

Deepen your knowledge

NHI governance, agentic AI identity, machine identity security, and secrets management 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 programme maturity, 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.