Quantum risk assessment: scoring exposure and data longevity
Not every RSA key is equally urgent. A quantum risk assessment ranks cryptographic assets by how long their protection must last, how exposed they are and how hard they are to change.
- Mosca's inequality frames the question: if data shelf-life plus migration time exceeds the time until current public-key cryptography is broken, there is a problem today.
- Key establishment protecting long-lived data carries harvest-now risk; signatures matter most where roots of trust are long-lived or hard to replace.
- Score assets on data longevity, exposure, cryptographic function, migration difficulty and business criticality.
- CERT-In recommends a risk-based approach guided by threat exposure, technical feasibility and risk tolerance.
- The output is a priority tier per asset that feeds the migration plan.
The framing: Mosca's inequality
In a 2015 paper, Michele Mosca set out a simple test. Let x be how long information must remain secure, y how long it will take to deploy quantum-safe tools and z how long until a quantum computer or other method breaks the deployed public-key cryptography. "If x + y > z, we have a serious problem today" [1]. India's TEC technical report on PQC migration applies the same model [2].
You control x through data retention and y through engineering. You do not control or reliably know z, and this assessment does not depend on predicting it. Instead it ranks assets so that those with the largest x + y are migrated first.
What CERT-In asks for
CERT-In recommends a risk-based approach to quantum readiness that includes cryptographic validation testing, independent security assessments, adversarial simulations and continuous threat intelligence, and says implementation should be guided by threat exposure, technical feasibility and the organisation's risk tolerance [3]. It also recommends periodic risk assessments for systems involving cryptographic or quantum components [3].
The factors
| Factor | Question | Why it matters |
|---|---|---|
| Data longevity | How long must the protected data stay confidential, or the signature stay trustworthy? | The x in Mosca's inequality; the CISA, NSA and NIST factsheet asks organisations to document protection lengths for sensitive data sets [4] |
| Cryptographic function | Key establishment, encryption or signature? | The NCSC notes that for key establishment and encryption there is a risk from data collected today and decrypted later [5] |
| Exposure | Does traffic cross public or partner networks? | Canada's roadmap flags systems protecting confidentiality across public networks as facing earlier harvest-now risk [6] |
| Migration difficulty | Is it configuration, code, hardware or a partner protocol? Who controls it? | The y in Mosca's inequality; embedded and vendor-controlled cryptography takes longest |
| Business criticality | What service depends on it, and what is the impact of compromise? | Aligns priority with business impact |
Signatures and roots of trust
Harvest-now risk applies mainly to confidentiality. Signatures are different: a forged signature matters only once an attacker can forge it, but some signing keys are embedded in devices and cannot be replaced after deployment. That is why CNSA 2.0 puts software and firmware signing on its earliest timeline, with exclusive use of quantum-resistant algorithms by 2030 [7]. Score long-lived roots of trust (firmware signing, device identity, PKI roots) on migration difficulty and device lifetime, not only on data confidentiality. See What is an HBOM? for the hardware side.
An example scoring model
The model below is an illustration, not a standard; adjust the weights to your risk appetite. Score each factor 1 to 3 and multiply by the weight.
| Factor | 1 | 2 | 3 | Weight |
|---|---|---|---|---|
| Data longevity | Under 5 years | 5 to 10 years | Over 10 years | 3 |
| Function | Symmetric or hash only | Signature | Key establishment or public-key encryption | 2 |
| Exposure | Internal only | Partner network | Internet | 2 |
| Migration difficulty | Configuration | Code change | Hardware, firmware or third party | 2 |
| Criticality | Low | Medium | High | 1 |
Assets that are not quantum-vulnerable (for example AES-256, which NIST does not expect to need replacing [8]) score zero and drop out. Group the rest into tiers: the top tier becomes the "highest-priority" set that the NCSC expects to be migrated by 2031 [9].
Worked examples
- Customer records replicated to a partner over TLS with ECDHE, retained for many years: high longevity, key establishment, partner exposure. Top tier; consider hybrid key exchange early.
- Internal service-to-service TLS carrying session data: low longevity, internal. Lower tier; migrate with platform upgrades.
- Firmware signing key for devices with a long field life: signature, but hardware-bound and hard to change. Top tier on migration difficulty.
Recording the result
Store the factor values, the score and the tier on each asset in the QBOM, with the date and assessor. Re-score when data retention, exposure or policy changes. The result drives the plan in Preparing for post-quantum cryptography.
How IntelliXBOM helps
IntelliXBOM correlates cryptographic assets with the components, hardware and business services that depend on them, which supplies much of the context a quantum risk assessment needs. Assessment results can be kept alongside the inventory with version history, and mapped to framework controls with timestamped evidence.
Frequently asked questions
What is Mosca's theorem?
It is a planning inequality from Michele Mosca's 2015 paper: if the time data must stay secure plus the time needed to migrate exceeds the time until current public-key cryptography is broken, there is a problem today. It is used to prioritise migration without predicting an exact date.
Are digital signatures at risk from harvest now, decrypt later?
Not in the same way as encryption, because a signature can only be forged once an attacker has the capability. Signing keys that are embedded in long-lived devices still need early attention because they are hard to replace.
Is AES quantum-vulnerable?
NIST's draft transition report says it does not expect to need to transition away from its symmetric standards such as AES, and the UK NCSC says AES with at least 128-bit keys can continue to be used. The main quantum risk is to public-key algorithms such as RSA and elliptic-curve schemes.
Sources
- Cybersecurity in an era with quantum computers: will we be ready? (Mosca, 2015)IACR Cryptology ePrint Archiveeprint.iacr.org/2015/1075.pdf
- Technical Report: Migration to Post Quantum Cryptography (TEC 910018:2025)Telecommunication Engineering Centre, DoTtec.gov.in/pdf/TR/Final%20technical%20report%20on%20migration%20to%20PQC%2028-03-25.pdf
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- Quantum-Readiness: Migration to Post-Quantum Cryptography (August 2023)CISA, NSA and NISTwww.nccoe.nist.gov/sites/default/files/2023-08/quantum-readiness-fact-sheet.pdf
- Next steps in preparing for post-quantum cryptographyUK National Cyber Security Centrewww.ncsc.gov.uk/paper/next-steps-in-preparing-for-post-quantum-cryptography
- Roadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)Canadian Centre for Cyber Securitywww.cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001
- CNSA 2.0: Complete Guide to NSA's PQC RequirementsPostQuantum.compostquantum.com/cnsa-2-0/complete-guide/
- NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards (November 2024)NISTnvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
- Timelines for migration to post-quantum cryptography (20 March 2025)UK National Cyber Security Centrewww.ncsc.gov.uk/guidance/pqc-migration-timelines
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.