Building a Crypto Inventory That Covers the Whole Estate

The algorithms are decided. The address list is not.

NIST published the first three post-quantum standards on August 13, 2024: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. The draft transition guidance in NIST IR 8547 proposes deprecating RSA and elliptic-curve algorithms at 112-bit security after 2030 and disallowing them after 2035. Two dates, three standards, and no ambiguity about what replaces what.

The open question in almost every large organization is where the replacements have to go. That list is the crypto inventory: the record of every place a cryptographic algorithm is implemented, who owns it, and who is able to change it. Every later decision in a migration program depends on it. Wave sequencing, budget, vendor pressure, board reporting, the honest answer to “how far along are we” – all of it is downstream of a document that most programs allocate two weeks and a network scanner to produce.

Two weeks and a scanner will find the part of the estate that answers TCP connections during business hours. It will miss the badge reader, the pipeline controller, the analytics platform the marketing team bought with a corporate card, and the digital signature format that a counterparty defines and you merely comply with. Those systems use public-key cryptography too, which puts them in scope from the start rather than eventually.

We teach the estate map by discovery method rather than by org chart, and there’s a practical reason for it. Ownership tells you who to call. Discovery method tells you whether you can find the thing at all, how much you’ll know once you have, and how much of the record will be evidence versus vendor assertion. What follows walks the estate that way, from what a scanner sees down to what you find by walking the building, and then sets out the ten fields each record needs before anyone can plan a wave from it.

What a scanner can see

Start where the tooling is strongest. Central infrastructure – the certificate authority hierarchy, hardware security modules (HSMs), TLS terminators, VPN gateways, load balancers, the identity platform, and the shared cryptographic libraries applications compile against – is discoverable by direct observation. Network scanning enumerates listening endpoints and their negotiated cipher suites. Certificate stores and CA databases yield issued certificates with their key types and expiry dates. Dependency scanning of build pipelines finds which crypto libraries each application actually links, which is often not the library the architecture diagram claims.

Three limits on scanner output are worth building into the record from day one. A scanner sees what is on the network when the scan runs, so batch processes, quarterly reconciliations, and disaster-recovery paths stay invisible. A scanner sees the outside of a negotiation, not the inside of a binary, so an endpoint offering TLS 1.3 tells you nothing about the signing algorithm the application uses internally. And a scanner cannot see key material at rest: backup encryption, archived data, and code-signing keys in a build system need their own discovery pass.

Enterprise applications – the resource planning suite, the human resources platform, the mail and collaboration stack – sit one step further out. They’re centrally managed, so the owner is easy to name, but the cryptography is inside vendor code. Discovery here means reading vendor documentation and support notes, and asking the account team a dated, specific question: which release supports ML-KEM for transport, which supports ML-DSA for signing, and what is the committed general-availability date. The answer, with the date it was given, becomes an inventory field rather than a note in someone’s inbox.

What only the platform will tell you

Cloud environments are discoverable through the provider’s own interfaces, and the record has to say which side of the shared responsibility model each item falls on. The shared responsibility model is the provider’s split between what they secure and what you secure: they own platform-level encryption on their own migration schedule, you own the transport configuration, the key management policy, and any customer-managed keys.

The useful consequence for inventory work is that half of your cloud estate is already written down. Infrastructure-as-code repositories declare TLS policies, key management resources, and certificate bindings in version-controlled text, which makes them the highest-confidence discovery source you will find anywhere in the program. The other half – the managed load balancer, the managed database’s encryption at rest, the provider’s own signing of platform artifacts – is not yours to change, and the record should say so plainly rather than leaving a blank that someone later reads as unmigrated.

Regional divergence complicates this in multinational estates. The same service, deployed in three regions, can face three different regulatory deadlines. Jurisdiction is a field, not a footnote.

What you can only ask for

Software-as-a-service platforms and vendor-managed infrastructure give you no scan surface and no configuration file. The e-signature service, the customer relationship platform, the outsourced security operations center, the managed hosting provider: you consume the cryptography they implement, and you can’t change a line of it.

Discovery here is a questionnaire plus a contract review, and the two need to be run together. The questionnaire establishes technical state: which algorithms in transit, which at rest, which for any signatures the service produces on your behalf, and what the migration commitment is. The contract review establishes bargaining power – which is to say, what you can actually require and when. A vendor with a renewal eighteen months out and a vendor with a five-year term are different risks even with identical technical answers.

