Map your entire certificate estate in days, not quarters

Every post-quantum program starts with the same question: what cryptography do we actually have? For most organizations the honest answer is "we're not sure." Certificates are issued by many teams, keys live in cloud services and code, and spreadsheets go stale the week they are finished. This playbook shows how to build a reliable inventory quickly.

Start from the outside in

Your internet-facing surface is the fastest place to begin and often the most exposed. Enumerate your registered domains and subdomains, then inspect every reachable TLS endpoint. Record the certificate chain, key algorithm and size, signature algorithm, supported protocol versions and key-exchange groups. Certificate Transparency logs are a valuable cross-check: they reveal certificates issued for your domains that internal records may have missed.

This external pass needs no agents and no access to internal systems, so it can usually be completed in hours. It also produces quick wins, such as expired certificates, weak keys or deprecated protocol versions.

Then connect the systems of record

Next, read from the places cryptography is managed. Cloud key management services, secrets managers and certificate authorities hold authoritative lists of keys and certificates. Connecting them through read-only APIs adds internal certificates, signing keys and encryption keys that never appear on the public internet.

Kubernetes clusters, load balancers and service meshes deserve particular attention. They frequently issue short-lived internal certificates automatically, which is good practice but makes manual tracking impossible.

Look inside code and dependencies

A large share of cryptographic usage lives in application code: libraries that call RSA directly, hard-coded algorithm choices and dependencies that pull in older cryptographic packages. Scanning repositories and software bills of materials surfaces these uses and shows which teams own them. This is where migration effort is often greatest, so finding it early matters.

Normalize into a cryptographic bill of materials

Raw discovery data is noisy. The goal is a cryptographic bill of materials (CBOM): one record per cryptographic asset, with its algorithm, parameters, location, owner and the data it protects. The CycloneDX standard includes a format for this, which makes the inventory portable between tools and easy to share with auditors.

Deduplicate aggressively. The same certificate may appear on dozens of hosts, and the same library in hundreds of services. Grouping them reveals the real number of migration decisions you need to make, which is usually far smaller than the raw asset count.

Assign owners and data context

An inventory without owners does not get fixed. Map each asset to a team using cloud tags, repository ownership or CMDB records. Then attach data context: what kind of information does this endpoint or key protect, and how long must it stay confidential? That context is what lets you rank quantum risk rather than simply listing assets.

Keep it current

Certificate estates change daily. Schedule recurring discovery, alert on new certificates using vulnerable algorithms, and add policy checks to CI pipelines so new code defaults to approved cryptography. An inventory that refreshes itself stays useful for the entire migration rather than becoming another stale spreadsheet.

Where this leads

With a complete, owned and contextualized inventory, the rest of the program becomes tractable: you can score risk, prioritize systems carrying long-lived data and build a migration roadmap with realistic timelines. Discovery is not the glamorous part of post-quantum security, but it is the part everything else depends on.