Quantum Risk Scoring Methodology: How to Prioritize Cryptographic Migration

Why Quantum Risk Scoring Matters

Every enterprise has hundreds to thousands of cryptographic assets — algorithms, certificates, protocols, and keys spread across their infrastructure. When facing the post-quantum migration imperative, the fundamental question is not “what needs to change” (answer: everything using RSA/ECC) but rather “what needs to change first.”

Quantum risk scoring provides the answer by assigning a quantified risk value to each cryptographic asset based on multiple factors. This transforms an overwhelming migration challenge into a prioritized, actionable backlog.

The Problem Without Risk Scoring

Without quantified risk scoring, organizations face:

Paralysis: The scale of migration is so large that teams don’t know where to start
Misallocation: Resources spent on low-risk systems while critical exposures go unaddressed
False urgency: Treating all quantum-vulnerable crypto as equally urgent
Compliance gaps: Inability to justify prioritization decisions to auditors
Budget battles: No data-driven basis for requesting migration funding

What Good Risk Scoring Enables

Capability	Business Value
Prioritized backlog	Teams work on highest-risk items first
Resource justification	Quantified risk supports budget requests
Compliance evidence	Documented methodology satisfies auditors
Progress tracking	Risk score reduction demonstrates migration value
Decision support	Data-driven tradeoffs between competing priorities
Vendor conversations	Prioritization guides where to pressure vendors

The Six Risk Factors

Quantum risk scoring considers six primary factors that together determine the urgency and potential impact of each cryptographic asset’s quantum vulnerability.

Factor 1: Algorithm Vulnerability

The most fundamental factor — how vulnerable is this specific algorithm to quantum attack?

Algorithm Category	Vulnerability Score	Rationale
RSA (all sizes)	10	Completely broken by Shor’s algorithm
ECDSA / ECDH (all curves)	10	Completely broken by Shor’s algorithm
DH / DSA (all sizes)	10	Completely broken by Shor’s algorithm
AES-128	3	Reduced to 64-bit security by Grover’s (weak but not broken)
AES-192	1	Reduced to 96-bit security (still adequate)
SHA-256	1	Reduced collision resistance but still practical
AES-256	0	128-bit post-quantum security (adequate)
SHA-384 / SHA-512	0	Adequate post-quantum security
ML-KEM / ML-DSA / SLH-DSA	0	Designed for quantum resistance

Scoring logic: If the algorithm is directly broken by Shor’s algorithm, it receives the maximum vulnerability score of 10. Algorithms with reduced (but still adequate) security under Grover’s algorithm receive lower scores. Quantum-safe algorithms score 0.

Factor 2: Data Sensitivity

How sensitive is the data protected by this cryptographic asset?

Classification	Sensitivity Score	Examples
Top Secret / State secrets	10	Classified intelligence, military plans
Secret / Highly restricted	8	Defense contractor data, critical infrastructure
Confidential / Restricted	6	Trade secrets, M&A communications, PII
Internal / Business sensitive	4	Internal strategy, financial projections
Internal / General	2	General business communications
Public / Non-sensitive	0	Published data, public communications

Scoring guidance: Score based on the most sensitive data protected by this cryptographic instance. If a TLS connection carries a mix of sensitivity levels, score at the highest level present.

Factor 3: Retention Period (Data Lifetime)

How long must the protected data remain confidential?

Retention Requirement	Retention Score	Examples
50+ years	10	State secrets, certain military data
25-50 years	8	Long-classified intelligence, genomic data
10-25 years	6	Trade secrets, long-term IP, medical records
5-10 years	4	Financial records, competitive strategy
1-5 years	2	Current operations, short-term plans
< 1 year	1	Ephemeral sessions, temporary data
No confidentiality need	0	Public information, already disclosed

Critical insight: Data with retention requirements exceeding the estimated CRQC timeline is at direct HNDL risk today. The retention score heavily influences overall quantum risk because long-lived data faces the greatest retroactive decryption threat.

Factor 4: HNDL Exposure

