Topic starter
12/06/2026 10:00 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Axiad: “Find Out If Your Public-Facing Domains Are Quantum-Ready”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
13/06/2026 12:29 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Public-facing domain PQC readiness exposes the deeper crypto gap