The CBOM Starter Checklist

Summary

Ask a security team where their cryptography lives and you will usually hear about TLS certificates and the internal PKI. Both true. Both a fraction of it.

The rest sits in places nobody put on a list. Badge readers. Security cameras. Operational technology still running software written in the 1990s. SSH keys generated by someone who left years ago. Hard-coded keys in an application nobody has opened since the last migration. None of it was ever in the certificate program, so none of it shows up in certificate tooling.

That is the wall most organizations hit on day one of a post-quantum migration, well before anyone picks an algorithm. This checklist will not produce a complete cryptographic bill of materials on its own. It will tell you what belongs in one, what fields each entry needs to be useful, and how to sequence the work so the first ninety days produce something you can act on.
‍

What is inside

1. Define scope
   A working scope list across certificates and PKI, keys outside the certificate program, the places teams routinely forget, and third-party dependencies. The boxes you cannot check become your first work queue.
2. Decide what each entry must contain\
   Nine fields per asset, including the two most teams skip: whether the source and the destination can each actually accept post-quantum algorithms today. Without both, you find the gap during migration rather than during planning.
3. Sort what you find
   Three buckets based on capability at both ends, plus a lifetime test that cuts the immediate scope down to something a team can actually start on.
4. Set a crypto agility target
   Not whether you can replace a certificate, but how long before every application in your estate trusts a new chain and you are issuing again. Measured, not estimated.
5. Avoid the two common failure modes
   The team that oversimplifies and the team that is overwhelmed. Both are inventory problems, and they need different first moves.
6. First ninety days
   A dated sequence from naming an owner through to reporting the inventory as a standing metric rather than a completed project.

Who should use this

• Security architects and PKI leads scoping a cryptographic inventory for the first time
• CISOs and IT leaders who need to size a post-quantum program before committing to a timeline or a budget
• GRC and compliance teams tracking M-26-15, NIST IR 8547 and sector equivalents
• Federal and defense industrial base teams working to the 2030 and 2031 migration phases

Inventory is no longer just good practice

OMB Memorandum M-26-15, issued 24 June 2026, directs federal civilian agencies to mitigate as much quantum risk as feasible by 31 December 2030 and lays out a five-phase migration beginning with discovery. It observes that manual approaches to discovery and management of cryptography are often insufficient at federal scale, says the inventory should be created and maintained through automated tools wherever possible, and that the resulting data should populate a central cryptographic bill of materials. Naming the methodologies and automated tools used for that inventory is a required element of every agency migration plan. The memorandum does not apply to national security systems.
‍