What Is a Quantum Risk Assessment?
A quantum risk assessment evaluates an organization's exposure to cryptographic risk arising from the development of quantum computing capabilities specifically the harvest-now, decrypt-later threat and the future risk of signature forgery. It is distinct from a general cybersecurity risk assessment: it focuses specifically on which cryptographic systems create exposure, how much exposure they create, and in what order they should be migrated. The output is a risk-scored cryptographic inventory that serves as the direct input to migration roadmap planning.
NIST SP 1800-38 and the CISA joint guidance on quantum-readiness both recommend risk-based approaches to PQC migration, recognizing that organizations cannot migrate all cryptographic systems simultaneously and must prioritize effectively. A quantum risk assessment provides the evidence base for prioritization decisions: each system's migration urgency is determined by measurable risk factors rather than by arbitrary ordering or organizational convenience.
The Four Risk Dimensions
Quantum risk assessment scores each cryptographic system across four dimensions. Data sensitivity is the classification of the information protected by the cryptographic system classified, sensitive, regulated, or public. Confidentiality lifetime is the duration for which the protected data must remain confidential ranging from minutes (ephemeral session data) to decades (classified government communications). System criticality is the operational and business impact of cryptographic failure ranging from low (non-production systems) to critical (essential services and safety-critical infrastructure). Regulatory context is the set of compliance obligations that affect the system NSA CNSA 2.0, OMB M-23-02, EU DORA, healthcare regulations, financial regulations.
Each dimension is scored independently, and the scores are combined to produce an overall migration priority for each cryptographic system. Systems with high scores across all four dimensions receive the highest migration priority. Systems with high scores in one or two dimensions and low scores in others require more nuanced prioritization. The scoring framework ensures that the highest-risk systems receive resources first, regardless of which team owns them or how visible they are in normal operations.
Data Sensitivity: Classifying Information Assets
Data sensitivity classification assigns each cryptographic system to a sensitivity tier based on the nature of the data it protects. The highest tier includes classified government data, defense information, intelligence product, and personally identifiable information (PII) at scale. The second tier includes regulated business data (healthcare records under HIPAA, financial data under PCI-DSS or GLBA, legal records subject to privilege), commercially sensitive information (trade secrets, M&A planning, strategic roadmaps), and critical infrastructure operational data.
Lower tiers include internal business data without specific regulatory requirements, operational data for non-critical systems, and public or semi-public information. The sensitivity tier directly affects harvest-now risk: a nation-state adversary collecting traffic for future decryption prioritizes high-sensitivity targets. Data without long-term sensitivity value session logs, anonymized analytics, publicly accessible content has low HNDL risk regardless of other factors, because the adversary gains little value from decrypting it in the future.
Confidentiality Lifetime: The Most Important Variable
Confidentiality lifetime is the single most important variable in quantum risk assessment. HNDL risk is a direct function of how long data must remain confidential: if data's confidentiality requirement expires before a quantum computer capable of decrypting it is available, the HNDL risk is limited. If data must remain confidential for longer than that window, HNDL exposure exists today for every day that data is transmitted using classical key exchange.
Confidentiality lifetime varies dramatically across data categories. Session data in a consumer web application may have a practical confidentiality lifetime of hours or days. A financial transaction record may need to remain confidential for seven to ten years under regulatory retention requirements. A patient health record may have a confidentiality requirement spanning the patient's lifetime. State secrets and intelligence product may have declassification timelines of 25 years or more. Each category should be assessed independently rather than applying uniform lifetime assumptions across all data types.
System Criticality Assessment
System criticality measures the operational and business impact of cryptographic failure in a given system. Critical infrastructure systems power grid management, water treatment control, financial market infrastructure, aviation control systems have the highest criticality because cryptographic failure in these contexts could affect public safety or financial stability. Revenue-critical business systems production e-commerce platforms, payment processing, core banking systems occupy the next tier.
System criticality also affects migration urgency for reasons beyond HNDL risk. If a cryptographic system is critical enough that cryptographic failure would cause a major operational incident, even a low-probability quantum cryptographic attack justifies aggressive migration timelines. Conversely, non-production systems, development environments, and archived systems with low operational impact may receive lower priority even if they use classical cryptography, because the consequence of their cryptographic exposure is limited.
Regulatory and Compliance Context
Regulatory context adds mandatory constraints to the risk scoring framework. NSA CNSA 2.0 requirements apply to National Security Systems and specify not just algorithm requirements but timelines making compliance a binding migration deadline rather than a risk-based recommendation. OMB M-23-02 creates similar binding requirements for U.S. federal civilian agencies. Systems in scope for these requirements receive elevated migration priority regardless of other risk scores, because non-compliance has direct legal and operational consequences.
European organizations face requirements from DORA (Regulation 2022/2554), which requires financial entities to manage ICT risks including cryptographic resilience. ETSI TR 103 619 provides European organizations with technical migration guidance. Healthcare organizations in the U.S. should consider HIPAA's requirements for protecting the confidentiality and integrity of protected health information as context for assessing cryptographic systems handling patient data. Financial institutions should consider the long retention requirements and audit obligations that extend data confidentiality lifetimes significantly.
“Financial entities shall ensure that ICT systems and tools are resilient and manage all relevant ICT risks in accordance with the requirements set out in this Regulation, including cryptographic risks arising from the evolution of computing capabilities.”
The HNDL Risk Scoring Model
HNDL risk scoring combines data sensitivity and confidentiality lifetime into a composite exposure score. The highest HNDL risk accrues to systems that protect high-sensitivity data with long confidentiality lifetimes: classified government communications (high sensitivity, decades-long lifetime), patient genomic data (high sensitivity, permanent lifetime), long-term financial archives (high sensitivity, decade-long lifetime). Medium HNDL risk applies to regulated data with medium-term confidentiality requirements. Low HNDL risk applies to short-lived or low-sensitivity data.
The HNDL exposure score for each system is calculated as a function of daily data volume times data sensitivity weight times confidentiality lifetime. Systems generating high volumes of high-sensitivity, long-lived data accumulate HNDL risk faster than lower-volume or lower-sensitivity systems. Urgent HNDL remediation deploying hybrid ML-KEM for key exchange can reduce HNDL exposure to near-zero for traffic generated after deployment, but cannot retroactively protect traffic collected before migration. This forward-only remediation characteristic makes early deployment especially valuable.
Assessing Key Exchange Risk
Key exchange risk assessment evaluates every system that uses ECDH, RSA key transport, or Diffie-Hellman for session key establishment. Each endpoint's TLS key exchange algorithm, the sensitivity of the data transmitted, and the confidentiality lifetime of that data together determine the HNDL exposure. TLS endpoints using ECDHE (ephemeral ECDH) are vulnerable to HNDL despite providing Perfect Forward Secrecy against classical threats, because an adversary with future quantum capabilities can recover ephemeral keys from archived TLS handshake records.
Key exchange risk assessment should inventory every TLS server, VPN endpoint, SSH server, and encrypted messaging service in the organization's estate. For each, determine the key exchange algorithm in use, the data sensitivity of traffic served, and the confidentiality lifetime. High-sensitivity endpoints with long confidentiality lifetimes receive the highest migration priority. The migration action for key exchange risk is deploying hybrid ML-KEM, which can typically be accomplished through TLS library and configuration updates without application-level changes.
Assessing Signature and Certificate Risk
Signature risk differs from HNDL risk in its time horizon. Forging a digital signature requires a quantum computer at the time of attack, not at the time of signing. The risk for signatures is therefore more future-contingent: if a capable quantum computer does not arrive before an organization completes its signature infrastructure migration, no signature forgery attacks occur. However, long-lived trust anchors root CA certificates valid for 20-30 years may be at risk if quantum computers arrive during their validity period.
Signature risk assessment prioritizes systems where signature compromise would have the most severe consequences: root certificate authorities whose compromise would invalidate all certificates signed under them, code signing infrastructure where signature forgery enables malicious code distribution, and firmware signing roots embedded in hardware that cannot be quickly updated. These systems should be migrated to ML-DSA or SLH-DSA even before quantum hardware presents an immediate threat, because the migration of these systems is itself slow and complex.
Assessing Third-Party and Supply Chain Risk
Supply chain cryptographic risk is frequently underestimated. Third-party software, cloud services, and SaaS platforms that process or transmit sensitive organizational data on the organization's behalf inherit the organization's data sensitivity classification. If a SaaS platform uses ECDH for its API connections and does not have a published PQC migration roadmap, data flowing through that platform faces HNDL exposure that the organization cannot directly control.
Supply chain risk assessment involves requesting vendor cryptographic disclosures what algorithms are used for key exchange, data encryption, and signatures in the vendor's infrastructure and evaluating vendor PQC migration timelines against the organization's own risk profile. CNSA 2.0 requires that National Security System operators assess their supply chains for cryptographic compliance, not only their internally operated systems. For all organizations, contract language requiring vendor PQC migration commitments is an increasingly important procurement consideration.
Risk Score Aggregation and Prioritization
Each CBOM entry receives scores on all four risk dimensions, which are combined using a weighted formula appropriate to the organization's specific threat model and regulatory context to produce an overall migration priority score. Systems with the highest priority scores form the first migration phase; medium-priority systems form subsequent phases. The scoring framework should be documented and consistently applied so that prioritization decisions are defensible and can be explained to auditors, regulators, and leadership.
Risk score aggregation should also account for migration dependencies: a high-priority web application cannot complete its TLS migration to ML-KEM until the intermediate CA serving its certificates has migrated to an algorithm compatible with hybrid TLS. The migration roadmap must sequence dependent systems correctly. Dependency mapping is typically done alongside risk scoring and produces a directed graph of migration dependencies that constrains the ordering of work items regardless of their individual priority scores.
Regulatory Frameworks and Migration Timelines
NSA CNSA 2.0, released in September 2022, provides the most specific timeline requirements of any published PQC guidance. CNSA 2.0 specifies algorithm requirements for National Security Systems by system type (software and firmware, networking equipment, operating systems, browsers and applications) and sets the requirement that CNSA 2.0 algorithms be used exclusively by 2033 for most categories, with earlier requirements for specific system types. Organizations subject to CNSA 2.0 must align their risk assessment and migration roadmap with these timelines.
OMB M-23-02 requires U.S. federal agencies to submit inventories of vulnerable systems and prioritized migration plans. CISA's PQC initiative provides supporting resources and guidance for federal agencies. For commercial organizations, while binding regulatory deadlines are fewer, the NIST, CISA, and NSA joint guidance on quantum-readiness provides a risk-based framework that can be adapted to any organization's compliance and governance requirements. ETSI TR 103 619 provides European organizations with a migration strategy framework aligned with European regulatory requirements.
Repeating the Assessment: Ongoing Risk Management
A quantum risk assessment is not a one-time exercise. The risk landscape changes as quantum computing capabilities evolve, as new systems are deployed, as supply chain dependencies change, and as regulatory requirements are updated. An assessment conducted in 2024 may not accurately reflect the risk profile of a technology estate that has grown, changed vendors, or added new services by 2026. Refreshing the assessment annually or after major technology changes maintains the accuracy of the risk picture.
Ongoing monitoring provides early warning of risk changes: new CBOM entries created by system additions, changes in vendor cryptographic disclosures, updates to regulatory requirements, or changes in the quantum computing threat landscape (such as published advances in fault-tolerant quantum hardware). NIST, NSA, and CISA publish updated guidance as the post-quantum transition progresses; organizations should track these updates and assess their implications for the migration program's scope and timeline.
References
- [1]
- [2]
- [3]NSANSA CNSA 2.0(2022)Commercial National Security Algorithm Suite 2.0
- [4]OMBOMB M-23-02(2022)Memorandum on Migrating to Post-Quantum Cryptography
- [5]CISACISA PQC Initiative(2022)Post-Quantum Cryptography Initiative
- [6]CISACISA/NSA/NIST Joint Guidance(2023)Quantum-Readiness: Migration to Post-Quantum Cryptography
- [7]ETSIETSI TR 103 619(2022)Quantum-Safe Cryptography; Migration and Co-existence
- [8]EUEU DORA (Regulation 2022/2554)(2022)Digital Operational Resilience Act
Related Guides
Complete Guide to Post-Quantum Cryptography
A comprehensive reference covering why classical public-key cryptography is being replaced, the NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA), the harvest-now decrypt-later threat, and how to plan and execute a cryptographic migration program.
What Is Harvest Now Decrypt Later?
Harvest-now, decrypt-later (HNDL) is the most immediate cryptographic risk requiring action before quantum computers exist at scale. This guide explains how HNDL attacks work, what data is most exposed, and why cryptographic migration cannot wait.
ML-KEM Explained
ML-KEM (NIST FIPS 203) is the primary post-quantum key encapsulation mechanism, replacing RSA and ECDH in TLS, VPNs, and SSH. This guide explains how it works, its parameter sets, hybrid deployment, and migration from ECDH.