PQC Migration Playbook, Part 2: Risk Assessment

This is Part 2 of the PQC Migration Playbook. Part 1 covered cryptographic discovery and building your CBOM. This part covers risk assessment. Part 3 covers remediation and crypto-agility.

You have completed your cryptographic discovery. Your CBOM contains every algorithm, certificate, key, and protocol in your infrastructure, classified by quantum safety status. Now what?

The answer is risk assessment -- the process of scoring each cryptographic asset by its quantum exposure, determining your organization-wide migration deadline, and building the business case that gets executive leadership to fund the migration. This phase transforms raw inventory data into actionable priorities.

From Inventory to Risk: The Scoring Framework

A CBOM tells you what you have. Risk assessment tells you what matters. Not every quantum-vulnerable asset carries the same risk. An RSA-2048 key exchange on an internal development server handling ephemeral test data is a vastly different risk than the same algorithm on a production API handling patient healthcare records.

The risk assessment framework evaluates each cryptographic asset across three dimensions:

Dimension 1: Data Sensitivity and Shelf Life

For each quantum-vulnerable cryptographic asset in your CBOM, determine:

What data does this asset protect? Map the cryptographic asset to the data flows it encrypts, signs, or authenticates.
What is the confidentiality shelf life of that data? How many years must this data remain secret? This is determined by regulatory requirements, business needs, and contractual obligations.
What is the integrity shelf life? For signature algorithms, how long must the signature remain trustworthy? A code signing certificate that signs firmware for devices with a 15-year operational life has a 15-year integrity requirement.

Assign a sensitivity score from 1 (public data, no shelf life) to 10 (classified or indefinitely sensitive data with multi-decade shelf life).

Dimension 2: Exposure and Interception Probability

Not all data has the same probability of being intercepted. Assess:

Network position: Internet-facing services are at higher risk than services on an air-gapped network. An API endpoint accessible from the public internet is subject to passive interception by any adversary with access to the network path.
Traffic volume: High-traffic services present more valuable interception targets. An API handling millions of requests per day provides more data for an adversary to harvest than one handling a few requests per hour.
Known targeting: Are you in an industry or geography that is known to be targeted by nation-state HNDL operations? Defense, government, healthcare, financial services, and critical infrastructure are priority targets.

Assign an exposure score from 1 (isolated, low-traffic, not targeted) to 10 (internet-facing, high-traffic, actively targeted sector).

Dimension 3: Current Cryptographic Posture

Evaluate the current state of each asset's cryptographic configuration:

Algorithm quantum safety: Is the algorithm quantum-safe (ML-KEM, ML-DSA), hybrid (X25519+ML-KEM), or quantum-vulnerable (RSA, ECDH, ECDSA)?
Algorithm strength: Even among quantum-vulnerable algorithms, there are differences. RSA-4096 provides more classical security margin than RSA-1024.
Forward secrecy: Protocols using ephemeral key exchange (ECDHE, DHE) are somewhat less vulnerable to HNDL than those using static RSA key transport, because each session uses a different key. However, this provides no quantum protection -- it only means the adversary must break each session key individually rather than recovering one long-term key.

Assign a posture score from 1 (PQC-safe, hybrid mode deployed) to 10 (static RSA key transport with no forward secrecy).

Composite Risk Score

The composite risk score for each asset is:

Asset Risk = Sensitivity x Exposure x Posture / 10

This produces a score from 0.1 to 100 for each cryptographic asset. Assets with high sensitivity, high exposure, and poor cryptographic posture score near 100. Assets with low sensitivity, low exposure, and good posture score near zero.

Sort your CBOM by this composite risk score. The top of the list is where you start your migration.

Applying the Mosca Inequality

The Mosca Inequality provides your organizational migration deadline. If you have not read our detailed Mosca Inequality explainer, do so before proceeding.

For your organization-wide assessment:

Calculate X (migration timeline): Using your CBOM, estimate the time required to migrate all quantum-vulnerable assets to PQC. This is not the time to migrate a single TLS endpoint -- it is the time to achieve full coverage. Consider:

Number of quantum-vulnerable assets in your CBOM
Complexity of each migration (TLS configuration change vs. firmware replacement)
Organizational constraints (change management processes, testing requirements, vendor dependencies)
Staffing and budget availability
Phased rollout requirements

Determine Y (maximum shelf life): From your risk-scored CBOM, identify the maximum confidentiality shelf life across all quantum-vulnerable assets. This is your Y. If you have even one system transmitting data with a 30-year shelf life over RSA-encrypted channels, your Y is 30.

Estimate Z (CRQC timeline): Use the consensus estimate of 10-15 years, adjusted for your threat model. If you are in a sector targeted by advanced nation-states, use the optimistic end (8-10 years). If you are in a lower-risk sector, the moderate estimate (12-15 years) may be appropriate.

