Build a Cryptographic Inventory Before Quantum Forces Your Hand

Alice & Bob has estimated that RSA-2048 could be factored by Shor's algorithm using fewer than 23,000 physical qubits, in as little as three days. That's roughly 40 times fewer qubits than Google Quantum AI's 2025 estimate. Their own figure fell from 350,000 cat qubits in 2023 to 100,000 a year later and 23,000 now. The preprint still needs peer review, and cat qubits at that quality and scale are unproven. But the trend line is the point. The math is getting cheaper faster than most organizations are migrating.

This guide helps you move from "we use RSA somewhere" to a documented, risk-ranked inventory and a transition plan an auditor can trace.

The Problem

The practical threat is "harvest now, decrypt later." Data stolen today can be read once a capable machine exists. A three-day factoring window is irrelevant for a live payment but critical for medical records, intellectual property, or anything that must stay confidential for 15 years.

For compliance teams, this is familiar territory. ISO/IEC 27001:2022 Annex A control 8.24 (use of cryptography) expects defined rules for cryptographic controls and key management. Clause 6.1.2 requires you to assess risks, and a changing threat environment is a legitimate trigger for reassessment. For SOC 2, CC6.1 and CC6.7 cover encryption of data at rest and in transit, and CC3.2 expects you to identify risks to objectives, including emerging ones.

What You Need Before Starting

• An owner and an executive sponsor. Cryptography spans infrastructure, application, and vendor management. Without a named owner, this stalls.
• Access to asset and data classification records, including retention periods. Retention drives urgency.
• Scanning tools. Network and certificate discovery (nmap with ssl-enum-ciphers, testssl.sh, your CMDB), source code scanning (grep or semgrep rules for crypto API calls), and cloud inventories (AWS KMS, Azure Key Vault, GCP Cloud KMS key listings).
• Your vendor register, so you can send cryptographic questionnaires.
• Reference material. NIST has finalized post-quantum standards NIST post-quantum cryptography.

Step-by-Step Implementation

Step 1: Build the Cryptographic Inventory.
Create a register with these columns: system, data classification, algorithm, key length, protocol, key owner, certificate expiry, vendor dependency, and data retention period.

Start with discovery:

# TLS endpoints: enumerate protocols and ciphers
nmap --script ssl-enum-ciphers -p 443 <host-range>

# Certificate details
openssl s_client -connect host:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E "Public Key Algorithm|Public-Key|Signature Algorithm"

# SSH host key types
ssh-keyscan -t rsa,ecdsa,ed25519 <host>

Then cover what scanners miss: VPN configurations, S/MIME and code-signing certificates, database encryption settings, backup tooling, HSM-held keys, and application code that calls crypto libraries directly. Note that RSA, Diffie-Hellman, and elliptic-curve cryptography are all exposed to Shor's algorithm. Elliptic-curve schemes were estimated by Alice & Bob to fall even faster than RSA. Don't scope this as an "RSA-only" project.

Step 2: Rank by Exposure.
Score each entry on two axes: how long the data must remain confidential, and whether ciphertext can be intercepted in transit or at rest by an adversary. Long retention plus interceptable traffic goes to the top. Short-lived session data with low sensitivity goes to the bottom. Document the scoring method; this is your Scenario-Based Risk Assessment and the evidence an assessor will ask for.

Step 3: Record the Risk and Decide Treatment.
Add quantum-related cryptographic risk to your risk register with an owner, likelihood rationale, and impact. Create a Risk Treatment Plan with dated milestones. Under ISO/IEC 27001, this also feeds your Statement of Applicability justification for control 8.24.

Step 4: Assess Vendors and Subservice Organizations.
Send a short questionnaire: which asymmetric algorithms protect your data, whether they have a post-quantum migration roadmap, and whether they support crypto-agility. Log responses against your supplier records (Annex A 5.19 to 5.22). For SOC 2, track gaps in your review of Complementary Subservice Organization Controls.

Step 5: Update Policy.
Revise your cryptography policy to require crypto-agility: algorithms and key lengths must be configurable without re-architecting. Add a requirement that new systems document their algorithm choices and migration path. Route the change through your Control of Documented Information process so versions and approvals are traceable.

Step 6: Pilot Hybrid Key Exchange.
Pick a low-risk, high-visibility internal service. Enable hybrid post-quantum plus classical key exchange where your TLS library or load balancer supports it, and measure handshake size and latency effects. Check FIPS-Validated Cryptography requirements first; if you operate under FIPS constraints, confirm validated module availability before deploying anything experimental.

Step 7: Schedule the Migration.
Sequence by the Step 2 ranking. Long-retention data in transit goes first. Set milestones in the Risk Treatment Plan and assign each to an owner.

Validation

• Coverage Check: Compare the inventory against your asset register and cloud account lists. Unreconciled assets mean the inventory is incomplete.
• Re-scan Quarterly and diff results against the register. New RSA or ECC usage that isn't recorded is a gap.
• Sample Test: Pick five systems at random and have someone other than the inventory owner trace algorithm, key length, and owner from the register back to live configuration.
• Pilot Verification: Confirm the negotiated key exchange group in a packet capture or server log, rather than trusting the configuration file.
• Vendor Response Rate: Track how many critical suppliers have answered. Unanswered questionnaires are open items, not silent approvals.

Maintenance

• Review the cryptographic risk entry at least annually and whenever a credible new resource estimate or standards update is published. This is part of Performance Evaluation under clause 9.1.
• Add a crypto check to change management so new systems can't enter production without a register entry.
• Track certificate and key lifecycles in the register; rotation dates double as migration opportunities.
• Report progress against the Risk Treatment Plan to management review (clause 9.3).
• Watch for peer review of the 23,000-qubit estimate and for independent replication. Adjust your timeline assumptions as evidence firms up, and record why you changed them.

Auditors won't expect you to have finished a post-quantum migration. They will expect you to show you identified the risk, assessed it, and have a dated plan. An inventory and a treatment plan get you there.