Understanding Your Quantum Exposure Snapshot: What the Score Means

The Quantum Exposure Snapshot produces a four-band score. Most users want to know what the band means and whether they should be concerned. The more useful question is: what does the score actually measure, and how did it arrive at that number? Understanding the methodology is what converts the output from a traffic-light indicator into an actionable risk position.

QSECDEF's Quantum Threat Exposure Assessment tool is not a compliance scanner. It does not parse your firewall rules or connect to your certificate management system. It takes three structured inputs, overlays them against two independent analytical frameworks, and returns a score that reflects the statistical probability your organisation's encrypted data will require confidentiality past the point at which current public-key algorithms are expected to be broken. That is a narrow, specific question. The score answers it.

This article walks through what those frameworks are, what each input contributes to the calculation, and what organisations in each score band should do next. Security architects who have already completed the assessment will find this useful for explaining the result to colleagues. Risk officers preparing to use the tool will find it useful for understanding which inputs to research before they start.

The Two Frameworks Behind the Score

The score integrates two independent analytical frameworks. Neither is proprietary. Both are published by US government standards bodies.

Framework 1: NIST IR 8547 deprecation taxonomy. NIST IR 8547 IPD (Initial Public Draft, November 2024) classifies cryptographic algorithms into four categories based on their quantum security status:

• Category 1: Algorithms considered quantum-resistant. No migration required. AES-256-GCM is Category 1. Grover's algorithm reduces its effective key length from 256 bits to 128 bits, which remains secure against near-term CRQCs. SHA-256 and SHA-384 are also Category 1.
• Category 2: Algorithms deprecated for use in new systems after 2030. RSA (all key sizes), ECDH, ECDSA, DSA, and DH fall here. Existing systems must migrate before 2035.
• Category 3: All Category 2 algorithms disallowed after 2035 regardless of use case. Category 2 transitions here automatically at that deadline.
• Category 4: Algorithms already deprecated before the PQC transition. SHA-1 and 3DES are examples. Relevant to inventory completeness rather than forward quantum risk.

Framework 2: Retention period overlaid against the CRQC probability distribution. For each data category the user declares in the tool, the tool calculates the forward confidentiality requirement: from today, how long must data encrypted now remain secure? This is the sensitivity lifetime (SL) from Mosca's inequality, first published in IEEE Security and Privacy by Michele Mosca in 2018. The tool then applies the GRI 2024 probability distribution for CRQC availability, which places 14 to 34% probability of a cryptographically relevant quantum computer (CRQC) capable of breaking RSA-2048 within 24 hours in the 2033 to 2035 window. These two elements together determine whether the organisation's data is likely to require confidentiality inside the risk window.

For context on how these probability figures were derived, see Q-Day Probability Research Synthesis 2024.

Input One: Data Inventory Categories

What Each Category Contributes to the Score

The tool uses four broad data inventory categories, each with a default sensitivity lifetime weighting based on common regulatory retention schedules across UK and EU jurisdictions.

PII (personally identifiable information). Default SL weighting: 3 to 7 years, depending on the applicable jurisdiction retention schedule. GDPR Article 5(1)(e) requires data to be kept no longer than necessary; in practice, consumer PII retention runs 2 to 5 years across most sectors. Short SL relative to the CRQC window. For most organisations, PII alone will not produce a High or Critical score unless it is combined with other high-SL data categories or a very long migration timeline.

Financial records. Default SL weighting: 5 to 10 years. MiFID II Article 25(1) requires records of transactions for 5 years, extending to 7 years in some categories. Tier-1 financial institutions holding long-duration instruments, such as mortgages and structured products, may carry financial data sensitivity extending to 15 to 25 years. Medium to high SL depending on the instrument type and the organisation's counterparty position.

Intellectual property. Default SL weighting: 10 to 20 years. Patent protection runs 20 years from filing; trade secrets may have indefinite commercial value. IP data is a primary harvest-now-decrypt-later (HNDL) target. NSA's August 2021 advisory on quantum computing documented HNDL as an active threat model against high-value IP precisely because the sensitivity lifetime extends well past current CRQC probability estimates. High SL. The HNDL Risk Assessment Framework covers the threat model and mitigation sequence for organisations in this position.

Regulated archives. Default SL weighting: 10 to 30 years. Includes government, defence, regulated financial, and healthcare records subject to statutory or regulatory retention mandates. NHS Digital retention schedules require a minimum of 8 years for adult care records; defence acquisition records may be retained indefinitely. Maximum SL.

