Cryptographic Inventory: A Field Guide for Quantum Readiness

Scope

This guide outlines the operational steps for building and maintaining a cryptographic inventory to counter quantum computing threats. It targets organizations managing digital assets reliant on asymmetric cryptography (RSA, ECC, Diffie-Hellman) for key exchange, authentication, or digital signatures. You'll find requirement breakdowns from Executive Order 14412, implementation steps for discovery and migration, and a reference table for prioritizing remediation work.

This isn't theoretical. Adversaries are harvesting encrypted data now to decrypt later, making your cryptographic posture a current vulnerability.

Key Concepts and Definitions

Cryptographically Relevant Quantum Computer (CRQC): A fault-tolerant quantum computer capable of running Shor's Algorithm to break RSA, ECC, and Diffie-Hellman encryption in polynomial time. Its arrival timeline is uncertain, so immediate action is necessary.

Harvest Now, Decrypt Later (HNDL): A strategy where adversaries intercept and store encrypted traffic today, planning to decrypt it once quantum capabilities mature. Nation-states execute this at scale using techniques like Border Gateway Protocol hijacking.

Post-Quantum Cryptography (PQC): Cryptographic algorithms designed to resist attacks from both classical and quantum computers. NIST has standardized several PQC algorithms for key establishment and digital signatures.

Cryptographic Bill of Materials (CBOM): An inventory of all cryptographic assets across software, firmware, and hardware dependencies. Frameworks like CycloneDX provide structure for automated discovery and cataloging.

Crypto-Agility: The ability to swap cryptographic algorithms without recompiling code or redeploying systems. This is essential because PQC standards are new and may require updates if vulnerabilities emerge.

Requirements Breakdown

Executive Order 14412 Mandates

• Key establishment transition deadline: Dec. 31, 2030. Federal agencies must migrate high-value assets to PQC for key establishment by this date.
• Digital signature transition deadline: Dec. 31, 2031. Federal agencies must complete PQC migration for digital signature functions.
• Contractor compliance: The Federal Acquisition Regulatory Council requires federal contractors to meet NIST FIPS-approved PQC standards by the end of 2030. If you hold federal contracts, your cryptographic inventory affects contract eligibility.
• Cryptographic weakness as vulnerability: Vulnerability disclosure programs must treat the absence of encryption or use of non-FIPS-approved algorithms as reportable vulnerabilities. This shifts crypto-hygiene from an audit finding to an active risk item in your exposure management program.

What Breaks Under Quantum Attack

Completely compromised:

• RSA-2048 and RSA-4096
• Elliptic Curve Diffie-Hellman (ECDH)
• Elliptic Curve Digital Signature Algorithm (ECDSA)
• Diffie-Hellman key exchange

Remains secure:

• AES-256 symmetric encryption (Grover's Algorithm effectively halves key strength, but AES-256 provides adequate security margin)

The crisis centers on asymmetric cryptography used for TLS/SSL handshakes, SSH session negotiation, code signing, and authentication.

Implementation Guidance

Phase 1: Automated Discovery

Start with an outside-in view of your internet-facing services. HNDL attacks target data in transit, so you need visibility into what key exchanges and ciphers your external services negotiate.

Action steps:

1. Inventory all connected accounts and cloud resources.
2. Actively scan internet-facing services to capture negotiated ciphers.
3. Document TLS/SSL and SSH protocol configurations across infrastructure.
4. Generate a baseline CBOM that includes cryptographic dependencies in all software, firmware, and hardware.

Don't limit discovery to configuration files. Configuration drift happens constantly. You need active scanning that captures what's actually running, not what's documented.

Phase 2: Prioritization and Risk Assessment

Not every system requires immediate PQC migration. Focus on:

High-priority targets:

• Systems handling data with long confidentiality requirements (10+ years)
• Authentication infrastructure (identity providers, certificate authorities)
• Services exposed to internet traffic that adversaries can intercept
• Systems processing regulated data (financial, healthcare, defense)
• Code signing infrastructure

Use asset criticality ratings that factor in device function, connectivity, and third-party data exposure. Assets rated 6-10 on a 10-point scale warrant priority remediation.

Phase 3: Remediation and Crypto-Agility

Migrate in stages: conventional to hybrid (parallel conventional and PQC) to fully PQC compliant. Governmental mandates generally target 2035 for complete quantum resistance across all systems.

Critical implementation rule: Never hard-code cryptographic algorithms. Use configuration-based implementations that allow algorithm swaps without code changes. PQC standards are new. If a vulnerability surfaces in a newly adopted algorithm, you must be able to switch alternatives immediately.

Hybrid configurations let you maintain backward compatibility while adding quantum resistance. Configure systems to negotiate PQC ciphers first, falling back to conventional algorithms only for legacy clients.

Phase 4: Continuous Verification

A DevOps push can overwrite configurations and revert systems to quantum-vulnerable states. Build continuous scanning into your exposure management workflow.

Verification requirements:

• Automated daily scans of cryptographic configurations
• Alerts when services revert to classical-only ciphers
• Certificate expiry tracking (expired certificates often trigger emergency fixes that bypass security standards)
• Configuration drift detection across TLS/SSL and SSH services

Treat cryptographic compliance as exposure management, not a separate audit exercise. Cryptographic weaknesses should surface alongside vulnerabilities, misconfigurations, and identity risks in unified dashboards.

Common Pitfalls

• Treating quantum threats as future-only concerns: HNDL attacks are active now. Data you encrypt today may have confidentiality requirements extending beyond the quantum computing timeline.
• Separating crypto inventory from vulnerability management: If cryptographic risk lives in a separate report, it competes poorly for engineering attention. Integrate it into your existing exposure management platform.
• Ignoring supply chain cryptography: Your contractors and vendors use cryptography too. Executive Order 14412's contractor mandates mean their cryptographic posture affects your compliance status.
• Hard-coding PQC algorithms: The standards are new. Build crypto-agility into your architecture or you'll face another migration when algorithms need updates.
• Focusing only on configuration files: Configuration drift is constant. Active scanning captures what's actually running, which often differs from documented configurations.
• Delaying until Q-Day: By the time a CRQC becomes operational, adversaries will have years of harvested encrypted data ready to decrypt. Your timeline is now, not when quantum computers arrive.

Quick Reference Table

Asset Type	Quantum Vulnerability	Priority Level	Target Timeline
Internet-facing TLS/SSL services	High (HNDL exposure)	Critical	2030
SSH key exchange	High	Critical	2030
Code signing infrastructure	High	Critical	2031
Certificate authorities	High	Critical	2030
Internal-only services (short-term data)	Medium	Standard	2035
AES-256 symmetric encryption	Low	Monitor only	No action required
Long-lived data archives	High (future decryption risk)	Critical	2030
Federal contractor systems	High (compliance)	Critical	2030

Cipher support status to track:

• Services with at least one PQC cipher: Compliant
• Services with no PQC ciphers: Remediation required
• Services using only classical algorithms: Critical risk
• Self-signed or expired certificates: Configuration concern requiring immediate attention

Your cryptographic inventory is now a compliance artifact, an operational security control, and a contractual requirement. Build it with the same rigor you apply to vulnerability management, because regulatory bodies and adversaries are both watching.