Building a cryptographic inventory for PQC

The current position

NIST finalized its first three post-quantum cryptography standards in August 2024:

FIPS 203 — ML-KEM, for key establishment
FIPS 204 — ML-DSA, for digital signatures
FIPS 205 — SLH-DSA, a hash-based digital-signature standard

NIST now tells organizations to begin migrating. Its transition work identifies widely deployed public-key mechanisms such as RSA, finite-field and elliptic-curve Diffie-Hellman, ECDSA, and EdDSA as quantum-vulnerable. NIST’s transition document, IR 8547, is still listed as a draft as of July 2026; its dates are important planning inputs, not a substitute for the final rules and sector-specific obligations that apply to your organization.

The first operational step is less glamorous than choosing an algorithm: find where cryptography is used, what it protects, who depends on it, and how it can be changed without breaking the business.

A certificate list is not a cryptographic inventory

TLS certificates are one useful source. They are not the complete estate. Cryptography also appears in:

Application and service-to-service authentication
VPNs, remote access, Wi-Fi, and network appliances
Public key infrastructure and internal certificate authorities
Code, package, container, firmware, and document signing
Database, disk, file, backup, and object-storage encryption
HSMs, cloud KMS platforms, secrets managers, and embedded keystores
Identity tokens, SSO, device credentials, and machine identities
APIs, message queues, file-transfer systems, and partner connections
Custom applications, third-party libraries, appliances, and managed services

An inventory becomes useful only when those technical observations are connected to owners, data, services, dependencies, and replacement paths.

The minimum useful record

For each cryptographic use, capture at least:

Field	What to record	Why it matters
Business service	Application, system, environment, owner, and criticality	Turns a scan result into something the organization can prioritize
Protected information	Data type, sensitivity, location, and required confidentiality lifetime	Highlights information exposed to harvest-now-decrypt-later risk
Cryptographic function	Encryption, key establishment, signature, authentication, hashing, or key wrapping	Different functions require different migration paths
Implementation	Algorithm, parameters, key size, library or provider, version, protocol, and configuration	Names what is vulnerable and where the change must occur
Keys and certificates	Location, custody, KMS or HSM, issuance, rotation, expiration, backup, recovery, and destruction	Migration fails when the algorithm changes but the key lifecycle does not
Dependencies	Clients, servers, partners, devices, vendors, standards, and backward-compatibility requirements	Most cryptographic transitions fail at an interface, not inside one component
Change authority	Internal team, product vendor, cloud provider, partner, or standards body	Shows where you can act and where you must influence a roadmap
Evidence	Discovery method, source, confidence, and last verification date	Separates measured facts from assumptions and keeps the record maintainable

How to discover the estate

Use several methods and reconcile them. No single scanner sees everything.

Start with authoritative systems. Export certificate records, PKI databases, HSM and KMS objects, secrets-manager metadata, load balancer configurations, code-signing systems, and network-device inventories.
Observe the environment. Use network discovery, configuration analysis, repository searches, software-composition data, and runtime telemetry to find protocols and libraries actually in use.
Trace critical business services. Walk a transaction end to end. Identify every place confidentiality, integrity, identity, or trust depends on cryptography.
Question vendors precisely. “Are you quantum safe?” invites a marketing answer. Ask which products, versions, protocols, algorithms, hybrid modes, interoperability dependencies, and release dates are supported.
Validate with owners. A technical finding needs a human owner, a business purpose, and a decision about whether the system is active, duplicated, abandoned, or scheduled for replacement.

Treat a cryptographic bill of materials or discovery-tool export as evidence feeding the inventory—not automatically as the inventory itself.

How to prioritize migration

Do not sort only by algorithm name. Start with exposure and replacement difficulty.

1. Long-lived sensitive information

Data that must remain confidential for years deserves early attention because an adversary can capture encrypted traffic or archives now and retain them for later cryptanalysis. Record the required secrecy lifetime, not merely the system’s current risk rating.

2. Trust anchors and high-impact signatures

Root and issuing certificate authorities, firmware signing, code signing, identity infrastructure, and long-lived device credentials have wide blast radii and difficult rollover procedures. Their migrations require rehearsal.

3. Externally exposed and highly connected protocols

Public endpoints, partner links, VPNs, APIs, and large service meshes combine exposure with interoperability constraints. A server may support a new mechanism long before every client and intermediary does.

4. Embedded systems and long replacement cycles

Appliances, medical devices, industrial equipment, vehicles, building systems, and firmware may remain deployed longer than the cryptography designed into them. Vendor and procurement timelines can dominate the technical work.

5. Dependencies you do not control

Managed services, SaaS platforms, commercial software, partner systems, and standards-based ecosystems need a tracked vendor roadmap, contractual leverage where appropriate, and an exit or compensating-control plan.

Avoid three common mistakes

Replacing algorithms directly in application code

PQC changes key sizes, message sizes, certificate profiles, protocols, performance, failure modes, and operational procedures. Use supported implementations and updated protocols; test interoperability and rollback. Do not turn a standards migration into a collection of local cryptographic inventions.

Treating every primitive as equally urgent

The most disruptive quantum threat is to widely used public-key cryptography. NIST’s transition material continues to allow approved symmetric primitives with at least 128 bits of classical security. Inventory symmetric cryptography too, but prioritize according to the actual transition guidance and your data risk.

Building a spreadsheet that immediately goes stale

An inventory is an operating capability. Connect it to certificate management, architecture review, procurement, vulnerability management, change control, and system retirement. Define who updates each record and which events trigger revalidation.

That is crypto agility in practical form: knowing what must change, having an approved path to change it, and being able to complete the transition without losing security or availability.

A useful first 30 days

Name an accountable migration owner and the teams that must contribute data.
Define the inventory schema and a single place to maintain it.
Select five critical services and trace their cryptographic dependencies end to end.
Export existing certificate, KMS, HSM, PKI, and network records.
Identify information with long confidentiality requirements.
Send precise PQC-readiness questions to the vendors behind those five services.
Record unknowns explicitly and turn them into assigned discovery work.
Produce an initial risk-ranked roadmap—without purchasing a “quantum safe” product merely to show activity.

Primary references

Reviewed July 2026. Standards and transition guidance continue to evolve; verify current requirements before making an implementation decision.

Plan an inventory or migration review