How should security teams inventory certificates that use post-quantum algorithms before standardisation is complete?

Security teams should start with discovery and inventory, because you cannot govern what you cannot see. Track every certificate that uses post-quantum or test algorithms, including non-standardized ones, and record the object identifier in certificate details. That gives administrators a reliable way to identify, classify, and plan for migration while standards and tooling continue to evolve.

Why inventory comes first for post-quantum certificates

Before standardisation is complete, the practical problem is not deciding which post-quantum certificate is “best”, it is finding every place one exists and making it visible to the teams that own it. That is a discovery and classification exercise first. Record the certificate subject, issuer, validity window, environment, and the certificate-related identity context needed to understand where it is used.

For post-quantum or test algorithms, the key detail to preserve is the algorithm object identifier in the certificate itself. That gives you a stable way to distinguish experimental issuance from conventional crypto and to separate certificates that only look similar in subject or issuer data. Without that field, inventory becomes ambiguous the moment multiple pilot algorithms coexist.

Inventory should also capture where the certificate terminates, what service depends on it, and whether it is externally trusted, internally issued, or part of a lab or pilot chain. That is why a pure certificate dump is not enough. The operational unit is the certificate plus its dependency path, because migration planning depends on where replacement will actually break traffic or trust.

What to record so the inventory stays usable during migration

A usable inventory is one that supports search, grouping, ownership, and change planning. At minimum, record certificate fingerprint, serial number, subject alternative names, issuer, expiry, environment, application owner, and the algorithm OID. If your tooling can also capture whether the certificate is a leaf, intermediate, or test artifact, that extra classification will reduce confusion when standards and implementations diverge.

It is also worth normalising naming so analysts can filter by algorithm family rather than by ad hoc comments. Post-quantum pilots often fail operationally because the inventory is technically complete but practically unusable. The finding in The NHI and Secrets Risk Report that exposed secrets and identity material are often distributed outside central repositories is a reminder that discovery must span endpoints, CI/CD systems, configuration stores, and lab tooling.

When a certificate is tied to a test or non-standard algorithm, mark that status explicitly. Do not assume the label will survive export, renewal, or ticketing workflows. The inventory should make it obvious which objects are production candidates, which are interoperability tests, and which exist only to validate tooling or vendor support.

How to govern the inventory until standards catch up

Once the certificates are found, treat the inventory as a control surface, not a static spreadsheet. Assign ownership, define review cadence, and track whether each certificate is still needed, where it is trusted, and what replacement path exists if the algorithm becomes unsupported. This is especially important for long-lived certificates, because crypto transitions usually fail at the edges, where legacy systems, embedded devices, and vendor-managed services lag behind.

That governance model aligns with NIST SP 800-57 Key Management, which frames cryptographic material as something that must be managed across its full lifecycle, not just issued once. It also fits the broader lifecycle view in The Critical Gaps in Machine Identity Management report, where certificate rotation and identity lifecycle are treated as operational risks, not inventory trivia.

The most useful governance question is not “Do we have post-quantum certificates?” but “Can we prove where each one is, who owns it, what trusts it, and how fast we can replace it?” If the inventory cannot answer those questions, the organisation is not ready for migration planning.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM — Asset Management	Inventorying certificates is asset visibility for cryptographic trust material.
Recommendation — Inventory all certificate assets and ownership so migration scope stays visible.
CIS Controls v8	1 — Inventory and Control of Enterprise Assets	Certificate discovery depends on knowing where crypto assets exist across the estate.
	3 — Data Protection	Certificates are cryptographic material that must be tracked for protection and lifecycle control.
Recommendation — Discover certificate-bearing systems and keep the asset inventory current. Track cryptographic objects and associated metadata to support secure handling.
NIST SP 800-63	IAL — Identity Assurance Level	Certificate handling affects identity proofing and trust assurance in certificate-backed identity contexts.
Recommendation — Preserve certificate trust attributes so identity assurance decisions remain defensible.

Practitioner Guidance

What to prioritise: Start with discovery sources that are most likely to hold certificates outside normal PKI records, including load balancers, reverse proxies, CI/CD jobs, container images, appliance exports, and test environments. Those are the places where experimental algorithms are most likely to appear first and where they are easiest to miss.

What to verify: Make sure the inventory can distinguish algorithm OID, certificate role, ownership, and trust scope. If the same certificate appears in multiple systems, preserve one canonical record and attach every dependency to it; otherwise migration planning will fragment across duplicate entries.

Common mistake: Treating post-quantum certificates as a cryptography-only topic. In practice, the hard part is operational traceability, because standardisation gaps create a moving target for tooling, policy, and vendor support. The inventory is valuable only if it survives those changes.

Practitioner takeaway: The goal is not to categorise every new algorithm perfectly on day one, but to make every certificate discoverable, attributable, and replaceable before the ecosystem settles.