Record the vendor’s answer, the date they gave it, and the name of the person who gave it. Vendor readiness statements age quickly, and a program that treats a two-year-old questionnaire response as current data is reporting fiction to its board.

What the expense ledger finds

Shadow IT – services procured by a business unit outside IT governance – doesn’t appear in the configuration management database, because nobody put it there. It does appear in four other places: single sign-on logs, outbound DNS and proxy logs, cloud access security broker telemetry, and the corporate card ledger. Finance is an underused discovery partner. A recurring monthly charge to a software vendor is evidence of a service, whether or not anyone in IT has heard of it.

Each service found this way needs a disposition rather than a migration plan: absorb it into the governed estate and treat it like any other vendor relationship, replace it with a managed alternative, or accept the residual risk with compensating controls and a data-classification restriction. All three are legitimate. Leaving the row blank is not.

There’s a secondary return here that survives the migration program entirely. An organization that runs this discovery honestly ends up with asset visibility it did not previously have, and that visibility keeps paying long after the last certificate is reissued.

What you find by walking the building

Corporate operational technology (OT) is the technology estate inside your own offices: building management and HVAC controls, lighting automation, physical access control with its badge readers and door controllers, elevator systems, fire suppression panels, and video surveillance. These systems are on the corporate network. They authenticate, they encrypt management traffic, and they hold certificates. They are also managed by facilities, corporate security, or building operations, and typically appear in no IT asset register at all.

Discovery is physical and documentary. Walk the plant rooms and the risers with the facilities engineer. Pull the maintenance contracts, which name every system, its vendor, and its service schedule. Pull the capital plan, which tells you when each system is due for replacement – often the single most useful piece of migration data available for this domain, since a controller scheduled for refresh in three years may not need a firmware path at all.

The conversation that makes this possible has usually never happened, and it doesn’t succeed on technical merit. A facilities director who receives an unannounced audit request from a program they’ve never heard of will decline politely. The same request, following an instruction that the migration program covers every department, gets an engineer and a set of keys.

What you find by reading the safety file

Industrial OT – supervisory control systems, programmable logic controllers, distributed control systems in manufacturing, energy, water, and transport – is where discovery technique matters most, because the wrong technique causes an incident. Active network scanning of a live control segment can disrupt devices that were never designed to receive unexpected traffic. Discovery here is passive: span-port monitoring with OT-aware tooling, plus documentary review.

The documents are better than most IT teams expect. Management of change (MOC) records, the formal procedure governing any modification to a plant, contain a history of every firmware update and configuration change with dates and approvals. Asset registers maintained for safety and insurance purposes list device models and installation dates. Vendor firmware documentation states what a device’s cryptographic stack supports, which is frequently a fixed implementation with no update path.

Device lifecycles in this domain are measured in decades, and a meaningful share of what you discover will have no migration path at any price. That’s a valid inventory outcome, recorded as compensating controls: an encryption gateway at the boundary between the control network and the corporate network, network segmentation, and a documented, dated risk acceptance with a named accepting owner. What isn’t valid is an empty field that a dashboard renders as “in progress.”

What you find by counting

Connected devices and field sites are a counting problem before they’re a cryptography problem. Sensors, smart meters, fleet telematics, medical devices, retail point-of-sale terminals, and remote substations are discovered through procurement records, fleet management systems, and device bills of materials rather than through the network. A device with a fixed cryptographic implementation and a few tens of kilobytes of flash memory will not run ML-KEM, so the migration path is replacement, and replacement at scale is a procurement and logistics program with a multi-year calendar.

For distributed field sites, add a field to the record that IT inventories never need: whether the change requires someone to physically travel there. A configuration change that takes four minutes in a data center takes a scheduled site visit at a remote pumping station, and the count of sites, not the count of devices, drives the timeline.

What every record has to say

Ten fields. A cryptographic bill of materials (CBOM) is the machine-readable form of exactly this record, and whether you produce one or maintain a structured register, the content is the same.

