Post-Quantum Readiness
Quantum-resistant migration is broader than replacing one certificate algorithm. Organizations must inventory certificates, TLS key exchange, stored data, VPNs, HSMs, code-signing systems, applications, and operational dependencies.
What Certificate Inspector does: it provides an externally observable endpoint snapshot. It does not certify that an organization is quantum-safe or compliant.
What the report checks
- Whether the public certificate exposes recognizable classical or post-quantum signature/key material. ML-DSA is a digital-signature algorithm, not a TLS key-exchange mechanism.
- Negotiated TLS version and cipher suite.
- Whether the current scanner can identify the TLS key-exchange group or must report it as not observed. ML-KEM is a key-encapsulation mechanism for key establishment, not a certificate-signature algorithm.
- Migration limitations and practical follow-up actions.
How to interpret the result
- PQC observed: a recognized post-quantum certificate algorithm was visible.
- Classical-only observed: the certificate exposes RSA, ECDSA, or another classical algorithm. This is a migration signal, not a complete risk verdict.
- Not observed: the scanner cannot determine the key-exchange group from the current handshake path.
- Unknown: the returned fields do not support a reliable classification.
Recommended organizational next steps
- Build a cryptographic inventory covering public and internal certificates, keys, algorithms, protocols, vendors, and owners.
- Identify long-lived sensitive data that may face “harvest now, decrypt later” exposure.
- Confirm support for current hybrid key exchange and post-quantum signature options with TLS vendors, certificate authorities, browsers, and clients.
- Test interoperability and performance before changing production certificate profiles.
- Track current NIST and standards guidance rather than relying on a one-time scan result.