What is the likelihood that encrypted data has been or is being captured by adversaries for future quantum decryption?

Exposure Level	HNDL Score	Criteria
Known adversary interest	10	Organization is a known intelligence target, nation-state adversary confirmed active
High probability of interception	8	Data traverses international networks, high-value sector (defense, government, finance)
Moderate interception risk	6	Data crosses organizational boundaries over public internet
Low interception risk	4	Private circuits, limited exposure, non-targeted sector
Minimal exposure	2	Data stays within controlled private infrastructure
No transit exposure	0	Air-gapped, no network transmission of encrypted data

Assessment methodology:

Consider the organization’s threat model and sector
Evaluate network paths (internet transit vs. private circuits)
Consider geographic routing (crosses adversary-controlled infrastructure?)
Factor in data value to potential adversaries
Consider volume and consistency of collection opportunity

Factor 5: System Criticality

How critical is the system hosting this cryptographic asset to business operations and security?

Criticality Level	Criticality Score	Criteria
Mission-critical / Safety	10	System failure causes safety risk, regulatory breach, or catastrophic business impact
Core business operations	8	Primary revenue systems, essential services, customer-facing platforms
Important supporting systems	6	Internal tools with broad impact, development infrastructure
Standard business systems	4	Department-level tools, non-critical applications
Low-impact systems	2	Testing, development, archival systems
Non-operational	0	Decommissioned, experimental, unused

Why system criticality matters: High-criticality systems face both higher consequence of quantum compromise AND greater complexity in migration (stricter change windows, more testing required, higher rollback risk).

Factor 6: Remediation Complexity

How difficult is it to migrate this specific cryptographic asset to quantum-safe alternatives?

Complexity Level	Complexity Score	Characteristics
System replacement required	10	Hardware with no PQC firmware path, end-of-life vendor
Multi-party coordination	8	Protocol changes requiring partner/ecosystem agreement
Code-level refactoring	6	Application code changes needed, no crypto-agility
Library/framework upgrade	4	Update dependency and configuration
Configuration change	2	Change cipher suite or algorithm in config file
Already crypto-agile	1	Config update only, system designed for algorithm change

Note on scoring direction: Higher complexity scores indicate greater risk — because complex migrations take longer, increasing the window of exposure. This factor represents the “time to remediate” component of risk.

The Quantum Risk Scoring Formula

Composite Risk Score Calculation

Quantum Risk Score = 
  (Algorithm Vulnerability × Weight_AV) +
  (Data Sensitivity × Weight_DS) +
  (Retention Period × Weight_RP) +
  (HNDL Exposure × Weight_HE) +
  (System Criticality × Weight_SC) +
  (Remediation Complexity × Weight_RC)

Where:
  Weight_AV = 0.25 (Algorithm vulnerability is fundamental)
  Weight_DS = 0.20 (Data sensitivity drives consequence)
  Weight_RP = 0.20 (Retention period determines HNDL relevance)
  Weight_HE = 0.15 (HNDL exposure is the active threat)
  Weight_SC = 0.10 (System criticality affects both risk and migration difficulty)
  Weight_RC = 0.10 (Remediation complexity extends exposure window)

Maximum Possible Score

Maximum = (10 × 0.25) + (10 × 0.20) + (10 × 0.20) + (10 × 0.15) + (10 × 0.10) + (10 × 0.10)
        = 2.5 + 2.0 + 2.0 + 1.5 + 1.0 + 1.0
        = 10.0

Risk Level Classification

Score Range	Risk Level	Action Required
8.0 - 10.0	Critical	Immediate migration required (highest priority)
6.0 - 7.9	High	Migration within 12 months
4.0 - 5.9	Medium	Migration within 24 months
2.0 - 3.9	Low	Migration within compliance timeline
0.0 - 1.9	Minimal	Monitor, address in standard maintenance

Scoring Examples

Example 1: Government VPN (Critical Risk)

A VPN connection between government facilities using IKEv2 with ECDH P-384:

