Implementation guide
How to build and maintain a cryptographic inventory
A cryptographic inventory is a living record of cryptographic assets, their locations, relationships, purpose, evidence, and ownership. This guide explains how to build one that can support real change.
Decision brief
- Primary query
- cryptographic inventory
- Best for
- Teams that need reviewable cryptographic evidence, ownership, and continuous migration control.
- Safety boundary
- Evidence supports decisions; it is not proof of implementation safety or compliance.
Start with a scope model, not a scanner. List the software repositories, build pipelines, deployed services, network endpoints, certificates, key-management systems, hardware, vendor products, and data flows that matter. Mark which surfaces can be scanned, which need API or sensor data, which depend on vendor attestations, and which remain unknown. Completeness can only be evaluated against this denominator.
Define an asset model before collecting results. At minimum preserve asset type, normalized name, parameters when observable, purpose, location, software component, evidence, confidence, first and last observation, project, owner, policy status, and dependencies. Never store private keys. Keep raw or redacted evidence accessible enough that another reviewer can reproduce the classification.
Capabilities
What the operating model needs to do
Scope ledger
Document included, excluded, inaccessible, vendor-controlled, and unknown surfaces.
Evidence model
Separate the observed fact, scanner inference, reviewer decision, and organizational policy result.
Stable identity
Deduplicate repeated observations while retaining locations and relationships.
Refresh loop
Run discovery on material change and a scheduled cadence, then review differences.
Workflow
A repeatable path to evidence
Use explicit scope, accountable decisions, and verification gates. Keep unknowns visible so progress is not manufactured by narrowing the denominator.
- 1
Design
Agree on asset taxonomy, evidence requirements, confidence, ownership, and acceptable data handling.
- 2
Discover
Combine source, dependencies, configuration, containers, endpoints, certificate systems, and vendor inputs.
- 3
Validate
Sample findings, investigate unknowns, measure coverage, and correct normalization errors.
- 4
Use
Drive policy, migration, exception review, customer evidence, and CI drift from the inventory.
Expected deliverables
Artifacts the next team can inspect
- Inventory scope and coverage ledger
- Cryptographic asset schema
- Discovery and normalization procedure
- Ownership and exception workflow
- Refresh and quality metrics
Buyer checklist
Questions for a proof of value
- 01What is the inventory denominator?
- 02Can every finding be traced to evidence?
- 03How are repeated observations deduplicated?
- 04Who resolves ambiguous assets?
- 05What operational decisions will the inventory drive?
Limits and cautions
What this page does not promise
- An inventory is never complete without a stated scope.
- Algorithm names alone do not capture implementation or protocol safety.
- Readiness reporting must show unknowns and stale evidence.
Continue evaluating
Related decision pages
CBOM guide
Cryptographic bill of materials: what a CBOM contains and how to use it
Understand CBOM scope, CycloneDX cryptographic assets, evidence, relationships, confidence, validation, diffs, and post-quantum migration use.
Read pagePQC migration guide
Post-quantum cryptography migration: an operating roadmap
A practical roadmap for PQC inventory, prioritization, standards tracking, vendor dependencies, interoperability testing, rollout, verification, and drift control.
Read pageCNSA 2.0 guide
CNSA 2.0 planning: inventory, policy, migration evidence, and limits
Use current NSA sources to plan CNSA 2.0-related inventory and migration work while keeping applicability, implementation validation, and compliance decisions with the proper authority.
Read pageCryptographic inventory software
A cryptographic inventory your engineering teams can keep current
Discover cryptographic assets in source, dependencies, configuration, containers, and authorized TLS endpoints. Preserve evidence, ownership, and change history in one inventory.
Read pageStart with evidence from one representative repository
Run a scoped scan, inspect every result, export the CBOM, and decide whether the evidence is strong enough to support your operating model.