Post-Quantum Cryptography: Why Inventory Comes Before Migration

---

The industry conversation around post-quantum cryptography (PQC) is dominated by algorithm selection. Which key encapsulation mechanism to adopt. Which digital signature scheme to deploy. How hybrid key exchange works in TLS 1.3.

These are important questions. They are also premature for 90% of organizations.

The actual first step — the one that determines whether your PQC migration succeeds or stalls — is inventory. You cannot migrate cryptography you cannot find. You cannot prioritize what you haven’t mapped. And you cannot estimate timelines without knowing the scope of the problem.

Most enterprises have zero visibility into where cryptographic algorithms are deployed across their infrastructure. Not partial visibility. Zero.

This post makes the case for inventory-first PQC migration, provides a framework for cryptographic discovery, and outlines the decision model for prioritization.

---

PQC Migration Trajectory (CNSA 2.0 Timeline)

Projected algorithm distribution across enterprise infrastructure

⚠️ Organizations that haven't started inventory by 2026 will miss CNSA 2.0 network equipment deadline (2030) — migration typically takes 3-5 years.

NIST PQC Standards: What’s Been Finalized

The National Institute of Standards and Technology published the first three post-quantum cryptographic standards on August 13, 2024:

Standard	Algorithm	Type	Use Case	Based On
FIPS 203	ML-KEM (CRYSTALS-Kyber)	Key Encapsulation Mechanism	Key exchange, TLS handshakes	Module Lattices
FIPS 204	ML-DSA (CRYSTALS-Dilithium)	Digital Signature	Code signing, certificate signing, authentication	Module Lattices
FIPS 205	SLH-DSA (SPHINCS+)	Digital Signature	Stateless hash-based signatures (conservative backup)	Hash functions

A fourth standard, FN-DSA (FALCON), based on NTRU lattices, is expected in late 2025 for applications requiring compact signatures.

What this means practically: The algorithms are no longer experimental. They are standardized, assigned FIPS numbers, and expected to be implemented. The “we’ll wait for standards” justification no longer applies.

Implementation Timeline Pressure

• NSA CNSA 2.0 (September 2022): Requires quantum-resistant algorithms for National Security Systems by 2035. Software and firmware signing must use PQC by 2025. Web servers/cloud services by 2025. Network equipment by 2030.
• CISA Guidance (August 2023): Federal agencies must inventory cryptographic assets and develop migration plans.
• OMB Memo M-23-02: Requires agencies to submit cryptographic systems inventories.

The U.S. government isn’t asking whether to migrate. It’s asking how fast.

---

Harvest Now, Decrypt Later: The Threat Timeline

The most cited justification for urgent PQC migration is the Harvest Now, Decrypt Later (HNDL) attack model:

1. An adversary captures encrypted network traffic today (VPN sessions, TLS connections, encrypted emails).
2. The adversary stores this data — storage is cheap.
3. When a cryptographically relevant quantum computer (CRQC) becomes available, the adversary decrypts the captured data.

The question isn’t whether a CRQC will exist. It’s when. Estimates vary:

Source	Estimated CRQC Timeline	Confidence
NIST (2022 report)	2030-2040	Moderate
IBM Quantum roadmap	100K+ qubits by 2033	Manufacturer claim
Chinese research (2023)	Claims RSA-2048 factoring advances	Disputed
Mitre (2024 assessment)	2035 ± 5 years	Consensus estimate
European Commission	Plan for 2030 readiness	Policy decision

The critical insight: The threat isn’t about when quantum computers break RSA. It’s about how long your data needs to remain confidential.

If your data has a 10-year confidentiality requirement (medical records, M&A data, defense contracts, trade secrets), and a CRQC arrives in 15 years, and your migration takes 5 years — you needed to start already.

This is Mosca’s theorem formalized.

---

Mosca’s Theorem: A Decision Framework

Michele Mosca’s inequality provides the decision framework:

If X + Y > Z, your data is at risk.

Where:

• X = Number of years the data must remain secure
• Y = Number of years to migrate your systems to PQC
• Z = Number of years until a CRQC exists

Data Type	X (Security Lifespan)	Y (Migration Time)	Z (CRQC Estimate)	X + Y > Z?	Action Required
Healthcare records (HIPAA)	50+ years	5-7 years	15 years	Yes (55+ > 15)	Immediate
Financial transactions	7 years	3-5 years	15 years	Maybe (10-12 vs 15)	Plan now
Government classified	25-75 years	5-10 years	15 years	Yes (30-85 > 15)	Immediate
Trade secrets	Indefinite	5-7 years	15 years	Yes	Immediate
Retail transactions	2-3 years	3-5 years	15 years	No (5-8 < 15)	Monitor
Marketing data	1-2 years	2-3 years	15 years	No (3-5 < 15)	Low priority