These defaults are starting points. Organisations with specific policy data should adjust SL estimates to reflect their actual retention schedules rather than relying on the tool's defaults.

Why Multi-Category Inventories Produce Compound Scores

Most organisations hold multiple data categories simultaneously. An insurer holds PII (low risk), financial records (medium risk), and long-duration liability data that qualifies as regulated archives (high risk). The tool compounds these by taking the maximum SL across declared categories and applying the CRQC timeline overlay to that maximum.

This is a conservative design choice, not an alarmist one. The alternative, averaging SL across all declared categories, would underweight high-risk data classes and produce a misleadingly moderate score for organisations that hold even small amounts of high-SL data. The tool assumes the highest-risk data class drives the organisation's overall cryptographic exposure. That assumption is appropriate because a HNDL adversary targeting IP will collect the full encrypted traffic stream, not just the IP-specific transmissions.

Input Two: Retention Periods

The tool's second input is the organisation's actual retention period for each declared data category. Where the user has specific policy data, this overrides the default SL weighting.

The distinction between retention period and sensitivity lifetime is worth holding precisely.

• Retention period: how long the organisation stores the data. A policy and legal compliance variable.
• Sensitivity lifetime: how long the data must remain confidential from an adversary. A risk variable.

For most data, the two are approximately equal. But some categories diverge. Anonymised financial research data might be retained for 15 years for statistical purposes while losing commercial sensitivity after 3 years. The tool uses the shorter of the two: the period during which data is both retained and sensitive. This is consistent with the framework in NIST IR 8105 (April 2016) and Mosca's 2018 formulation of the inequality, both of which define SL as a risk variable rather than a policy variable.

NIST IR 8547 IPD uses the concept of "sensitivity period" explicitly when discussing long-term data protection requirements. The tool's input structure follows that framing directly.

Input Three: Current Cryptographic Stack

Algorithm Classification Against NIST IR 8547

The third input is a self-declaration of the organisation's current cryptographic stack: which algorithms are in use, across which systems, and whether those systems have confirmed PQC migration paths. The tool maps declared algorithms to NIST IR 8547 categories to determine how many of the organisation's systems are already running deprecated or at-risk algorithms.

• RSA-2048, RSA-4096, ECDH (P-256, P-384), ECDSA: Category 2. Deprecated for new systems after 2030, disallowed after 2035.
• AES-128-GCM: Category 1, but operationally weaker than AES-256-GCM. Post-Grover, AES-128-GCM provides 64-bit effective security. That 64-bit post-Grover bound falls below NIST SP 800-57 Part 1 Rev 5's minimum 112-bit security strength threshold for near-term use, meaning AES-128 post-Grover is not marginally acceptable. It falls below the NIST security floor entirely. The tool flags this for upgrade independently of the quantum risk score. AES-256-GCM is the appropriate standard.
• AES-256-GCM: Category 1. Quantum-resistant. No migration required.
• TLS 1.3 with ECDH key exchange: Category 2 for the key exchange component. The symmetric cipher component (typically AES-256-GCM) may be Category 1. These are separable risks. A TLS configuration that uses AES-256-GCM for session encryption but ECDH for key exchange is partially Category 2.
• 3DES, RC4, DES, RSA-1024: Category 4. Already deprecated. These should be flagged as immediate-action items irrespective of quantum risk.

For a detailed treatment of how TLS 1.3 components map to these categories, see Post-Quantum TLS: What Changes and What Stays the Same.

What "No Known Migration Path" Means for the Score

Some systems, particularly legacy hardware security modules (HSMs), embedded devices, and operational technology controllers, use Category 2 algorithms but have no vendor-confirmed PQC migration path. FIPS 140-3 validated PQC implementations are required in regulated sectors. The NIST Cryptographic Module Validation Programme (CMVP) at csrc.nist.gov is the authoritative source for module validation status. As of early 2026, validated PQC implementations remain limited in number; organisations should verify current CMVP status directly rather than relying on vendor roadmap claims.

When a system is declared as having no known migration path, the tool increases the score contribution from that system category. An organisation with RSA in use on systems with a confirmed ML-KEM migration path faces a different risk position from one with RSA on systems that require physical hardware replacement. The self-declaration input captures this distinction, but it requires accurate reporting. An organisation that marks "migration path unknown" as "confirmed" will receive a lower score than its actual risk position warrants.

