Cryptography, Quantum Risk, and PQC Migration — Operating Quantum Computers

A book about operating quantum computers should also cover what quantum computers do to existing infrastructure. Cryptographic risk is not a future-only concern. Organizations with long-lived sensitive data need to account for “harvest now, decrypt later” exposure, dependency chains, certificates, firmware, protocols, suppliers, and slow-moving embedded systems.

NIST released the first three finalized post-quantum cryptography standards in August 2024: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA [R58]. NIST’s FIPS 203 page describes ML-KEM and its three parameter sets [R59]. CISA, NSA, and NIST have also published quantum-readiness migration guidance for organizations preparing for post-quantum cryptography [R60].

30.1 Quantum risk model

Diagram loads as you read

30.1 Quantum risk model · Figure 1

View diagram source

flowchart TB
    Quantum[Cryptographically relevant quantum computer] --> PublicKey[Public-key cryptography risk]
    PublicKey --> KeyExchange[Key exchange]
    PublicKey --> Signatures[Digital signatures]
    KeyExchange --> Confidentiality[Confidentiality exposure]
    Signatures --> Integrity[Integrity and identity exposure]
    Confidentiality --> HNDL[Harvest now, decrypt later]

The operational question is not “when will a cryptographically relevant quantum computer exist?” The operational question is:

Which assets must remain confidential or trustworthy long enough that migration delay creates unacceptable risk?

30.2 Cryptographic inventory

A migration cannot start without an inventory. The inventory needs to connect cryptography to assets, owners, data classes, protocols, libraries, certificates, vendors, and replacement paths.

Diagram loads as you read

30.2 Cryptographic inventory · Figure 2

View diagram source

