How We Score

QUANTRAMA provides an automated quantum transition readiness assessment based on live TLS analysis and NIST post-quantum cryptography guidance. Here is exactly how it works — including where it may be incomplete.

Important: QUANTRAMA is a triage and prioritization tool, not a certification authority. Our scores indicate estimated quantum migration exposure based on publicly observable cryptographic configuration and current NIST guidance. They do not constitute a compliance certification, a guarantee of security, or a prediction of when quantum computers will break specific algorithms. Use our results alongside professional security review for compliance decisions.

What we analyze

We perform a real TLS handshake with your domain and inspect the cryptographic parameters negotiated by the server. This is the same handshake any browser or client performs — non-intrusive and zero-impact on your servers.

1. Protocol version — TLS 1.3, 1.2, or older (deprecated) protocols
2. Key exchange algorithm — RSA, ECDHE, DHE, and whether post-quantum key exchange (ML-KEM/Kyber) is supported
3. Cipher suites — AES-GCM, ChaCha20, or weak/deprecated ciphers (RC4, DES, 3DES)
4. Certificate details — key size, signature algorithm (RSA vs ECDSA), chain validity
5. CDN detection — we identify if a CDN fronts the domain so findings reflect the actual origin's exposure

Scoring formula

Your quantum readiness score is 0-100, where 100 means no quantum-vulnerable configurations detected. The exact formula:

score = 100 - ((critical × 40 + high × 25 + medium × 15 + low × 10) / max(totalFindings, 1))

Critical findingweight: 40

High findingweight: 25

Medium findingweight: 15

Low / informationalweight: 10

These weights are modeling decisions, not empirically derived constants. We chose them to reflect relative migration urgency based on NIST transition planning guidance. They may be adjusted as the post-quantum landscape evolves.

Severity classification

Severity reflects migration urgency — how exposed the configuration is and how quickly it should be addressed in a quantum transition plan:

Critical: Configuration that is either already deprecated (SSLv3, TLS 1.0) or represents the highest quantum migration exposure: static RSA key exchange (no forward secrecy, vulnerable to harvest-now-decrypt-later), RSA-2048 certificates
High: Quantum-vulnerable but with some mitigating factors: ECDHE key exchange (has forward secrecy but ECC is quantum-vulnerable), larger RSA keys, no TLS 1.3 support
Medium: Missing post-quantum readiness features: no ML-KEM support, SHA-1 in certificate chain, 3DES cipher suites
Low: Best-practice gaps that are not directly quantum-related: missing HSTS, suboptimal cipher preference order, approaching certificate expiry

NIST PQC standard references

We assess alignment with the NIST post-quantum cryptography standards finalized in 2024:

FIPS 203 (ML-KEM) — Module-Lattice-Based Key-Encapsulation Mechanism (formerly Kyber)
FIPS 204 (ML-DSA) — Module-Lattice-Based Digital Signature Algorithm (formerly Dilithium)
FIPS 205 (SLH-DSA) — Stateless Hash-Based Digital Signature Algorithm (formerly SPHINCS+)

We also map findings to 9 additional compliance frameworks (HIPAA, PCI-DSS, GDPR, SOC2, CMMC, and more). These mappings are directional — they indicate where quantum cryptographic exposure intersects with framework requirements for encryption in transit, but they are not authoritative compliance assessments.

Migration urgency tiers

Instead of predicting when quantum computers will break specific algorithms (which nobody can reliably do), we classify findings by migration urgency:

Immediate

Already deprecated or broken (SSLv3, MD5, expired certs). Fix regardless of quantum timeline.

Urgent

Below NIST minimum key sizes. Vulnerable to classical and quantum attacks.

High priority

Vulnerable to Shor's algorithm on a CRQC. No forward secrecy or harvest-now-decrypt-later exposure.

Strategic

Currently secure against classical computers but will require migration per NIST PQC transition guidance. Plan and budget.

Low priority

Adequate effective security margin even under quantum threat models (e.g., SHA-256 under Grover's algorithm).

Where this assessment may be incomplete

We believe transparency about limitations builds more trust than claiming completeness. Here is what our scan does not cover:

Internal infrastructure: We analyze externally-observable TLS configuration only. Internal services, VPNs, database connections, and inter-service communication are not assessed.
Application-layer cryptography: We do not analyze how your application uses cryptographic libraries, key management, or data-at-rest encryption.
Full cipher suite enumeration: We analyze the cipher suite negotiated in a single handshake, not every cipher the server supports. A comprehensive audit would test all supported suites.
Multi-CDN / multi-origin configurations: CDN detection is heuristic-based. Complex multi-origin or multi-CDN setups may not be fully disambiguated.
Quantum timeline predictions: Nobody can reliably predict when a cryptographically relevant quantum computer (CRQC) will exist. We classify migration urgency, not timelines.
Compliance certification: Our framework mappings are directional guidance, not authoritative compliance assessments. Work with qualified auditors for compliance certification.

Try it yourself

Scan any domain and see exactly how the score breaks down — every finding is listed with its severity, explanation, and recommended action.

Scan a Domain — Free