Evaluate the inequality: If X + Y > Z, your migration deadline has passed. The gap (X + Y - Z) represents the number of years of data that will be vulnerable -- data that has already been transmitted and potentially harvested.

Building a Board Number

Security teams often struggle to communicate cryptographic risk to executive leadership and board members. The Board Number is a single metric designed for this audience.

The Board Number combines your HNDL Score, Mosca Inequality result, and CBOM statistics into a one-page executive summary:

The Board Number Format

Quantum Risk Rating: Critical / High / Moderate / Low

Derived from your HNDL Score. This is the headline.

Migration Status: Overdue by N years / On track / Not yet required

Derived from the Mosca Inequality. If X + Y > Z, the migration is overdue by (X + Y - Z) years.

Scope of Exposure:

Metric	Value
Total cryptographic assets	4,271
Quantum-vulnerable assets	3,892 (91%)
Assets in hybrid PQC mode	47 (1%)
High-risk assets (score > 70)	312
Estimated migration duration	5 years
Budget required (estimated)	$X.XM

Key Risk Statement: "91% of our cryptographic infrastructure is vulnerable to quantum computing attacks. Data transmitted today over these systems may be decrypted when quantum computers arrive, which current estimates place within 10-15 years. Our data confidentiality requirements extend up to 30 years, meaning data transmitted today will still be sensitive when it becomes readable. Migration will take approximately 5 years, and every month of delay extends our window of vulnerability."

This format works because it translates technical risk into business language. It answers the three questions that boards care about: How bad is it? What do we need to do? What does it cost?

Prioritizing the Migration

With your risk-scored CBOM and Board Number in hand, build a prioritized migration roadmap:

Tier 1: Immediate (0-6 months)

Deploy hybrid ML-KEM key exchange on all internet-facing TLS endpoints. This is the single highest-impact action with the lowest implementation risk. It addresses the HNDL threat for your most exposed systems.
Upgrade VPN concentrators to support PQC key exchange. These protect long-lived business communications.
Begin issuing ML-DSA certificates for internal services.

Tier 2: Near-Term (6-18 months)

Migrate internal service-to-service communication to hybrid PQC key exchange.
Upgrade SSH infrastructure to PQC-compatible key exchange and host keys.
Address application-layer cryptography in high-risk applications (JWT signing, S/MIME, custom encryption).
Begin vendor engagement for systems with third-party dependencies.

Tier 3: Medium-Term (18-36 months)

Complete certificate chain migration to ML-DSA.
Address embedded systems and IoT devices that support firmware updates.
Migrate database encryption and data-at-rest protection to PQC algorithms.
Address legacy protocols (SCADA, HL7v2, legacy SOAP) where possible.

Tier 4: Long-Term (36+ months)

Replace embedded systems and HSMs that cannot be upgraded via firmware.
Complete migration of all remaining quantum-vulnerable assets.
Achieve 100% PQC coverage across all cryptographic assets.
Decommission classical-only cipher suites.

Risk Acceptance and Residual Risk

Not every quantum-vulnerable asset can or should be migrated immediately. Some will remain in a quantum-vulnerable state for years due to technical constraints, vendor dependencies, or cost considerations. For these assets, document a formal risk acceptance:

Asset identification: Which specific assets remain quantum-vulnerable?
Risk justification: Why is migration not feasible in the near term? (HSM replacement cost, vendor timeline, legacy protocol constraints)
Compensating controls: What mitigations are in place? (Network segmentation to reduce exposure, data classification to limit what transits the vulnerable channel, monitoring for anomalous traffic capture)
Review date: When will this risk acceptance be reassessed?
Residual risk owner: Who is accountable for this risk?

Risk acceptance is not risk ignorance. It is a documented decision with an owner and a review date. Every risk acceptance entry should be tracked alongside your migration progress.

Connecting Assessment to Action

The risk assessment phase produces three critical outputs:

A risk-scored CBOM that tells you which cryptographic assets to migrate first.
A Mosca Inequality calculation that tells you whether you are already behind schedule.
A Board Number that communicates the urgency to leadership and secures the budget and authority to proceed.

With these in hand, you are ready for Part 3: Remediation and Crypto-Agility, where we cover the actual migration work -- deploying PQC algorithms, managing the hybrid transition, and building an architecture that can adapt to future cryptographic changes without another multi-year migration program.

The assessment phase is where intellectual honesty matters most. It is tempting to use optimistic estimates for X, low sensitivity classifications for Y, or conservative (long) estimates for Z to avoid triggering the inequality. Resist this temptation. The math does not care about organizational comfort. The adversaries conducting HNDL operations do not care about your budget cycle. Use realistic numbers, present them clearly, and let the data drive the decision.

PQC Migration Playbook, Part 2: Risk Assessment