Factor	Score	Rationale
Algorithm Vulnerability	10	ECDH broken by Shor’s algorithm
Data Sensitivity	10	Classified government communications
Retention Period	10	50-year classification period
HNDL Exposure	10	Known nation-state targeting of government comms
System Criticality	10	Mission-critical government operations
Remediation Complexity	4	IKEv2 supports PQC via RFC 9370

Composite Score: (10×0.25) + (10×0.20) + (10×0.20) + (10×0.15) + (10×0.10) + (4×0.10) = 9.4 (Critical)

Example 2: E-Commerce TLS (Medium Risk)

A retail website using TLS 1.3 with X25519 key exchange:

Factor	Score	Rationale
Algorithm Vulnerability	10	X25519 (ECDH) broken by Shor’s
Data Sensitivity	4	Payment data (PCI), customer accounts
Retention Period	2	Transaction data retained 2-3 years
HNDL Exposure	4	Internet-facing but not nation-state target
System Criticality	8	Primary revenue system
Remediation Complexity	2	TLS config change (add hybrid)

Composite Score: (10×0.25) + (4×0.20) + (2×0.20) + (4×0.15) + (8×0.10) + (2×0.10) = 5.5 (Medium)

Example 3: Internal HR Application (Low Risk)

An internal HR portal using TLS 1.2 with RSA-2048 key exchange:

Factor	Score	Rationale
Algorithm Vulnerability	10	RSA broken by Shor’s
Data Sensitivity	4	Employee PII (regulated but not classified)
Retention Period	4	Employee records retained 7 years post-employment
HNDL Exposure	2	Internal network only, low external exposure
System Criticality	4	Standard business system
Remediation Complexity	2	TLS config update

Composite Score: (10×0.25) + (4×0.20) + (4×0.20) + (2×0.15) + (4×0.10) + (2×0.10) = 5.0 (Medium)

Example 4: Development Environment (Minimal Risk)

A development server using SSH with ECDSA P-256 host keys:

Factor	Score	Rationale
Algorithm Vulnerability	10	ECDSA broken by Shor’s
Data Sensitivity	2	Development code (non-production)
Retention Period	1	Ephemeral sessions
HNDL Exposure	2	Internal network, non-targeted
System Criticality	2	Development environment
Remediation Complexity	2	SSH config change

Composite Score: (10×0.25) + (2×0.20) + (1×0.20) + (2×0.15) + (2×0.10) + (2×0.10) = 3.7 (Low)

Prioritization Framework

Risk-Based Migration Waves

Use composite risk scores to define migration waves:

┌────────────────────────────────────────────────────┐
│           Migration Wave Assignment                 │
├────────────────────────────────────────────────────┤
│                                                     │
│  Wave 1 (Immediate): Score 8.0-10.0               │
│  ├── Government/military systems                   │
│  ├── Long-lived classified data flows              │
│  ├── Known HNDL-targeted communications            │
│  └── Timeline: Start immediately, complete 12 mo   │
│                                                     │
│  Wave 2 (Urgent): Score 6.0-7.9                   │
│  ├── Financial systems with PCI requirements       │
│  ├── Healthcare with genomic/long-term data        │
│  ├── IP-heavy research communications              │
│  └── Timeline: Start within 6 months, complete 24  │
│                                                     │
│  Wave 3 (Planned): Score 4.0-5.9                  │
│  ├── Customer-facing services                      │
│  ├── Internal business applications                │
│  ├── Standard compliance-driven migrations         │
│  └── Timeline: Plan now, execute within 36 months  │
│                                                     │
│  Wave 4 (Scheduled): Score 2.0-3.9               │
│  ├── Low-sensitivity internal systems              │
│  ├── Development and testing environments          │
│  ├── Systems approaching end-of-life               │
│  └── Timeline: Include in standard maintenance     │
│                                                     │
│  Wave 5 (Monitor): Score 0.0-1.9                  │
│  ├── Already quantum-safe systems                  │
│  ├── Non-sensitive public systems                  │
│  └── Timeline: Verify and maintain                 │
│                                                     │
└────────────────────────────────────────────────────┘

Tie-Breaking Criteria

