Cryptographic Inventory for Post-Quantum Migration

Migration to post-quantum cryptography is, first and foremost, an inventory challenge. No organization can safely replace what it cannot locate, classify, and connect to business processes. The risk is not limited to legacy servers or expired certificates. It also appears in embedded libraries, third-party integrations, industrial devices, long-retention backups, and protocols that cross networks without clear ownership.

The starting point is straightforward: discover where the organization uses public-key cryptography vulnerable to quantum advances and determine what must change first. NIST has been structuring the migration journey in phases, with explicit emphasis on cryptographic visibility, risk management, interoperability, and testing. The NCCoE's updated guidance reinforces that adopting post-quantum cryptography requires a comprehensive inventory, not an isolated product update.

Why is the cryptographic inventory the first meaningful deliverable?

Because the algorithm is rarely visible to those who operate the business. An application may use TLS for transport, X.509 certificates for authentication, a cryptographic library to sign files, and a key vault to protect secrets. Each layer may have its own vendor, update cycle, and criticality level.

A cryptographic inventory is the structured record of assets, algorithms, keys, certificates, protocols, libraries, dependencies, and owners that make up the company's cryptographic controls. It differs from a traditional IT inventory. A CMDB indicates that a server exists. The cryptographic inventory must indicate how it protects data, which connections it establishes, which keys it consumes, and what consequences arise if the mechanism needs to change.

Urgency does not stem from an exact forecast of when a cryptographically relevant quantum computer will emerge. It stems from the length of the transition. Sensitive data can be captured now and decrypted in the future, a scenario known as harvest now, decrypt later: encrypted content is collected today to be broken once sufficient computing capacity becomes available. DigiCert's global report published in 2026 identified an important gap between executive awareness and technical execution: recognition of the risk is growing, but asset discovery and the deployment of certificates resistant to quantum risk are still at an early stage in much of the market. View the report.

The inventory, therefore, is not audit documentation. It is the mechanism that turns a long-term threat into short-term operational decisions.

What should be included in the inventory scope?

The scope must follow the flow of information, not just the server list. Start with four groups of evidence.

1. Data with a long confidentiality window

Classify information whose value persists for years: intellectual property, clinical data, financial records, contracts, pricing strategies, credentials, biometric data, and personal information subject to legal retention obligations. For each class, record how long it must remain confidential.

This window determines priority. Data that loses relevance in six months may tolerate a gradual approach. A collection that must remain confidential for ten years should enter the plan early, even if the corresponding system does not appear critical from an availability perspective.

2. Public-key cryptography usage points

Map where RSA, elliptic curve cryptography, Diffie-Hellman, digital signatures, and certificates are used. This includes TLS, VPN, SSH, corporate email, APIs, code signing, federated authentication, mobile devices, corporate Wi-Fi, DNSSEC, BGP, internal PKI, and machine-to-machine integrations.

A recent review of widely used protocols indicates that TLS and Signal have advanced further in hybrid key-exchange mechanisms, while SSH and IPsec have standards available but less widespread production adoption. The study also highlights that authentication migration tends to be more complex than key exchange, especially when signature size affects protocol and equipment limits. Read the comparative analysis.

3. Hidden implementations in code and the software supply chain

Look for cryptographic libraries embedded in applications, containers, SDKs, firmware, appliances, and legacy packages. It is common to find dependencies that use obsolete algorithms without the product team being aware of them. Perform software composition analysis, repository inspection, image scanning, and reviews of libraries called by critical applications.

Include versions. Knowing that an application uses OpenSSL, Java, .NET, a cloud SDK, or an authentication library is not enough. The ability to adopt post-quantum algorithms depends on versions, parameters, protocol compatibility, and client behavior.

4. Third parties and managed services

SaaS, cloud providers, payment gateways, identity platforms, CDNs, B2B partners, and device manufacturers must be included in the inventory. For each vendor, record which data is encrypted, who controls the keys, which algorithms are used, how updates are delivered, and whether a public migration plan exists.

The recurring mistake is treating the purchased service as a secure black box. In a post-quantum transition, the contract must provide visibility into the timeline, compatibility, testing responsibilities, and alternatives if the vendor delays readiness.

How do you turn technical discovery into business priority?

The asset list will be extensive. The value lies in assigning a consistent priority. A practical approach is to assess each item across five dimensions: data sensitivity, confidentiality duration, external exposure, operational dependency, and migration difficulty.

External exposure measures whether the asset accepts public connections, integrates with partners, or transmits over untrusted networks. Operational dependency measures the impact if a cryptographic change causes incompatibility, authentication failure, or performance degradation. Migration difficulty accounts for legacy systems, unsupported firmware, vendor dependency, specialized hardware, and the volume of external clients.

The outcome should not be an opaque score. Use clear bands:

• Wave 1: long-lived data, exposed services, central authentication, PKI, and high-volume integrations.
• Wave 2: critical internal applications, VPNs, development platforms, code signing, and branch-to-branch connectivity.
• Wave 3: lower-exposure assets, lab environments, applications being retired, and devices that depend on physical replacement.