This isn’t abstract math. It’s a resource allocation model. Organizations with high-value, long-lived data must start migration now — which means they must start inventory now.

---

Why Migration Without Inventory Fails

Organizations that skip inventory and jump to implementation encounter predictable failures:

Scenario 1: The Shadow Cryptography Problem

A financial services firm begins PQC migration by upgrading their public-facing TLS infrastructure. They replace RSA-2048 key exchange with ML-KEM hybrid in their web tier. Project declared successful.

Six months later, an internal audit discovers:

• 340 internal microservices using mTLS with RSA-2048 certificates
• VPN concentrators using IKEv2 with ECDH key exchange (quantum-vulnerable)
• A legacy payment processing system using 3DES (not quantum-related, but discovered during the scramble)
• SSH keys across 2,000 servers using RSA-4096
• Code signing certificates using RSA-2048 for CI/CD pipelines

The “completed” migration covered 12% of their cryptographic footprint. The remaining 88% was invisible to the project team because nobody inventoried it.

Scenario 2: The Dependency Chain

A technology company inventories their own systems but not their vendor dependencies. They migrate internal services to PQC algorithms. Then discover:

• Their SSO provider (Okta/Azure AD) hasn’t migrated SAML signing
• Their CDN provider’s TLS termination uses ECDSA certificates they don’t control
• Database connections to managed services (RDS, Cloud SQL) use provider-controlled encryption
• Third-party APIs they consume use RSA for mutual TLS authentication

Their migration is incomplete because their cryptographic perimeter extends beyond their infrastructure boundary.

Scenario 3: The Compliance Surprise

A defense contractor begins migration to meet CNSA 2.0 deadlines. They discover mid-project that their audit framework requires documenting current-state cryptography before making changes. Without a pre-migration inventory:

• They cannot demonstrate which systems were vulnerable
• They cannot prove migration completeness
• They cannot generate the delta report auditors require
• The audit finding triggers a contract compliance issue

The pattern: Every failed PQC migration traces back to the same root cause — the organization didn’t know what it had before it tried to change it.

---

What Needs Migrating: The Full Scope

Most teams think of PQC migration as “update TLS.” The actual scope is dramatically larger:

Cryptographic Use Case	Current Algorithm (Typical)	Quantum Threat	PQC Replacement	Migration Complexity
TLS key exchange	ECDHE (P-256, X25519)	Key recovery	ML-KEM-768 (hybrid)	Medium
TLS server certificates	RSA-2048, ECDSA P-256	Signature forgery	ML-DSA-65	Medium
VPN (IPsec IKEv2)	ECDH, RSA	Key recovery	ML-KEM + ML-DSA	High (firmware updates)
SSH authentication	RSA-4096, Ed25519	Key recovery	ML-KEM, ML-DSA	Medium
Code signing	RSA-2048, ECDSA	Forgery	ML-DSA-87	High (toolchain changes)
Email (S/MIME)	RSA-2048	Decryption	ML-KEM + ML-DSA	High (client support)
Document signing	RSA-2048	Forgery	ML-DSA-65	Medium
Database encryption (TDE)	AES-256 (key wrapped with RSA)	Key unwrapping	ML-KEM for key wrapping	Medium
Disk encryption (BitLocker/LUKS)	AES-256 (protector uses RSA/TPM)	Protector compromise	PQC-wrapped protectors	Low-Medium
JWT/OAuth tokens	RSA-256, ES256	Forgery	ML-DSA	Medium (library support)
PKI (CA certificates)	RSA-4096	Forgery	ML-DSA-87 (composite)	Very High
HSM stored keys	RSA, ECC	Key recovery	ML-KEM, ML-DSA	Very High (hardware)
Blockchain/DLT	ECDSA (secp256k1)	Forgery	ML-DSA	Ecosystem-dependent
API authentication (mTLS)	RSA-2048, ECDSA	Forgery	ML-DSA certificates	Medium
Firmware signing	RSA-2048	Forgery	ML-DSA-87, SLH-DSA	Very High (embedded)

That’s 15+ categories. Each with different migration paths, different timeline requirements, and different owner teams.

---

CBOM: Cryptographic Bill of Materials

A Cryptographic Bill of Materials is the structured inventory that makes PQC migration tractable. It documents every cryptographic asset in your environment with sufficient detail to plan migration.

What a CBOM Entry Contains

