Notifications
Clear all
Topic starter
06/06/2026 11:33 am
TL;DR: Public-facing TLS can often be checked for post-quantum readiness in seconds, but the harder work sits in the broader cryptographic estate where certificates, service accounts, SSH keys, and code signing remain poorly inventoried, according to Axiad. The real risk is not just quantum timelines, but the identity visibility gap that turns migration into a multi-year governance problem.
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 start a post-quantum migration program?
A: Start by inventorying where cryptography is actually used, then measure external exposure first.
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.
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.
Practitioner guidance
- 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.
- Separate hybrid support from final-state readiness Treat hybrid TLS negotiation as a transitional control.
What's in the full article
Axiad's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step interpretation of PQC readiness results for TLS 1.3 domains and certificate metadata
- Guidance on testing subdomains, vendor domains, and partner-facing endpoints as part of a portfolio scan
- Operational context for how hybrid key exchange behaves during migration and compatibility testing
- A deeper discussion of Axiad Mesh and how it correlates cryptographic assets with identities and risk
👉 Read Axiad's analysis of post-quantum readiness for internet-facing domains →
Post-quantum readiness testing: what IAM teams are missing?
Explore further
06/06/2026 12:25 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Post-quantum readiness exposes the identity inventory gap
