Case Study: The Cryptographic Inventory Nobody Wants to Do

Executive Summary

Every post-quantum migration guide begins with "inventory your cryptography." Every organization discovers that this step, which sounds like a week of documentation, takes six to eighteen months and is the actual project.

This case study follows a 4,000-person financial-services firm through its inventory. It finds 340% more cryptographic usage than the initial estimate, uncovers a class of exposure nobody was tracking, and produces the prioritized migration plan that follows. The discovery techniques transfer to any organization.

Skills applied

• Enumerating cryptographic assets across code, infrastructure, and vendors (§30.14).
• Distinguishing data-in-transit from data-at-rest exposure.
• Identifying hybrid constructions that hide public-key dependence.
• Prioritizing by Mosca's inequality.

Phase 1: The initial estimate

The security team's first pass, from architecture documents:

Five systems. Estimated migration: six months.

Phase 2: What the automated scan found

Running cryptographic discovery tools — static analysis over source, TLS scanning across the network, certificate inventory, and configuration auditing:

340% more than the architecture documents suggested, and the excess is concentrated in exactly the places that are hardest to change: embedded devices, third-party integrations, and code with hardcoded keys.

Phase 3: The exposures nobody was tracking

Three categories emerged that no one had considered.

1. Key wrapping under symmetric encryption. Backups used AES-256 — safe from Grover. But the AES keys were themselves wrapped with RSA-2048. An adversary who exfiltrated a backup today needs only to break the RSA wrapper in 2040 to obtain the AES key and decrypt 25-year-retention data.

This is the single most commonly missed exposure. An inventory recording only "AES-256" for a system is wrong if the key management underneath is public-key based. The rule: inventory the key hierarchy, not the bulk cipher.

2. Long-lived signatures on long-lived artifacts. Firmware signed with RSA-2048 today runs on devices with 15-year service lives. In 2038, an attacker with a CRQC could forge a signature and push malicious firmware to devices still in the field. The signature must remain unforgeable for the device's lifetime, not the certificate's validity period.

3. Third-party dependencies. 94 SaaS integrations, each with its own cryptographic posture entirely outside the firm's control. The inventory could enumerate them; migrating them required vendor commitments that mostly did not exist yet. Contract language requiring PQC roadmaps became a procurement change, not a technical one.

Phase 4: Prioritization by Mosca

Applying $T_{\text{data}} + T_{\text{migrate}} > T_{\text{CRQC}}$:

The ordering is driven almost entirely by data lifetime, which the organization already knows from its retention policy — no quantum forecasting required. This is what makes the prioritization defensible to a board: it depends on facts the business already owns.

Note the inversion against intuition: the customer-facing website, the most visible system, is the lowest priority because its content is public and its sessions are ephemeral. Backup key wrapping, which nobody thinks about, is the highest.

Phase 5: What the inventory cost

Roughly $1.4M in staff time before a single algorithm was replaced.

Why so long? Automated tools find TLS endpoints and certificates well. They do not find hardcoded keys in a decade of accumulated code, undocumented integrations, or the cryptographic posture of a vendor's vendor. That work is manual.

Phase 6: What made it tractable

Four things that materially helped:

1. Crypto-agility as the real deliverable. The goal shifted from "replace RSA with ML-KEM" to "make algorithms configurable so the next migration is cheap." Post-quantum will not be the last transition, and hardcoded algorithm choices were the root cause of the difficulty.

2. A cryptographic bill of materials (CBOM). A machine-readable inventory maintained alongside the software bill of materials, updated in CI. Discovery became continuous rather than a one-time project.

3. Procurement leverage. New contracts required PQC roadmaps. Cheaper than retrofitting, and it moved vendors.

4. Accepting partial coverage. 1,100 embedded certificates on devices without remote update could not be migrated. Those devices were network-segmented and scheduled for replacement — an accepted, documented risk rather than an unbounded one.

Discussion Questions

1. The inventory found 340% more than documented. What does that suggest about migration timelines quoted before an inventory?
2. Key wrapping under AES is the most-missed exposure. Why is it so easy to overlook, and what inventory practice catches it?
3. Prioritization depended on data lifetime, not on quantum forecasts. Why does that make the plan more defensible?
4. Crypto-agility was the real deliverable. What would you have to change in a typical codebase to achieve it?

Your Turn: Extensions

• Run a TLS scan over a network you administer and compare findings against documentation.
• Trace one system's full key hierarchy from bulk cipher up to the root, noting every public-key step.
• Build a Mosca table for three asset classes you know.
• Draft contract language requiring a vendor PQC roadmap.

Key Takeaways

• Cryptographic inventory typically finds several times more usage than architecture documents show, concentrated in the hardest-to-change places.
• Inventory the key hierarchy, not the bulk cipher: AES-256 protected by an RSA-wrapped key is an RSA exposure.
• Long-lived signed artifacts such as firmware need signatures unforgeable for the artifact's service life, not the certificate's validity.
• Prioritize by data lifetime via Mosca's inequality — it needs no quantum forecast and rests on facts the business already has.
• The durable deliverable is crypto-agility plus a maintained CBOM, since post-quantum will not be the last cryptographic transition.