{
  "asset_id": "tls-cert-api-prod-001",
  "asset_type": "x509_certificate",
  "algorithm": {
    "key_type": "RSA",
    "key_size": 2048,
    "signature_algorithm": "sha256WithRSAEncryption"
  },
  "location": {
    "host": "api-prod-lb-01.internal",
    "port": 443,
    "service": "API Gateway",
    "environment": "production"
  },
  "owner": {
    "team": "Platform Engineering",
    "contact": "platform-eng@example.com"
  },
  "quantum_vulnerability": {
    "threat_type": "signature_forgery",
    "priority": "high",
    "data_sensitivity": "PII + financial",
    "migration_target": "ML-DSA-65"
  },
  "dependencies": [
    "ca-cert-internal-root-001",
    "hsm-slot-prod-007"
  ],
  "compliance": ["PCI-DSS", "SOC2", "HIPAA"],
  "last_discovered": "2026-06-15T08:30:00Z",
  "discovery_method": "network_scan"
}

CBOM Standards: CycloneDX Cryptographic Extensions

The CycloneDX SBOM standard (managed by OWASP) includes cryptographic extensions specifically designed for CBOM:

• CycloneDX v1.6 introduced the cryptoProperties component type
• Supports documenting: algorithms, key sizes, certificate details, protocol versions
• Machine-readable format (JSON/XML) enables automated analysis
• Integrates with existing SBOM tooling and vulnerability management

The IBM Quantum Safe initiative and NIST’s Migration to Post-Quantum Cryptography project both reference CBOM as a prerequisite for managed migration.

---

Discovery Methods: Finding Your Cryptography

Inventory requires active discovery. Cryptographic assets don’t self-report. Here are the four primary discovery approaches:

1. Network Scanning

Actively probe network endpoints to identify cryptographic protocols in use.

What it finds:

• TLS certificates and cipher suites on all listening ports
• SSH host keys and authentication methods
• VPN endpoint configurations
• STARTTLS on mail servers

Tools: Nmap with ssl-enum-ciphers script, sslyze, testssl.sh, Qualys SSL Labs API

# Scan all internal subnets for TLS endpoints
nmap -sV --script ssl-enum-ciphers -p 443,8443,636,993,995,5061 \
  10.0.0.0/8 -oX tls-scan-results.xml

# Extract certificate details from scan results
sslyze --targets_in hosts.txt --json_out crypto-inventory.json \
  --certinfo --tlsv1_2 --tlsv1_3

Limitations: Only finds active network listeners. Misses offline systems, batch processes, and encryption at rest.

2. Static Code Analysis

Scan source code repositories for cryptographic API calls, hardcoded algorithms, and key material.

What it finds:

• Algorithm choices in application code (e.g., Cipher.getInstance("RSA/ECB/PKCS1Padding"))
• Hardcoded key sizes and curve selections
• Cryptographic library imports and version dependencies
• Certificate loading and validation code

Tools: Semgrep (with crypto rules), CryptoGuard, Cryptosense Analyzer

# Semgrep rule: find RSA key generation with weak sizes
rules:
  - id: weak-rsa-key-generation
    patterns:
      - pattern: KeyPairGenerator.getInstance("RSA")
      - pattern: $KPG.initialize($SIZE)
      - metavariable-comparison:
          metavariable: $SIZE
          comparison: $SIZE < 3072
    message: "RSA key generation with size < 3072 bits (quantum-vulnerable)"
    severity: WARNING
    languages: [java]

Limitations: Requires source code access. Misses dynamically configured cryptography and third-party binaries.

3. Binary and Configuration Inspection

Examine deployed artifacts — compiled binaries, configuration files, keystores, and container images.

What it finds:

