A cryptographic inventory is a list of where your systems use encryption and signatures, with the algorithm, the owner and the data protected. CISA lists building one first. You can start in a week with a spreadsheet, a code search and a few questions to vendors.
Why inventory first
CISA says federal agencies must maintain a current inventory of IT vulnerable to quantum decryption, and tells organizations to identify the most vulnerable systems and plan migration. NIST's project page gives the same order: identify where vulnerable algorithms are used, then plan replacements. You cannot replace what you cannot find.
Day 1: decide the columns
Keep it small.
- System or service
- Where crypto is used (TLS, VPN, SSH, code signing, database encryption, tokens, certificates)
- Algorithm and key size, if known
- Data protected and how long it must stay secret
- Owner
- Can the algorithm be changed by configuration?
Days 2 to 4: search your code and the edges
Search repositories for crypto library imports and for algorithm names such as RSA, ECDSA, ECDH and DH. Search configuration for cipher and certificate settings. Record hard-coded choices. These are the expensive ones later.
List certificates and their issuers, VPN and SSH settings, and any signing keys for builds or packages. Dependencies count too: a library you did not write may do the cryptography for you, so your dependency inventory is part of the answer.
Click through it at your own pace, or open it full screen.
Day 5: ask vendors
For each third-party product that terminates or signs something, ask whether and when it will support the NIST standards (ML-KEM, ML-DSA, SLH-DSA). CISA publishes a list of product categories that support or plan to support these algorithms, which helps you frame the question.
Then prioritize
Sort by data lifetime and by how hard the change is. Long-lived data on hard-coded algorithms comes first. See Harvest now, decrypt later: who should worry.
Safeguard's SBOM and dependency scanning can list the libraries in your projects, which feeds the dependency part of this inventory. It does not detect every cryptographic use in your code, so keep the manual search.
What a good result looks like
At the end of the week you should not have a perfect list. You should have a rough one with owners, a count of items that use quantum-vulnerable public-key algorithms, a shortlist of long-lived data flows, and a set of questions sent to vendors. Mark unknowns honestly as unknown rather than guessing.
Then schedule a monthly review of ten minutes. The inventory goes stale fast: new services, new certificates, new libraries. A living list with a named owner is far more useful than a polished one nobody updates.
Quick check
Do I need a special tool to start?
No. A spreadsheet and a code search are enough to begin. Tools help later with scale.
Sources
Last reviewed: 19 October 2026.