• Asset identifier and owner. A named accountable individual, not a department.
• Algorithm, key size, and purpose. RSA-2048 for transport is a different problem from RSA-2048 for code signing.
• Where it’s implemented. Hardware, a shared library, application code, or a vendor binary. This field predicts effort better than any other.
• Who can change it. The practical form of crypto-agility. Your team, another business unit, a vendor’s release schedule, or a counterparty’s specification.
• Dependencies, both directions. What this asset needs before it can migrate, and what breaks if it migrates first.
• Confidentiality lifetime. How many years the data must stay secret. This is the harvest-now-decrypt-later exposure: an adversary copying encrypted traffic today can decrypt it once a sufficiently capable quantum computer exists, so ten-year secrets are already at risk and single-day secrets largely are not.
• Integrity and authentication exposure. Separate from confidentiality, and often the larger risk for short-lived data.
• Jurisdiction and applicable deadline. Which regulator’s clock this asset runs on.
• Discovery method, date, and confidence. Scan evidence and a vendor email are not the same grade of information.
• Disposition. Migrate, replace, gateway, accept, or retire, with the date the decision was made.

Two records, filled in

Take a networked door controller on the corporate access-control system. Owner: the facilities director. Discovery: physical inspection with the building engineer, plus the maintenance contract. Implementation: TLS with an RSA certificate to the management server, and a proprietary channel to the readers that the vendor won’t document. Changeable by: the vendor only, through firmware, with no published post-quantum roadmap. Dependencies: authenticates against the corporate identity platform, so it inherits whatever that platform supports. Confidentiality lifetime: negligible. Integrity exposure: high, since forged credentials open doors. Disposition: segment the controller behind a gateway, accept the residual risk with a named owner, and revisit at the hardware refresh already funded in the facilities capital plan.

Now an enterprise payments application. Owner: the line-of-business IT lead. Discovery: dependency scan of the build pipeline plus endpoint scanning, both high confidence. Implementation: transport security through the shared platform library, message signing with ECDSA P-256 in a format the settlement scheme defines, signing keys in an HSM. Changeable by: your team for transport, nobody for the signing format until the scheme publishes a post-quantum profile. Dependencies: horizontal, to a settlement gateway operated by a third party, which means both sides need compatible hybrid support during the transition or the integration fails. Confidentiality lifetime: short. Integrity exposure: severe once a cryptographically relevant quantum computer exists, meaning a machine capable of recovering private keys from public ones.

Two assets, two owners, two entirely different critical paths. Neither is discoverable by the method that finds the other, and no aggregate percentage tells you anything useful about the pair.

Dependencies are inventory data

Sequencing failures in migration programs trace back to dependency information that lived in an architect’s head rather than in a field. Three kinds are worth capturing at discovery time, while the person who knows the answer is in front of you.

Vertical dependencies run from central infrastructure outward: an application can’t request post-quantum certificates until the certificate authority issues them. Horizontal dependencies cross system boundaries at the same level, and they’re the ones that break in production. If a signing system migrates before its verifying counterpart, the integration stops working, so both records need to point at each other. External dependencies are vendor and provider delivery dates, which means every one of them is somebody else’s commitment and needs a date, a source, and a fallback.

Report by domain, never as one number

An estate-wide “sixty-five percent migrated” figure hides the only distinction anyone needs. Sixty-five percent, with the central and cloud domains near complete and industrial OT barely assessed, describes a program that’s on track. The same figure, with a stalled certificate authority upgrade blocking every downstream application, describes a program in trouble. Report by domain cluster, and report discovery confidence alongside migration status. A domain that’s ninety percent migrated against an inventory built from guesswork isn’t ninety percent anything.

Five things to do first

1. Get written agreement, at executive level, that every system using public-key cryptography is in scope. Without it, the non-IT domains stay invisible until year three.
2. Assign a discovery method to each domain before you start, and staff each one appropriately. Passive monitoring for industrial OT, questionnaires for vendor-managed services, finance records for shadow IT.
3. Define the record fields before the first scan runs. Retrofitting a schema across thousands of rows costs more than designing it once.
4. Capture dependencies during discovery, while the engineer who knows them is in the room.
5. Record confidence honestly. An inventory that distinguishes measured facts from vendor claims is worth more than a complete-looking one that doesn’t.

The organizations that finish migration on their regulator’s schedule are, in our experience of what the work demands, the ones that spent longer than felt comfortable on this stage. Discovery produces the artifact everything else in the program is built from, and it’s the deliverable that most repays doing properly the first time.

For the full migration methodology across all phases, see pqcframework.org. For deeper technical treatment of the standards and the threat model, PostQuantum.com goes considerably further than an inventory guide can.

Quantum Academy runs certification programs for practitioners leading post-quantum migration work. The current portfolio is at quantumacademy.com/.