Sample: example data, not your organisation. Every host, score and cost below is made up for example.com.
Post-Quantum Cryptography Risk Briefing
Scope: example.com · NCSC-aligned QScore briefing
ScoreCeiling ~82/100
This is a sample. example.com shows a mixed picture: one public website already negotiates a hybrid post-quantum key exchange, while most other endpoints use classical ECDHE or static RSA key exchange, and one legacy host still offers an outdated TLS version with a 1024-bit RSA certificate. Traffic recorded today from the classical endpoints could be decrypted in future if a cryptographically relevant quantum computer is built (harvest now, decrypt later). The quickest gains are retiring the legacy host and enabling hybrid key exchange where the server software supports it.
Indicative portfolio band
£130,000 to £295,000
22 programme-level actions in the underlying estimate
| Tier | Actions × affected | Indicative band | Typical work |
|---|---|---|---|
| High Complexity | 1 × 4 | £60,000 – £120,000 | PKI, HSM, CA migration |
| Medium Complexity | 3 × 13 | £60,996 – £152,493 | TLS libraries, vendor alignment |
| Low Complexity | 2 × 5 | £9,000 – £24,000 | Config changes, protocol updates |
NCSC Migration Horizon & Inaction Penalty Example
2031 risk differential (act now vs do nothing): 81 pts
Illustrative scenarios from your current QScore, not forecasts. Act now: steady upgrades reach 100 by 2031. Delay: no change for two years, then a rushed catch-up to 100 by 2035. Do nothing: falls to 0 by 2035 as today's algorithms are deprecated.
Google Cloud targets store-now-decrypt-later mitigation by the end of 2027, before the NCSC 2028, 2031, and 2035 milestones. Google targets its own PQC migration by 2029, and Google Cloud targets full PQC readiness by 2029, before the NCSC 2031 and 2035 milestones. IBM plans a fault-tolerant module in 2027 and the Starling fault-tolerant computer in 2029. IBM does not describe either as a cryptographically relevant quantum computer.
Sources. IBM Quantum roadmap, updated March 2026 · Google Cloud PQC roadmap · IBM Quantum roadmap · IBM newsroom · Google cryptography migration timeline
Indicative scores from automated TLS analysis — not a substitute for architecture review or legal advice.
- Confirm executive ownership of the PQC migration programme and name a Senior Responsible Owner.
- Agree reporting cadence to the Technology Risk Committee until QScore exceeds 60/100 (current 39/100).
- Ring-fence indicative budget of £130,000–£295,000 in the next planning cycle.
- Commission a crypto-agility baseline assessment for all systems processing long-lived sensitive data.
| Decision | Basis | Owner |
|---|---|---|
| Approve retiring legacy key exchange (RSA or finite-field DHE) on 2 public endpoints, moving to ECDHE as a step towards hybrid PQC. | 2 endpoints negotiated legacy key exchange (RSA or DHE). | Unassigned |
| Approve enabling TLS 1.3 on 4 public endpoints, after checking which clients still need older versions. | 4 endpoints did not negotiate TLS 1.3, which hybrid PQC key exchange requires. | Unassigned |
| Approve a hybrid PQC key exchange rollout (for example X25519MLKEM768) on 4 public endpoints, subject to client compatibility testing. | 4 endpoints offered only classical key exchange. | Unassigned |
| Approve reissuing certificates with short keys on 1 endpoint. | 1 endpoint presented a certificate key below current minimums. | Unassigned |
| Accept the residual risk of classical certificates and signatures until publicly trusted PQC certificates are available, and review this acceptance at each report. | Publicly trusted PQC certificates are not yet issued, so no endpoint can remove this risk today. | Unassigned |
| Decide whether to commission a manual assessment of the 1 service the automated scan could not assess, or accept them as unknown. | 1 discovered service returned no usable result. | Unassigned |
Proposed from the automated findings for the board to consider; each needs technical review before approval. Owners are not recorded yet.
| Risk | Why it matters | Services | Indicative cost | Owner |
|---|---|---|---|---|
| Legacy Key Exchange (DHE/RSA) | Legacy key exchange (static RSA or finite-field DHE). Static RSA has no forward secrecy, and both are classical, so recorded traffic is exposed to harvest-now, decrypt-later. | 2 | £14,142–£35,355 | Unassigned |
| PQC Hybrid Key Exchange Missing | Classical key exchange only: traffic recorded today could be decrypted by a future quantum computer (harvest-now, decrypt-later). | 4 | £60,000–£120,000 | Unassigned |
| Weak Certificate Key (RSA < 2048) | Certificate key is shorter than current minimums, weakening authentication now, before any quantum threat. | 1 | £3,000–£8,000 | Unassigned |
| Weak Signature Algorithm | Weak signature algorithm in the TLS handshake or certificate. | 5 | £22,360–£55,901 | Unassigned |
| Legacy TLS Version (< 1.3) | TLS 1.3 is not negotiated, and hybrid PQC key exchange needs TLS 1.3. | 4 | £6,000–£16,000 | Unassigned |
No earlier completed scan of this domain to compare with. Progress will show from the next report.
| Not assessed | Why |
|---|---|
| vpn.example.com:500 (IPSec-IKE) | Analysis did not return usable TLS data: it failed or timed out, or the service does not use TLS. |
Scores and findings cover assessed services only. Services that were not assessed are unknown, not safe.
CISO & Technical Evidence
Governance findings, resilience profile, supply chain posture, and technical annex.
| # | Risk Finding | Governance Impact | Priority |
|---|---|---|---|
| 1 | Crypto Agility Gap (Single Rigid Config) | TLS configuration changes to support multiple modern cipher suites and key exchange groups | High |
| 2 | Weak Signature Algorithm | Migration to RSA-PSS or ECDSA signatures, server configuration updates | High |
| 3 | PQC Hybrid Key Exchange Missing | Infrastructure upgrade to support ML-KEM hybrid ciphers, client compatibility testing, potential TLS library updates | Critical |
| 4 | Legacy TLS Version (< 1.3) | Standard protocol upgrade with minimal code changes, widely documented process | Medium |
| 5 | Legacy Key Exchange (DHE/RSA) | Requires enabling modern ECDHE key exchange, potential client compatibility review | High |
Six-Axis Assessment
Third-Party TLS and PQC Posture
Supply-chain scanning is not enabled on this account. Upgrade or enable suppliers in the dashboard to assess third-party TLS posture here.
3/8 endpoints
TLS 1.2 or below
Key-exchange gaps
Negotiation-ready
Endpoint scan metadata (lowest QScore)
Each row is a TLS discovery target (hostname or IP:port) from the scan. Top 5 lowest-scoring targets shown; full inventory via dashboard CSV export.
| # | Host / target | Port | Posture | Key ex. | Cert |
|---|---|---|---|---|---|
| 1 | legacy.example.com:8443 | 8443 | quantum-vulnerable | rsa | rsa-1024 |
| 2 | mail.example.com:25 | 25 | quantum-vulnerable | rsa | rsa-2048 |
| 3 | portal.example.com | 443 | transitional | ecdhe | rsa-2048 |
| 4 | mail.example.com:993 | 993 | transitional | ecdhe | rsa-2048 |
| 5 | api.example.com | 443 | transitional | ecdhe | rsa-2048 |
| Indicator | Wt | Max |
|---|---|---|
| Key Exchange | 35% | 2 |
| TLS Version | 20% | 2 |
| Crypto Agility | 20% | 2 |
| TLS Signature | 15% | 1 |
| Certificate Algorithm | 7% | Blk |
| Downgrade Resistance | 3% | Blk |