PQC readiness report
example-bank.com · Scanned May 20, 2026
PQC readiness score
example-bank.com
- Readiness indicator, not a security guarantee
- Higher score = more PQC-ready
- Based on TLS, certificate & key-exchange posture
Executive summary
PostQ scanned the public TLS endpoint for example-bank.com and found 3 findings, including 2 high-priority items and 3 quantum-vulnerable algorithms in the externally visible cryptography. The overall readiness score is 52/100 (High risk).
This score is a readiness indicator based on externally observable TLS, certificate, and key-exchange posture — not a guarantee of security. A complete cryptographic inventory also covers internal services, cloud KMS/HSM keys, JWTs, and code-signing workflows.
Risk score breakdown
Weighted categories that make up the readiness score.
TLS 1.0/1.1 disabled, TLS 1.3 available.
Leaf certificate uses RSA-2048 (quantum-vulnerable).
Certificate signed with RSA + SHA-256.
Classical X25519 key exchange — no PQ protection.
Certificate lifetime within recommended window.
External scan only — internal assets not yet inventoried.
TLS 1.3 in place, ready to enable hybrid key exchange.
Technical findings
Classical key exchange negotiated (X25519)
Key exchange
The TLS session key was established with X25519, a classical elliptic-curve Diffie-Hellman group. Traffic recorded today could be decrypted later by a quantum adversary (harvest-now-decrypt-later).
kx=X25519; cipher=TLS_AES_256_GCM_SHA384
What this means
This is the part of TLS most exposed to 'record now, decrypt later' once quantum computers arrive.
How to fix
Enable hybrid key exchange (X25519MLKEM768) on your TLS terminator / load balancer to protect session confidentiality.
Certificate public key uses RSA-2048
TLS certificate
The leaf certificate's public key (RSA-2048) is based on integer factorisation, which Shor's algorithm can break on a cryptographically relevant quantum computer.
subject=CN=example-bank.com; key=RSA-2048
What this means
This is the key that proves the server's identity. If it is RSA, a future quantum computer could forge it.
How to fix
Plan migration toward ML-DSA (FIPS 204) signatures, or a hybrid classical + ML-DSA composite certificate as CAs and clients add support.
Certificate signed with sha256WithRSAEncryption
TLS certificate
The certificate signature algorithm depends on RSA, which is quantum-vulnerable. Certificate signatures migrate when CAs begin issuing PQ-signed certificates.
sigalg=sha256WithRSAEncryption; issuer=DigiCert Global G2
What this means
This is how the Certificate Authority vouches for the certificate — a separate algorithm from the public key.
How to fix
Track your CA's roadmap for post-quantum signature support (ML-DSA / SLH-DSA).
TLS configuration
TLSv1
Disabled
TLSv1.1
Disabled
TLSv1.2
Enabled
TLSv1.3
Enabled
Algorithm inventory
| Algorithm | Category | Usage | Posture | Migrate to |
|---|---|---|---|---|
| RSA-2048 | public-key | TLS leaf certificate public key | Quantum-vulnerable | ML-DSA (FIPS 204) |
| sha256WithRSAEncryption | signature | Certificate signature | Quantum-vulnerable | ML-DSA / SLH-DSA |
| X25519 | key-exchange | TLS session key establishment | Quantum-vulnerable | X25519MLKEM768 (hybrid ML-KEM) |
| TLS_AES_256_GCM_SHA384 | symmetric | Bulk record encryption | Symmetric (lower risk) | — |
Certificate chain
- Public key
- RSA-2048
- Signature
- sha256WithRSAEncryption
- Issuer
- CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1, O=DigiCert Inc, C=US
- Valid to
- Feb 14, 2027 (261d)
- SHA-256
- B4:2C:9F:11:7A:E0:3D:55:88:AA:01:9C:7E:F3:2B:10:44:DE:90:71:0C:3F:A8:55:21:99:6E:D2:44:7B:C8:00
- Public key
- RSA-2048
- Signature
- sha256WithRSAEncryption
- Issuer
- CN=DigiCert Global Root G2, O=DigiCert Inc, C=US
- Valid to
- Apr 13, 2031 (1779d)
Recommended migration steps
- 1Enable hybrid key exchange (X25519MLKEM768) at your TLS terminator to mitigate harvest-now-decrypt-later on recorded traffic.
- 2Add the certificate's signing keys to your cryptographic inventory and tag them for ML-DSA migration once your CA supports PQ signatures.
- 3Run the PostQ agent inside your cluster and connect cloud KMS to extend this external view into a full cryptographic inventory.
- 4Prioritise migration by asset criticality and external exposure rather than migrating everything at once.
Compliance & audit notes
This report can be attached as evidence for cryptographic-inventory requirements that increasingly appear in security reviews (e.g. NIST’s migration guidance, US OMB M-23-02, and emerging FedRAMP / SOC 2 expectations around crypto-agility). PostQ does not assert any compliance certification on your behalf; use this as supporting evidence within your own program.
Send me the full PQC readiness report
Get the PDF for example-bank.com plus a guided checklist for extending this scan into a full cryptographic inventory.