Reading the Score Bands

The Quantum Exposure Snapshot outputs a four-band score. The bands reflect the organisation's position on the risk curve produced by overlaying its specific data lifetime and cryptographic stack against the GRI 2024 probability distribution.

Low. The organisation's data sensitivity lifetime, combined with the assessed cryptographic stack, falls below the lower bound of the GRI 2024 CRQC probability window. The current cryptographic stack is adequate for the near-term risk horizon, provided migration begins within 2 years. Typical profile: short retention periods, no high-value IP or regulated archives, use of AES-256 for data at rest with RSA limited to TLS session key establishment.

Medium. The organisation holds data with sensitivity lifetimes extending into the 2030 to 2033 window, and uses Category 2 algorithms across some systems. Migration is time-constrained but manageable within a structured 24 to 36-month programme. The investment case for PQC migration is clear at this score; the urgency is real rather than theoretical.

High. The organisation holds IP, regulated archives, or financial data with sensitivity lifetimes extending to 2033 to 2035 or beyond, with Category 2 algorithms across multiple critical systems without confirmed PQC migration paths. At this score level, the probability that adversaries are already harvesting encrypted traffic for future decryption is material, not hypothetical.

Critical. One or more of: sensitivity lifetime exceeds 2035 for material data categories; Category 2 algorithms in use on systems with no known migration path; Category 4 algorithms currently active; evidence or suspicion of active HNDL targeting. Immediate escalation to CISO level and initiation of a cryptographic inventory programme is indicated.

A high or critical score does not mean the organisation is failing. It means the organisation now has a clear-eyed view of its risk. The organisations that discover a high score and escalate are better positioned than those that have not yet assessed at all.

What to Do With Your Score

Each score band implies a different immediate action sequence.

Low: Initiate a cryptographic inventory now. The risk is manageable, but the inventory process takes 6 to 18 months for most enterprises. Starting now preserves the planning buffer against the 2030 deprecation milestone for new Category 2 deployments.

Medium: A cryptographic inventory is urgent. The TLS certificate estate is the highest-priority discovery target: highest volume, clearest migration path to ML-KEM hybrid. Begin vendor engagement on PQC roadmaps for critical systems. The CBOM Foundation and PQC Readiness article covers how to build the inventory structure. Once the inventory is built, the Cryptographic Asset Prioritisation Matrix helps sequence which assets to migrate first.

High: Escalate to the board or executive committee. The investment case for PQC migration is compelling at this score. Prioritise discovery for systems handling IP, financial data, and regulated archives. Treat the cryptographic inventory programme as a funded project with a defined scope and a 2030 delivery target for priority systems.

Critical: Treat as a current security escalation in terms of priority. Data encrypted today under Category 2 algorithms and retained for 15 or more years carries meaningful probability of adversarial decryption before its sensitivity period expires. The migration programme must be resourced and sequenced immediately, not deferred to the next planning cycle.

For organisations uncertain where to begin after receiving a Medium or higher score, the Q-Day Timeline Calculator provides the complementary tool: it takes migration timeline estimates and data sensitivity lifetimes as inputs and returns the urgency window for the migration programme specifically, as distinct from the overall exposure assessment.

Common Misconceptions

A high score means non-compliance. The score is a risk assessment, not a compliance audit. NIS2 Article 21(2)(h), DORA Article 6, and NCSC guidance all require appropriate cryptographic controls, but none have published a PQC compliance benchmark that maps directly to the Snapshot score bands.

AES-128-GCM and AES-256-GCM are the same risk. They are not. AES-256-GCM provides 128-bit post-Grover effective security. AES-128-GCM provides 64-bit. For any system where AES-256-GCM is operationally feasible, it is the correct choice. Use AES-256-GCM.

The tool only matters for public-key cryptography. For quantum risk specifically, yes: the Mosca inequality and CRQC timeline overlay apply to RSA, ECDH, and ECDSA. But the tool also surfaces legacy symmetric weaknesses such as 3DES and AES-128 that should be addressed independently of quantum risk.

Our TLS provider handles this for us. The TLS handshake key exchange (ECDH) is Category 2. The TLS session cipher (AES-256-GCM) is Category 1. Relying on a cloud provider to manage TLS does not address the key exchange component. The two risks are separable and should be assessed separately.