erDiagram
    ASSET ||--o{ CRYPTO_USE : contains
    CRYPTO_USE ||--o{ ALGORITHM : uses
    CRYPTO_USE ||--o{ CERTIFICATE : depends_on
    CRYPTO_USE ||--o{ LIBRARY : implemented_by
    ASSET ||--o{ DATA_CLASS : protects
    ASSET ||--o{ OWNER : owned_by
    ASSET ||--o{ VENDOR : supplied_by

Inventory schema:

Illustrative listing · yaml

crypto_inventory_item:
  asset_id: string
  owner: string
  environment: prod|staging|dev|lab|embedded
  data_classification: public|internal|confidential|regulated|mission_critical
  cryptographic_use: key_exchange|signature|encryption|certificate|firmware_signing|other
  algorithm: string
  key_size: string|null
  protocol: string|null
  library_or_product: string
  vendor: string|null
  certificate_authority: string|null
  data_lifetime_years: int|null
  migration_status: unknown|inventory|planned|testing|migrated|exception

30.3 Data lifetime and migration urgency

Urgency depends on the lifetime of the data, the exposure model, and the time required to migrate.

Diagram loads as you read

30.3 Data lifetime and migration urgency · Figure 3

View diagram source

flowchart LR
    DataLife[Data confidentiality lifetime] --> Risk[Quantum exposure risk]
    MigrationTime[Migration lead time] --> Risk
    Adversary[Adversary collection capability] --> Risk
    Risk --> Priority[Migration priority]

Priority model:

Factor	High-risk signal
data lifetime	data must remain confidential for many years
exposure	traffic or artifacts can be captured by adversaries
dependency depth	many vendors, devices, or certificate chains
change velocity	embedded, regulated, or hard-to-update systems
business criticality	outage or trust failure would be severe

30.4 Migration factory

PQC migration is not a single upgrade. It is a factory for discovery, testing, deployment, exception handling, and monitoring.

Diagram loads as you read

30.4 Migration factory · Figure 4

View diagram source

flowchart TB
    Inventory[Inventory] --> Classify[Classify risk]
    Classify --> Plan[Migration plan]
    Plan --> Lab[Test in lab]
    Lab --> Interop[Interoperability testing]
    Interop --> Deploy[Deploy]
    Deploy --> Monitor[Monitor]
    Monitor --> Exceptions[Exception management]
    Exceptions --> Plan

Factory workstreams:

Workstream	Output
discovery	cryptographic inventory
risk classification	migration priority
vendor engagement	product roadmaps and support status
lab validation	compatibility and performance results
deployment	staged rollout and rollback procedures
exception handling	compensating controls and expiry dates
monitoring	drift and reintroduction detection

30.5 Hybrid cryptography transition

Many migrations will use hybrid approaches during transition periods. The operational goal is to reduce risk without breaking interoperability.

Diagram loads as you read

30.5 Hybrid cryptography transition · Figure 5

View diagram source

sequenceDiagram
    participant Client
    participant Server
    participant Policy as Crypto policy
    Client->>Server: propose supported algorithms
    Server->>Policy: check approved suites
    Policy-->>Server: allowed classical + PQC / hybrid option
    Server-->>Client: negotiate suite
    Client->>Server: establish protected session

Policy needs to capture:

Policy item	Example decision
approved algorithms	ML-KEM parameter set, signature scheme
fallback behavior	allowed only for specific partners
certificate strategy	hybrid certificates, parallel chains, or staged CA migration
telemetry	negotiated algorithm and version logged
exception expiry	time-boxed, reviewed, owner assigned

30.6 Firmware and supply-chain risk

Signatures protect firmware, update packages, containers, SBOMs, build artifacts, and operational commands. These systems often have slow migration cycles.

Diagram loads as you read

30.6 Firmware and supply-chain risk · Figure 6

View diagram source

flowchart TB
    Build[Build system] --> Sign[Artifact signing]
    Sign --> Registry[Registry / update server]
    Registry --> Device[Device or service]
    Device --> Verify[Signature verification]
    Verify --> Run[Run artifact]
    CA[Certificate authority] --> Sign
    CA --> Verify

Migration questions:

Question	Why it matters
Can verifiers be updated?	old devices may not support new algorithms
Can artifacts be dual-signed?	transition requires compatibility
Who controls trust anchors?	determines rollout path
What is the rollback plan?	bad crypto rollout can brick systems
What is the firmware lifetime?	long-lived assets need earlier attention

30.7 PQC governance board

Quantum risk should not sit only with research teams. It belongs in enterprise security governance.

Diagram loads as you read

30.7 PQC governance board · Figure 7

View diagram source

flowchart LR
    Security[Security] --> Board[PQC governance board]
    Platform[Platform engineering] --> Board
    Legal[Legal / compliance] --> Board
    Procurement[Procurement] --> Board
    Product[Product] --> Board
    Vendors[Vendors] --> Board
    Board --> Roadmap[Migration roadmap]

Board responsibilities:

approve algorithm policy,
maintain inventory targets,
review high-risk exceptions,
approve vendor requirements,
monitor standards and regulator expectations,
coordinate customer-facing claims,
track migration progress.

30.8 Quantum-safe claim discipline

Do not make broad claims like “quantum-proof.” Prefer specific, testable claims.

Weak claim	Stronger claim
quantum-proof security	uses NIST-standardized PQC algorithm X for use case Y
fully migrated	production TLS edge migrated for defined traffic class
future-proof	policy supports algorithm agility and staged replacement
protected from quantum attacks	risk reduced for specified confidentiality lifetime and threat model

Diagram loads as you read

30.8 Quantum-safe claim discipline · Figure 8

View diagram source

flowchart TB
    Claim[Security claim] --> Scope[Scope]
    Claim --> Algorithm[Algorithm]
    Claim --> Deployment[Deployment status]
    Claim --> Exceptions[Exceptions]
    Claim --> Evidence[Evidence]

30.9 Exception management

Some systems cannot migrate quickly. Exceptions need owners, compensating controls, and expiry dates.

Illustrative listing · yaml

pqc_exception:
  asset_id: string
  owner: string
  reason: vendor_dependency|embedded_constraint|interop|regulatory|other
  current_algorithm: string
  risk_rating: low|medium|high|critical
  compensating_controls:
    - string
  approved_until: date
  migration_dependency: string
  review_cadence: monthly|quarterly

Diagram loads as you read

30.9 Exception management · Figure 9

View diagram source

stateDiagram-v2
    [*] --> Requested
    Requested --> Approved: risk accepted
    Requested --> Rejected: unacceptable risk
    Approved --> Monitored
    Monitored --> Renewed: dependency remains
    Monitored --> Migrated: remediation complete
    Renewed --> Monitored
    Migrated --> [*]

30.10 Chapter checklist

A credible PQC program has:

cryptographic inventory,
data-lifetime classification,
algorithm policy,
vendor engagement plan,
lab interoperability tests,
deployment waves,
exception register,
telemetry for negotiated algorithms,
customer-claim review,
recurring governance.

Diagram loads as you read

30.10 Chapter checklist · Figure 10

View diagram source

flowchart LR
    Inventory[Inventory] --> Program[PQC program]
    Policy[Policy] --> Program
    Vendors[Vendors] --> Program
    Testing[Testing] --> Program
    Exceptions[Exceptions] --> Program
    Program --> RiskReduction[Measured risk reduction]