When multiple assets have similar risk scores, use secondary criteria to determine order:

Compliance deadline proximity: Assets tied to CNSA 2.0 January 2027 gate first
Dependency chains: Assets that block other migrations go first
Quick wins: Among equally scored assets, address easy ones first (config changes before code rewrites)
Organizational readiness: Assets owned by teams already trained in PQC
Vendor availability: Assets where vendor PQC support is already available

Integration with CBOM

Automated Risk Scoring in CBOM

The quantum risk scoring methodology integrates directly with CBOM through enriched component metadata:

{
  "type": "crypto-asset",
  "bom-ref": "crypto-rsa2048-payment-api",
  "name": "RSA-2048 (Payment API Key Exchange)",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "pke",
      "variant": "RSA",
      "parameterSetIdentifier": "2048",
      "nistQuantumSecurityLevel": 0
    }
  },
  "properties": [
    {"name": "qrs:algorithm-vulnerability", "value": "10"},
    {"name": "qrs:data-sensitivity", "value": "6"},
    {"name": "qrs:retention-period", "value": "6"},
    {"name": "qrs:hndl-exposure", "value": "6"},
    {"name": "qrs:system-criticality", "value": "8"},
    {"name": "qrs:remediation-complexity", "value": "4"},
    {"name": "qrs:composite-score", "value": "7.1"},
    {"name": "qrs:risk-level", "value": "high"},
    {"name": "qrs:migration-wave", "value": "2"},
    {"name": "qrs:recommended-replacement", "value": "ML-KEM-1024"},
    {"name": "qrs:compliance-deadline", "value": "2027-01-01"},
    {"name": "qrs:assessment-date", "value": "2026-06-10"}
  ]
}

QCecuring CBOM Risk Scoring Integration

QCecuring CBOM integrates quantum risk scoring directly into the CBOM generation process:

Automated algorithm scoring: Algorithm vulnerability factor is automatically assigned based on detected algorithm type
Context enrichment: Data sensitivity and system criticality are enriched from organizational metadata (CMDB, data classification systems)
HNDL modeling: Network exposure analysis automatically estimates HNDL risk based on traffic patterns
Remediation assessment: Complexity scoring based on detected architecture and crypto-agility level
Continuous recalculation: Scores update automatically as new assets are discovered or context changes

Organizations deploying QCecuring CBOM get risk-scored inventories from day one, with the ability to customize weights and scoring criteria to match their organizational risk appetite.

Customizing the Methodology

Adjusting Weights

Different organizations may weight factors differently based on their threat model:

Government/Defense (highest HNDL concern):

Weight_AV = 0.20
Weight_DS = 0.15
Weight_RP = 0.25  ← Elevated (long classification periods)
Weight_HE = 0.25  ← Elevated (active nation-state targeting)
Weight_SC = 0.10
Weight_RC = 0.05

Financial Services (compliance-driven):

Weight_AV = 0.25
Weight_DS = 0.25  ← Elevated (financial data sensitivity)
Weight_RP = 0.15
Weight_HE = 0.10
Weight_SC = 0.15  ← Elevated (transaction system criticality)
Weight_RC = 0.10

Healthcare (data lifetime concern):

Weight_AV = 0.20
Weight_DS = 0.20
Weight_RP = 0.30  ← Elevated (genomic data = patient lifetime)
Weight_HE = 0.10
Weight_SC = 0.10
Weight_RC = 0.10

Adding Custom Factors

Organizations may add sector-specific risk factors:

Regulatory exposure: Specific penalties for non-compliance (e.g., PCI DSS fines)
Revenue impact: Direct revenue at risk if this system is compromised
Reputational sensitivity: Public-facing systems where breach visibility is high
Insurance implications: Cyber insurance requirements and coverage gaps
Supply chain position: Assets that affect downstream partners if compromised

Threshold Calibration

Adjust risk level thresholds based on organizational risk appetite:

# Conservative (risk-averse organization)
critical_threshold: 7.0
high_threshold: 5.0
medium_threshold: 3.0
low_threshold: 1.5

