Notifications
Clear all
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.
NHIMG editorial — based on content published by Axiad: Is Your Domain Ready for the Post-Quantum Era? Check Now Quantify Your Identity Risk in Minutes
By the numbers:
- Gartner's research projects that quantum computing will render conventional asymmetric cryptography unsafe by approximately 2029 and fully breakable by 2034.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Axiad's full article covers the operational detail this post intentionally leaves for the source:
- How the PQC Readiness Tester interprets TLS handshakes and algorithm negotiation in practice
- The exact result fields returned by the scan, including supported algorithms, TLS version, and certificate metadata
- Why hybrid post-quantum and classical negotiation is useful during migration
- How Axiad positions its broader cryptographic visibility platform for full inventory work
👉 Read Axiad's analysis of public-domain PQC readiness and cryptographic inventory →
PQC readiness for internet-facing domains: are your controls enough?
Explore further
13/06/2026 12:29 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Public-facing domain PQC readiness exposes the deeper crypto gap
