Quantum-Safe Operations and PQC Program Management

Operating quantum computers and preparing for quantum-safe cryptography are different programs, but they intersect at the executive and security layer. A company building or using quantum systems should not ignore the security transition caused by future cryptographically relevant quantum computers.

NIST finalized the first three post-quantum cryptography standards in 2024, and its migration work emphasizes inventory, prioritization, and roadmaps for moving away from quantum-vulnerable public-key algorithms [R32, R58, R59, R60, R72].

41.1 Separate the compute program from the security program

Diagram loads as you read

41.1 Separate the compute program from the security program · Figure 1

View diagram source

flowchart TB
    QuantumProgram[Quantum technology program] --> Compute[Quantum compute capability]
    QuantumProgram --> Security[Quantum-safe security]
    Compute --> Algorithms[Algorithms and workloads]
    Compute --> Hardware[Hardware operations]
    Security --> Inventory[Cryptographic inventory]
    Security --> Migration[PQC migration]
    Security --> Agility[Crypto agility]

Track	Main question
quantum computing	what can quantum hardware compute?
post-quantum cryptography	how do we protect systems against future quantum attacks?

The same executive sponsor may oversee both, but the workstreams need different owners and metrics.

41.2 Cryptographic inventory is the foundation

Diagram loads as you read

41.2 Cryptographic inventory is the foundation · Figure 2

View diagram source

flowchart LR
    Assets[Systems and assets] --> Discover[Discover crypto use]
    Discover --> Classify[Classify algorithms]
    Classify --> Risk[Risk rank]
    Risk --> Plan[Migration plan]
    Plan --> Execute[Execute migration]
    Execute --> Monitor[Monitor compliance]

Inventory record:

Illustrative listing · yaml

crypto_inventory_record:
  system_id: string
  owner: string
  data_classification: public | internal | confidential | regulated
  algorithm:
    key_establishment: string
    signature: string
    certificate_profile: string
  data_retention_years: int
  confidentiality_lifetime_years: int
  external_dependency: bool
  migration_priority: critical | high | medium | low
  target_pqc_profile: string
  exception_expiry: date | null

41.3 Harvest-now-decrypt-later risk changes priority

Data with a long confidentiality lifetime may need migration before systems that appear more operationally critical. Record how long the information must remain secret separately from its retention period: deleting the organization’s copy does not remove ciphertext an adversary has already collected. [R60]

Diagram loads as you read

41.3 Harvest-now-decrypt-later risk changes priority · Figure 3

View diagram source

flowchart TD
    Data[Data set] --> Retention[Required confidentiality lifetime]
    Data --> Sensitivity[Sensitivity]
    Data --> Exposure[Network exposure]
    Retention --> Risk[HNDL risk]
    Sensitivity --> Risk
    Exposure --> Risk
    Risk --> Priority[Migration priority]

Priority questions:

Question	Impact
will the data still be sensitive in 10+ years?	raises urgency
is the traffic externally observable?	raises harvest risk
does the system use public-key crypto?	identifies affected paths
can the component be updated?	determines migration complexity
is there a regulated deadline?	constrains sequencing

41.4 Crypto agility is an operating capability

PQC migration is not a one-time algorithm swap. Standards, libraries, protocols, and compliance requirements will evolve.

Diagram loads as you read

41.4 Crypto agility is an operating capability · Figure 4

View diagram source

flowchart LR
    Policy[Crypto policy] --> Profiles[Approved profiles]
    Profiles --> Libraries[Approved libraries]
    Libraries --> Deployment[Deployment automation]
    Deployment --> Telemetry[Crypto telemetry]
    Telemetry --> Policy

Crypto-agility controls:

centralized algorithm policy,
inventory telemetry,
library version governance,
certificate lifecycle automation,
test environments for hybrid modes,
exception registry,
rollback strategy,
vendor dependency tracking.

41.5 Migration waves

Diagram loads as you read

41.5 Migration waves · Figure 5

View diagram source

gantt
    title PQC Migration Wave Plan
    dateFormat  YYYY-MM-DD
    section Discovery
    Inventory critical systems :a1, 2026-05-01, 60d
    Vendor dependency review :a2, after a1, 45d
    section Pilot
    Internal TLS pilot :b1, 2026-08-01, 60d
    Signing pilot :b2, after b1, 60d
    section Migration
    High-risk services :c1, 2026-11-01, 120d
    Medium-risk services :c2, after c1, 180d
    section Sustain
    Continuous crypto monitoring :d1, after c2, 240d

Migration waves should be organized by risk and operational coupling, not only by team ownership.

41.6 Vendor and third-party risk

Diagram loads as you read

41.6 Vendor and third-party risk · Figure 6

View diagram source

flowchart TB
    Vendor[Vendor] --> Crypto[Crypto dependency]
    Crypto --> Inventory[Inventory disclosure]
    Crypto --> Roadmap[PQC roadmap]
    Crypto --> Evidence[Test evidence]
    Crypto --> Contract[Contract obligations]

Ask vendors for:

public-key algorithm inventory,
PQC roadmap,
protocol support plan,
hardware security module support,
certificate and signing migration plan,
FIPS or equivalent validation plan where applicable,
customer testing timeline,
emergency rollback process.

41.7 Governance model

Diagram loads as you read

41.7 Governance model · Figure 7

View diagram source

flowchart LR
    Steering[Quantum-safe steering group] --> Security[Security owner]
    Steering --> Infra[Infrastructure owner]
    Steering --> App[Application owners]
    Steering --> Legal[Legal/compliance]
    Steering --> Procurement[Procurement]
    Security --> Metrics[Migration metrics]
    Metrics --> Steering

Monthly metrics:

Metric	Meaning
inventory coverage	percent of systems with known crypto use
critical migration completion	fraction of in-scope high-risk systems migrated and validated; report scheduled work separately
exceptions expiring	risk debt requiring action
vendor readiness	third-party dependencies with credible plans
test coverage	protocols and platforms verified in staging

41.8 Claims discipline

Do not claim a system is “quantum-safe” unless the claim states the scope.

Diagram loads as you read

41.8 Claims discipline · Figure 8

View diagram source

flowchart TD
    Claim[Quantum-safe claim] --> Scope[Scope]
    Scope --> Algorithms[Algorithms covered]
    Scope --> Protocols[Protocols covered]
    Scope --> Libraries[Libraries and modules]
    Scope --> Exceptions[Exceptions]
    Exceptions --> Approved{Approved?}
    Approved -- no --> Reject[Reject claim]
    Approved -- yes --> Publish[Publish scoped claim]

Acceptable claim format:

The customer-facing TLS path for Service X uses approved PQC migration profile Y in environment Z, with exceptions A and B expiring on date D.

Unacceptable claim format:

We are quantum-safe.

Additional technical sources: [R262].