TL;DR: Public-facing domains can be scanned in seconds for post-quantum TLS readiness, but the real program work sits in cryptographic inventory, certificate migration, and long-lived machine identity dependencies, according to Axiad. The external check is useful, but it only marks the start of a multi-year transition, not the end.
At a glance
What this is: Axiad's article shows that public-facing domains can be scanned quickly for PQC readiness, but TLS results only expose part of the cryptographic migration problem.
Why it matters: IAM and security teams need to treat external PQC checks as an entry point to broader identity, certificate, and machine-credential inventory work, not as proof of readiness.
Context
Post-quantum cryptography readiness is a cryptographic governance problem before it is a scan result problem. Internet-facing TLS can be tested quickly, but the real exposure sits in the inventory, migration sequencing, and dependency mapping behind the handshake.
For identity programmes, the issue spans machine identities, certificates, and long-lived secrets as much as it spans public websites. Axiad's article argues that external domain checks help establish a baseline, but they do not surface the internal cryptographic estate that will be hardest to change.
Key questions
Q: How should teams start a PQC migration for internet-facing domains?
A: Start by scanning critical public domains to establish a baseline, then separate TLS key exchange support from certificate algorithms and from internal cryptographic dependencies. The early win is useful, but the programme only becomes real once teams map ownership, replacement order, and the machine identities tied to those assets.
Q: Why does a PQC-ready TLS result not mean the environment is fully ready?
A: Because a domain can negotiate post-quantum key exchange and still rely on classical certificate signatures, internal PKI, or long-lived machine credentials. Readiness is distributed across multiple identity and crypto layers, so one passing handshake cannot prove the rest of the estate is prepared.
Q: What are the biggest blind spots in external PQC scans?
A: External scans cannot see private networks, intranet systems, application-layer cryptography, or the machine identities and certificates that are embedded inside enterprise workflows. That means the scan is a useful edge signal, but it is not a cryptographic inventory and not a replacement for lifecycle governance.
Q: Should organisations prioritise public-facing domains before internal cryptographic assets?
A: Yes, because public-facing TLS is easier to measure and often faster to improve, which makes it a practical early milestone. But the largest migration effort usually sits in internal PKI, service credentials, and other long-lived machine identities, so the roadmap should not stop at the edge.
Technical breakdown
How a TLS handshake reveals PQC readiness
A public-domain PQC scan works by performing a real TLS handshake against the target domain and observing which key exchange algorithms the server offers and negotiates. In practice, that tells you whether the endpoint can use post-quantum methods at the connection layer. It does not test internal systems, private networks, or application-layer crypto. It is therefore a protocol-level signal, not a full cryptographic posture assessment.
Practical implication: Use external TLS scans as a point-in-time signal, then validate the broader cryptographic estate separately.
Why certificate and key exchange readiness are not the same thing
A domain can support PQC key exchange while still relying on classical certificate signature algorithms. That is because the TLS handshake and the certificate ecosystem migrate on different timelines. Readiness at one layer does not prove readiness at the other, and a green scan result can hide unresolved certificate dependencies, trust-chain issues, and mixed-mode deployment decisions.
Practical implication: Track key exchange, certificate algorithms, and trust-chain dependencies as separate migration workstreams.
Why machine identity is the harder part of PQC migration
The article's deeper point is that the hardest cryptographic work usually lives in machine identity: SSH keys, code-signing certificates, service account credentials, and other long-lived assets embedded across systems. These credentials are often poorly inventoried, widely distributed, and tied to legacy dependencies that cannot be upgraded in a single change window. That makes PQC migration a lifecycle problem, not just a protocol problem.
Practical implication: Build a machine-identity inventory before you set migration timelines for public-facing domains.
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
External PQC scanning is a visibility layer, not a migration strategy: A public-domain TLS check tells practitioners whether a server can negotiate quantum-resistant key exchange, but it does not tell them whether the enterprise is ready to operate that way at scale. The useful signal is bounded by what the handshake can observe, so the control plane still needs inventory, ownership, and change sequencing. The practitioner conclusion is simple: baseline scans are necessary, but they are not governance.
Cryptographic inventory is now an identity problem: The article correctly points to machine identities, certificates, SSH keys, and code-signing assets as the stubborn part of the journey. Those are identity objects with lifecycle, ownership, and dependency constraints, which means PQC readiness sits inside IAM and NHI governance as much as it sits inside cryptography. Teams that treat the issue as a security architecture refresh will miss the offboarding, renewal, and replacement work that determines success.
Public-facing domains are the easiest part of the transition: External TLS is often the first visible milestone because CDNs and hosting providers have already absorbed some of the complexity. That creates a dangerous optimism effect if teams mistake easy wins for programme maturity. The harder work remains in internal PKI, application dependencies, and long-lived machine credentials, so the real measure of readiness is whether the inventory exists to drive replacement decisions.
Long-lived crypto debt is the named concept practitioners should watch: The article's substance points to a backlog of classical algorithms embedded across certificates, keys, and identity systems that cannot be retired on a single schedule. That debt accumulates where visibility is weakest and where replacement cost is highest. Practitioners should treat quantum readiness as a debt-reduction programme, not a one-off scan result.
Quantum readiness exposes the gap between posture and proof: A domain can look prepared in a browser-facing test while the rest of the identity estate remains unclassified. That mismatch is why boards and auditors need evidence from inventories, not just a passing result from an external probe. The practitioner conclusion is to prove readiness across the full cryptographic lifecycle, not just at the edge.
What this signals
Long-lived crypto debt: The hardest PQC work sits in certificates, SSH keys, code signing, and service credentials that have accreted over years of system change. That means the operational question is not whether a public domain passes a scan, but whether the organisation can inventory and retire the cryptographic assets that are invisible from the edge.
External TLS checks will become a necessary but insufficient control signal for programmes that need board-level evidence of quantum readiness. Teams should expect the governance burden to move toward identity lifecycle ownership, replacement sequencing, and dependency mapping across machine credentials and PKI.
For practitioners
- Baseline public-facing domains Run external PQC scans across critical internet-facing domains to establish which TLS endpoints already negotiate post-quantum key exchange and which still rely on classical algorithms.
- Separate handshake results from certificate readiness Track TLS key exchange support, certificate signature algorithms, and trust-chain dependencies as distinct workstreams so one green result does not mask another gap.
- Inventory machine identity dependencies Build a register of SSH keys, code-signing certificates, service account credentials, and other long-lived cryptographic assets that sit outside public-domain scanning.
- Use scan output for vendor due diligence Test third-party internet-facing services that your organisation depends on and record whether their public TLS posture supports your quantum-readiness roadmap.
- Sequence migration by exposure and replacement cost Prioritise externally exposed assets first, then move to internal PKI and hard-to-replace identity credentials where replacement effort and dependency risk are highest.
Key takeaways
- Public-domain PQC tests are useful because they show whether a TLS endpoint can negotiate quantum-resistant key exchange, but they only cover one layer of the cryptographic estate.
- The article's key operational warning is that certificates, SSH keys, code-signing assets, and service credentials are the harder migration surface because they are longer-lived and less visible.
- Teams should treat external scans as a baseline and then move into inventory-led remediation for machine identities, internal PKI, and certificate dependencies.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-57 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Long-lived certificates, keys, and service credentials are the migration burden in this article. |
| NHI-05 — Overprivileged NHI | Machine identities and certificates often outlive their needed scope during crypto transitions. | |
| Recommendation — Inventory and retire long-lived NHI credentials before they become blockers to PQC migration. Reduce the blast radius of machine identities whose credentials persist beyond their operational need. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article is fundamentally about cryptographic lifecycle planning and replacement. |
| Recommendation — Apply key lifecycle governance to discover, rotate, replace, and retire quantum-vulnerable cryptographic material. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | PQC readiness depends on governing who and what can use cryptographic credentials and trust paths. |
| Recommendation — Review cryptographic entitlements and access paths before migration decisions are made. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Harvest-now-decrypt-later is a credential and encrypted-data exposure threat pattern. |
| Recommendation — Map long-term confidentiality exposure to TA0006 and prioritise assets likely to be harvested today. | ||
Key terms
- Post-Quantum Cryptography Readiness: Post-quantum cryptography readiness is the capacity to test, deploy, and manage quantum-resistant or hybrid algorithms before they are urgently required. It depends on flexible architecture, limited hard-coded cryptography, and operational processes that can absorb repeated algorithm change.
- 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.
- 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.
- Harvest now, decrypt later: An attacker strategy where encrypted traffic or stored data is collected today and decrypted later when better computing power becomes available. It matters to NHI governance because machine identities often protect the data paths and secrets most worth preserving over time.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org