Post-quantum cryptography inventory: a practical starting guide

Before a migration plan can be credible, someone needs to know where the cryptography is.

MicroApz Security · Updated 2 November 2026

Ask a team where its cryptography lives and the first answers may be certificates, encrypted connections and a key-management service. Then the list grows. A vendor library signs software updates. An integration depends on a supplier. An appliance has a replacement cycle measured in years.

This is why post-quantum preparation begins with an inventory. A migration plan cannot account for dependencies nobody has identified.

Open the phone-size infographic for larger text ↗

An inventory is a living decision tool, not a one-time spreadsheet exercise.

Why does post-quantum cryptography matter?

A sufficiently capable future quantum computer could break some public-key algorithms used today. Post-quantum cryptography (PQC) refers to cryptographic approaches designed to resist attacks by such computers as well as conventional ones. Organisations also need to consider information that must remain confidential for many years: data captured now could be held for future decryption.

NIST published NIST IR 8547 in October 2026, describing its transition approach for quantum-vulnerable digital signatures and key-establishment schemes. The report and applicable obligations should inform your decisions; do not assume every organisation has the same legal deadline.

What belongs in a cryptographic inventory?

• Business purpose: the data, transaction or software function protected.
• Location: application, service, infrastructure component or supplier.
• Cryptographic details: known algorithms, protocols, libraries, certificates and key types—never the secret key material itself.
• Ownership: technical and business contacts able to assess and approve change.
• Dependency and lifecycle: vendor support, renewal dates, replacement constraints and interfaces.
• Confidence and next action: verified, inferred or unknown; evidence source, owner and review date.

NIST’s migration FAQ discusses discovery and inventory in more detail.

Separate key establishment from signatures

A TLS connection may use different mechanisms for certificate signatures, authentication, key establishment and symmetric encryption. A single “TLS uses RSA” field hides those distinctions. Record the actual negotiated protocol and key exchange, certificate-chain signatures, termination point, client population and library versions separately.

NIST’s FIPS 203 specifies ML-KEM for key encapsulation; FIPS 204 and FIPS 205 specify ML-DSA and SLH-DSA digital signatures. They solve different problems. Product support for one does not prove support for the others, interoperability, secure configuration or a validated implementation.

A migration test that reveals hidden dependencies

1. Inventory the gateway, certificate chain, client libraries, load balancer, inspection proxy and downstream connection. Record versions and who owns each.
2. In an isolated representative environment, enable a vendor-supported configuration and record the actual negotiated result for each client class. Do not infer success merely from a configuration checkbox.
3. Measure connection failures, handshake size and latency, CPU, certificate handling and compatibility with proxies. Test failure and rollback, including older clients.
4. Capture configuration, versions, test results and exceptions. Approve a phased release only after owners resolve unacceptable failures.

Use vendor documentation and current standards to select an interoperable configuration; do not invent a custom hybrid protocol. The inventory should distinguish planned support from a capability actually enabled and verified.

NIST describes the different purposes of the approved schemes in its FIPS announcement.

Worked example: customer portal

These are illustrative inventory rows, not claims about a particular product.

How should you prioritise?

1. Data lifetime: how long must the information stay confidential?
2. Business consequence: what would failure or disclosure affect?
3. Migration lead time: are there legacy devices, contracts or long replacement cycles?
4. Dependency and uncertainty: do suppliers or external partners need to change too?
5. Testability: can you verify interoperability, performance and rollback before production?

Example of a useful first row

Illustrative record: “Customer portal external connection; platform team owner; TLS termination at managed gateway; certificate and protocol details confirmed from configuration on [date]. Supplier’s post-quantum support is unknown. Data includes long-lived confidential records. Next: platform owner to obtain the gateway’s supported options and test interoperability with representative clients by [date].”

That is a starting point, not a declaration that the entire connection is quantum-safe or vulnerable. A certificate, a key-establishment mechanism and a symmetric cipher serve different purposes. Capture the actual algorithms and versions before deciding what must change; do not assume every use of cryptography needs the same replacement.

Questions to send a supplier

• Which algorithms and protocols protect this specific product and interface today?
• Which post-quantum or hybrid options are supported, in which versions, and with what limitations?
• What compatibility, performance and rollback testing do you recommend for our configuration?
• Which dependencies or customer-side changes remain our responsibility?

Ask for product-specific documentation and a contact for unresolved answers. Record a supplier roadmap as a plan, not as evidence of a capability already deployed.

First actions for your team

Hold a discovery session for one critical service. Combine architecture records with authorised technical discovery and supplier questions; each has blind spots. Assign owners to unknowns, then test transition options in a representative environment. Avoid changing cryptographic configurations solely because they appear on a generic list: verify the function, support and consequences first.

Why one scanner is not an inventory

A network scan may reveal a visible TLS endpoint, but it will not necessarily identify code-signing keys, embedded libraries, offline devices or a supplier’s internal dependencies. Combine authorised discovery with software inventories, architecture reviews, certificate records and product-specific supplier evidence. Mark an unverified item as unknown and assign an owner; silence is not proof of safety.

This guide is an inventory starting point, not a complete migration plan or a substitute for applicable obligations.