Every PQC roadmap, every regulator, every agency opens with the same unglamorous instruction: inventory your cryptography first. There’s a reason it’s always step one, and it isn’t bureaucratic throat-clearing.
The reason is that all three of the pressures (horses) from the previous article, the cert validity compression, the post-quantum migration, and the FIPS sunset, share a single precondition. We can’t shorten the renewal cycle on a certificate we don’t know exists, we can’t swap an algorithm we can’t locate, and we can’t prove a boundary is validated if we’ve never established where the boundary is. Discovery isn’t the first task because someone enjoys paperwork. It’s the first task because every other task lies undefined until it’s done. The deadlines already have dates.
Our cryptographic inventory does not yet exist.
Start with what “cryptography” means here, because the word does more work than people expect. It’s not your web TLS certificates alone:
- It’s your TLS certificates AND
- The keys behind the code-signing pipeline
- The algorithms inside your VPN and SSH
- The cipher suites your load balancers negotiate,
- The crypto library static-linked across three dependencies deep into an application nobody’s patched since 2019
- The keys sitting in an HSM whose firmware you never audited (let’s be honest, not many people have)
- The partner API’s and Saas integrations you call, whose TLS and cert lifecycles you don’t control but whose failure still breaks your pipeline anyway
The machine-readable artifact for capturing all of that is the Cryptography Bill of Materials (CBOM), which extends a software Bill of Materials (SBOM) you may already produce [1] down into cryptographic specifics: which algorithm, which key length, which library, used where.
The inventory itself is a federal requirement rather than a suggestion. NSM-10 and OMB M-23-02 direct agencies to maintain a prioritized inventory of cryptographic systems and to report on it, and NIST’s transition guidance treats that inventory as the prerequisite for everything downstream [2][3]. The CBOM is the format that federal discovery work, including NIST’s National Cybersecurity Center of Excellence (NCCoE) migration project, increasingly converges on [4], even where the binding mandate names the inventory rather than the file.
Here is the trap, and it’s quiet. Cryptographic inventories that are supposed to cover everything tend to collapse into TLS certificate inventories, because certs are the easiest thing to scan and count. Resist letting the scope collapse, but do let the sequencing reflect the urgency of the other deadlines:
- Certificates go to the front of the inventory & remediation queue, not because they matter more than code signing or VPN keys, but because they are where the first hard, externally imposed deadline lands.
- The 47-day impacted regime in the next piece has a date on it.
- Your code-signing migration, for now, does not.
So you inventory everything and you triage certificates first, and those are two different statements that are dangerously easy to blur into one.
The hard part of discovery is that it is never complete, and the entries that hurt you are the ones you didn’t find. You will catch the certificates you provisioned on purpose. You will miss the self-signed cert an engineer stood up for a staging box in 2021, the key baked into a firmware image, the dependency that quietly pulls in its own TLS stack. No single method finds everything:
| Method | Sees | Misses |
|---|---|---|
| Network scanning | What answers on a port | Anything not listening/exposed |
| CT log mining | What was publicly logged | Internal/non-public certs, anything pre-CT-era |
| Host agents | What’s installed on a managed endpoint | Unmanaged hosts, shadow IT |
| Source analysis | What’s compiled/linked in | Runtime-only config, anything not in the repo you’re scanning |
A realistic inventory process coordinates across all of them and still assumes it is incomplete, because the alternative is learning about the gap when a certificate you never knew about expires at two in the morning. Have I received that call? Yup.
One discovery detail is worth singling out now, because it returns later in this article series with real consequences. When your inventory records that an appliance is “FIPS validated,” that sentence isn’t yet a fact, it’s three possible facts. The validated boundary might be the software cryptographic module, the appliance as a whole, or an attached hardware security module, and on a platform like F5’s BIG-IP those are genuinely different scopes with different validation status [5]. A CBOM entry that says “validated” without recording which boundary it means is an entry that will mislead you exactly when you can least afford it, during a migration whose whole premise is knowing what is actually certified. Record the boundary, not just the checkmark.
None of this is glamorous, most of it is tedious, which is precisely why it gets deferred until a deadline drags it into the open. A finished inventory is the first time most teams see their real cert count. The second that number is on screen, the next problem introduces itself, because every one of those certs is about to need renewing far more often than it does today. Guess what topic we’re teeing up for in the next article?
References
[2] National Security Memorandum 10 (NSM-10), May 2022, and Office of Management and Budget Memorandum M-23-02, “Migrating to Post-Quantum Cryptography,” November 2022
[3] NIST IR 8547, Transition to Post-Quantum Cryptography Standards.
[4] NIST National Cybersecurity Center of Excellence. SP 1800-38, Migration to Post-Quantum Cryptography