# Standard (balanced approach)
critical_threshold: 8.0
high_threshold: 6.0
medium_threshold: 4.0
low_threshold: 2.0

# Aggressive (high risk tolerance)
critical_threshold: 9.0
high_threshold: 7.0
medium_threshold: 5.0
low_threshold: 3.0

Operationalizing Risk Scoring

Governance Model

Activity	Frequency	Responsible
Risk methodology review	Annually	CISO / Risk Committee
Weight calibration	Semi-annually	Security Architecture
Score recalculation	Continuous (automated)	CBOM Platform
Score validation (manual)	Quarterly	System owners + Security
Migration wave planning	Quarterly	PQC Program Office
Progress reporting	Monthly	PQC Program Manager
Executive briefing	Quarterly	CISO → Board

Reporting Framework

Executive Dashboard:

Total quantum risk exposure (sum of all scores × system value)
Risk trend over time (decreasing score = successful migration)
Migration progress by wave
Compliance deadline tracking

Operational Reports:

Top 20 highest-risk assets requiring immediate attention
New assets introduced with high risk scores (regression detection)
Assets migrated this period (removed from high-risk)
Upcoming compliance deadlines with affected asset counts

Compliance Evidence:

Methodology documentation (this framework)
Scoring justification per asset
Risk acceptance documentation for deferred items
Audit trail of score changes and migration actions

Triggering Score Recalculation

Risk scores should be recalculated when:

New cryptographic assets are discovered
Data classification changes
Threat intelligence updates HNDL exposure assessment
CRQC timeline estimates change materially
System criticality changes (new revenue system, decommission)
Remediation progress changes complexity scores (e.g., library upgrade now available)
Organizational context changes (new regulation, acquisition, etc.)

Common Challenges

Challenge: Subjectivity in Scoring

Some factors (data sensitivity, HNDL exposure) involve judgment. Mitigate by:

Using standardized data classification as input (not ad-hoc assessment)
Documenting scoring rationale for each asset
Having scores validated by system owners and security architects
Calibrating through peer comparison (similar assets should score similarly)

Challenge: Scale

Enterprises may have thousands of cryptographic assets to score. Address by:

Automating algorithm vulnerability scoring (fully deterministic)
Inheriting data sensitivity from data classification systems
Using system-level defaults for criticality and retention
Applying bulk scoring to asset categories before individual refinement
Using QCecuring CBOM’s automated scoring for initial baseline

Challenge: Dynamic Environments

Cloud-native environments change continuously. Handle by:

Continuous CBOM generation (not periodic scans)
Scoring rules applied automatically to new discoveries
Alert thresholds for new high-risk introductions
CI/CD gates preventing deployment of high-risk cryptography

Challenge: Organizational Buy-In

Risk scores only matter if acted upon. Build support by:

Tying scores to compliance deadlines (CNSA 2.0, PCI DSS 4.0)
Showing financial exposure (potential breach cost × probability)
Comparing to peer organizations’ posture (where data available)
Demonstrating score reduction over time as proof of program value

Key Takeaways

Quantified risk scoring transforms PQC migration from overwhelming to manageable — prioritized backlogs enable focused action
Six factors capture the full risk picture — algorithm vulnerability, data sensitivity, retention period, HNDL exposure, system criticality, and remediation complexity
Weighted scoring reflects organizational priorities — customize weights for your sector and threat model
CBOM integration enables automation — risk scores embedded in CBOM drive automated prioritization and alerting
QCecuring CBOM provides automated risk scoring — integrated with discovery to deliver risk-scored inventories from day one
Classification drives migration waves — Critical/High/Medium/Low maps directly to migration timelines
Continuous recalculation is essential — risk scores change as new assets appear, context shifts, and migrations complete
Governance makes scoring operational — clear ownership, review cadence, and reporting ensure scores drive action
Customize for your organization — the framework is adaptable; adjust weights, thresholds, and factors to your context
Document everything — scoring methodology, rationale per asset, and risk acceptance decisions provide audit evidence