• Cryptographic libraries compiled into binaries (OpenSSL version, Bouncy Castle, etc.)
• Keystore files (JKS, PKCS#12) and their contents
• Configuration files specifying cipher suites
• Certificate files on disk

# Find all keystore and certificate files
find / -name "*.jks" -o -name "*.p12" -o -name "*.pfx" \
  -o -name "*.pem" -o -name "*.crt" -o -name "*.key" 2>/dev/null

# Inspect a Java keystore for algorithm details
keytool -list -v -keystore app.jks | grep -E "(Alias|Key Size|Algorithm|Valid)"

# Check OpenSSL version in a container image
docker run --rm target-image openssl version -a

Limitations: Requires host access or agent deployment. Labor-intensive for large environments without automation.

4. Traffic Analysis (Passive Monitoring)

Capture and analyze network traffic metadata to identify cryptographic protocols in active use.

What it finds:

• Actual cipher suites negotiated (not just what’s supported)
• Certificate exchanges during TLS handshakes
• SSH version and key exchange algorithms observed in practice
• Deprecated protocols still actively in use (TLS 1.0, SSHv1)

Tools: Zeek (formerly Bro), JA3/JA3S fingerprinting, network TAPs with protocol analysis

Limitations: Cannot see encryption-at-rest. Requires network tap or span port access. High data volume.

Discovery Method Comparison

Method	Coverage	Effort to Deploy	Ongoing Maintenance	Best For
Network scanning	Active network services	Low	Low (scheduled scans)	Quick baseline of TLS/SSH
Static code analysis	Application-layer crypto	Medium	Medium (CI integration)	Development teams
Binary/config inspection	Deployed artifacts	High	High (agent management)	Full infrastructure coverage
Traffic analysis	Crypto actually in use	High	Medium (tap maintenance)	Validating what’s active

Recommended approach: Start with network scanning for immediate visibility, add static analysis for development pipelines, and deploy agent-based inspection for complete coverage over time.

---

4-Phase Migration Framework

Phase 1: Inventory (Months 1-4)

Objective: Complete cryptographic asset discovery and produce initial CBOM.

Activity	Duration	Output
Deploy network scanning across all subnets	2 weeks	TLS/SSH endpoint inventory
Integrate static analysis into CI/CD pipelines	3 weeks	Code-level crypto findings
Scan configuration management databases	1 week	Known certificate/key inventory
Interview application teams for tribal knowledge	2 weeks	Undocumented crypto assets
Consolidate findings into CBOM format	2 weeks	v1.0 CBOM
Validate CBOM accuracy (10% sample verification)	2 weeks	Confidence score

Success criteria: 80%+ coverage of cryptographic assets with owner assignment.

Phase 2: Assess (Months 5-7)

Objective: Classify every cryptographic asset by quantum vulnerability and migration priority.

Apply the risk prioritization matrix (below) to every CBOM entry:

• Determine quantum vulnerability (is this algorithm broken by Shor’s or Grover’s algorithm?)
• Assess data sensitivity (what does this cryptography protect?)
• Calculate exposure window (how long must this data remain confidential?)
• Map dependencies (what else breaks if we change this?)
• Identify migration blockers (hardware constraints, vendor dependencies, protocol limitations)

Success criteria: Every CBOM entry has a priority score (Critical/High/Medium/Low) and identified migration target algorithm.

Phase 3: Plan (Months 8-11)

Objective: Produce executable migration roadmap with resource requirements.

• Group assets by migration path (similar systems migrate together)
• Sequence migrations to manage dependency chains (root CAs before leaf certs)
• Identify pilot candidates (low-risk, high-visibility for proof of concept)
• Estimate effort per migration group
• Align with vendor roadmaps (when does your CA support ML-DSA certificates?)
• Secure budget and staffing approval
• Define rollback procedures for every migration group

Success criteria: Approved project plan with timeline, budget, and resource allocation.

Phase 4: Execute (Months 12-36+)

Objective: Migrate cryptographic assets to quantum-resistant algorithms.

Execution sequence (recommended priority order):

1. Data in transit with long-term secrecy — VPN tunnels carrying sensitive data, TLS connections to data stores
2. Digital signatures on long-lived artifacts — Code signing, firmware signing, document signing
3. Certificate infrastructure — Internal CA migration to composite/hybrid certificates
4. Authentication systems — SSH keys, mTLS certificates, JWT signing
5. Data at rest — Re-wrapping encryption keys with PQC KEM
6. Legacy and third-party — Systems requiring vendor updates or hardware replacement

Success criteria: Percentage of CBOM assets migrated to PQC algorithms, tracked quarterly.

---

Algorithm Replacement Mapping

Current Algorithm	Quantum Threat	NIST PQC Replacement	Key/Signature Size Impact	Performance Impact
RSA-2048 (encryption)	Shor’s algorithm	ML-KEM-768	Public key: 1,184 bytes (vs 256 bytes)	Faster than RSA
RSA-2048 (signatures)	Shor’s algorithm	ML-DSA-65	Signature: 3,309 bytes (vs 256 bytes)	Comparable
RSA-4096 (signatures)	Shor’s algorithm	ML-DSA-87	Signature: 4,627 bytes (vs 512 bytes)	Faster than RSA-4096
ECDSA P-256	Shor’s algorithm	ML-DSA-44	Signature: 2,420 bytes (vs 64 bytes)	Slightly slower
ECDH P-256 (key exchange)	Shor’s algorithm	ML-KEM-512	Ciphertext: 768 bytes (vs 65 bytes)	Faster
X25519 (key exchange)	Shor’s algorithm	ML-KEM-768	Ciphertext: 1,088 bytes (vs 32 bytes)	Comparable
Ed25519 (signatures)	Shor’s algorithm	ML-DSA-44	Signature: 2,420 bytes (vs 64 bytes)	Slower
AES-128	Grover’s algorithm (halves key strength)	AES-256	Same	Negligible
SHA-256	Grover’s algorithm (theoretical)	SHA-256 (still adequate)	Same	None
3DES	Already broken + Grover’s	AES-256	Same	Faster

Key observation: PQC algorithms produce significantly larger keys and signatures. This impacts:

• TLS handshake sizes (larger ClientHello and ServerHello)
• Certificate chain sizes (3-5x larger)
• Network bandwidth for high-volume API traffic
• Storage for signed artifacts
• Embedded systems with memory constraints

Hybrid approaches (e.g., X25519 + ML-KEM-768 in TLS) provide quantum resistance while maintaining backward compatibility during the transition period.

---

Risk Prioritization Matrix

Prioritize migration based on two dimensions: data sensitivity and exposure window.

	Exposure Window: Short (< 3 years)	Exposure Window: Medium (3-10 years)	Exposure Window: Long (10+ years)
Data Sensitivity: Critical (classified, medical, trade secrets)	High	Critical	Critical
Data Sensitivity: High (PII, financial, legal)	Medium	High	Critical
Data Sensitivity: Medium (internal business data)	Low	Medium	High
Data Sensitivity: Low (public data, marketing)	Low	Low	Medium

Critical = migrate within 12 months. These are your HNDL-vulnerable, high-value data flows.

High = migrate within 24 months. Significant risk but slightly less urgent.

Medium = migrate within 36 months. Plan and budget; execute as part of normal upgrade cycles.

Low = migrate opportunistically. Include in system refreshes and platform upgrades.

---

When to Start: Decision Model Based on Data Retention

Use this decision tree:

1. What is the longest confidentiality requirement for data protected by this cryptographic system? (X value in Mosca’s theorem)
2. How long will migration take for this system class? (Y value — estimate 2-5 years for most enterprise environments)
3. When will a CRQC be available? (Z value — use 15 years as a conservative planning assumption)

If X + Y > Z: Start inventory immediately. You are already in the red zone.

If X + Y = Z (within 2 years): Start inventory within 6 months. You have minimal buffer.

If X + Y < Z (by more than 5 years): Monitor standards development. Plan inventory for next fiscal year.

For most enterprises handling PII, healthcare data, financial records, or intellectual property: X + Y > Z is already true. The migration time (Y) alone often exceeds 3-5 years for complex environments. Combined with data retention requirements of 7-25+ years, the math demands immediate action.

The inventory is the action. You cannot estimate Y (migration time) without first knowing what exists. Inventory is not a planning exercise. It is the first deliverable of your PQC program.

---

Common Objections and Responses

Objection	Response
”Quantum computers are 15+ years away”	Your data needs to be protected for longer than 15 years. And your migration will take 3-7 years. Do the math.
”We’ll wait for vendors to handle it”	Vendors will update libraries, not your architecture. You still need to know where to apply updates.
”We don’t have budget for this yet”	Inventory is the cheapest phase. Network scanning is free (open-source tools). Delay makes every subsequent phase more expensive.
”Our compliance framework doesn’t require PQC”	NIST SP 800-131A Rev 2 is in draft. OMB M-23-02 already requires federal suppliers to inventory. Commercial frameworks will follow within 24 months.
”We’ll do it during our next infrastructure refresh”	Your refresh cycle is 5-7 years. You need PQC readiness in 3-5 years. The timelines don’t align unless you start now.

---

About QCecuring

QCecuring provides cryptographic inventory and post-quantum migration services for enterprises. Our CBOM platform automates cryptographic discovery across networks, code repositories, and deployed infrastructure — giving you the complete picture of where cryptography exists before you begin migration.

We help organizations move from “we think we use RSA” to a machine-readable, auditable inventory that feeds directly into PQC migration planning.

Start your cryptographic inventory →

---

Tags: Post-Quantum Cryptography, PQC, NIST, FIPS 203, FIPS 204, FIPS 205, ML-KEM, ML-DSA, SLH-DSA, CBOM, Cryptographic Bill of Materials, Quantum Computing, Harvest Now Decrypt Later, Mosca’s Theorem, Crypto Migration, CNSA 2.0, CycloneDX