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

01

Scope ledger

Document included, excluded, inaccessible, vendor-controlled, and unknown surfaces.

02

Evidence model

Separate the observed fact, scanner inference, reviewer decision, and organizational policy result.

03

Stable identity

Deduplicate repeated observations while retaining locations and relationships.

04

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. 1

    Design

    Agree on asset taxonomy, evidence requirements, confidence, ownership, and acceptable data handling.

  2. 2

    Discover

    Combine source, dependencies, configuration, containers, endpoints, certificate systems, and vendor inputs.

  3. 3

    Validate

    Sample findings, investigate unknowns, measure coverage, and correct normalization errors.

  4. 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

  1. 01What is the inventory denominator?
  2. 02Can every finding be traced to evidence?
  3. 03How are repeated observations deduplicated?
  4. 04Who resolves ambiguous assets?
  5. 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.
Local-first discovery

Start 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.

Create a workspace