There is an important distinction between confidentiality and authenticity. Replacing key exchange in external connections can reduce the risk of interception and future storage first. Migrating signatures, on the other hand, affects certificates, tokens, software updates, and chains of trust. Both workstreams require dedicated governance, even when they appear in the same application.

How do you organize migration without causing operational disruption?

The answer is to migrate by capability, not by product. A mature organization does not simply decide to “enable PQC.” It creates the conditions to test, adopt, measure, and safely roll back changes.

Start with a validation environment that reproduces real traffic, clients, devices, and policies. Test key and signature sizes, latency, packet fragmentation, CPU consumption, load balancer limits, proxy compatibility, and legacy client behavior. In high-volume protocols, small size differences can affect cost and performance.

Then, where possible, adopt hybrid mechanisms. Hybrid cryptography combines a classical and a post-quantum mechanism during the transition. The goal is to preserve compatibility while incorporating protection against quantum risks. It does not eliminate the need for complete migration, but it reduces the risk of immediately relying on a single large-scale change.

The experience published by Meta in April 2026 shows that migration requires coordination across inventory, protocol engineering, performance testing, and dependency management. The company highlights that discovering cryptographic usage must precede deployment decisions and that challenges vary according to each service's context. Meta Engineering details the technical lessons.

Also define rollback criteria. If a change causes higher error rates, incompatibility with a critical client, or an impact beyond the latency budget, the team must be able to disable the configuration without manually restoring servers. This requirement distinguishes a controlled pilot from a risky production change.

What is crypto-agility, and why should it become an architecture requirement?

Crypto-agility is the ability to replace or reconfigure cryptographic algorithms, keys, parameters, and libraries without rewriting entire systems. It is not a specific product. It is an architectural property.

A crypto-agile application avoids hard-coding algorithms. It centralizes policies, uses standardized APIs, separates business logic from cryptographic implementation, and maintains key-rotation mechanisms. It also records where each certificate is used and enables new configurations to be tested with limited groups.

The absence of this capability creates cryptographic debt. It appears when an apparently simple change requires modifying hundreds of repositories, recompiling clients, updating physical devices, and renegotiating external integrations. The greater the debt, the sooner the asset should be discovered and addressed, even if its final migration takes place later.

Include crypto-agility requirements in procurement and renewals. Direct questions help: does the vendor support the post-quantum standards defined by NIST? Is support available for hybrid modes? What is the update timeline for managed versions? Can configuration be automated through an API? Will legacy clients continue to work? How does the company communicate algorithm changes?

NIST has already published post-quantum standards that can be implemented across multiple information protection scenarios. This shifts the conversation from research to engineering planning, although adoption still depends on the maturity of each protocol and vendor. NIST's official PQC page summarizes the available standards.

Who should govern the post-quantum migration program?

Responsibility cannot remain limited to the cryptography team, where one exists. The program needs sponsorship from security, architecture, platform, development, infrastructure, legal, procurement, and data owners. Each function controls part of the risk surface.

Create a lean committee with monthly decision-making and simple metrics. The key ones are: percentage of assets with discovery complete; percentage of data classified by confidentiality window; coverage of assessed vendors; proportion of certificates and integrations with a defined owner; critical assets eligible for hybrid testing; and exceptions with a remediation deadline.

Avoid measuring only “percentage migrated.” This is a lagging indicator and can drive rushed changes. Before migration, the strongest signal of progress is the reduction of unknown areas. An asset without an owner, an identified algorithm, or update evidence is a risk that cannot be correctly prioritized.

The role of governance is to keep decisions traceable. Every exception should record the rationale, affected data, compensating control, involved vendor, executive owner, and review date. In regulated environments, this discipline also demonstrates that the organization treated the transition as an architectural risk rather than a one-off reaction to a technology trend.

What 90-day plan creates real momentum?

In the first 30 days, establish the scope, asset taxonomy, and risk criteria. Select three to five high-confidentiality data flows. Assign owners for systems, certificates, keys, and integrations. In parallel, set up evidence collection through network scanning, certificate management, repositories, and observability tools.

Between days 31 and 60, consolidate findings into a single inventory. Identify algorithms, protocols, versions, dependencies, and ownership gaps. Classify assets across the three waves. Send technical questionnaires to critical vendors and open remediation plans for unsupported assets or assets with no viable update path.

Between days 61 and 90, select two controlled test cases. One may be an external TLS connection with hybrid support. The other may be an internal application with high-value data and a predictable change cycle. Measure performance, compatibility, errors, and operational effort. At the end, present the executive committee with a risk map, not merely a list of technologies.

The post-quantum transition will be long. The organization that starts with inventory, prioritization, and crypto-agility gains freedom of choice. The one that waits for a definitive date will likely discover too late that its biggest problem was not the algorithm: it was not knowing where it was.