Cryptographic Discovery & CBOM

You cannot migrate what you cannot see. Discovery builds a cryptographic inventory of every algorithm, key, certificate, and protocol in your estate, captured as a CBOM — a Cryptography Bill of Materials — so you can prioritize what to migrate first and prove progress over time.

Why inventory comes first

Most organizations have no authoritative list of where cryptography lives. It is buried in application code, third-party binaries, network protocols, TLS endpoints, certificates, HSMs, and libraries — much of it added years ago by people who have moved on. Without an inventory you cannot estimate Y (migration time) in the risk equation, you cannot prioritize, and you cannot tell when you are done. Discovery is therefore the first and most repeated phase of any migration program.

What to scan

• Source code. Static scans for crypto API calls, hard-coded algorithm names, OIDs, and key sizes.
• Binaries and dependencies. Linked crypto libraries and their versions, including transitive dependencies.
• Network traffic. TLS/SSH scans of live endpoints to discover negotiated versions, cipher suites, and named groups.
• Certificates. Public-key algorithms, key sizes, signature algorithms, validity, and issuing CAs across the PKI.
• HSMs and key stores. Stored keys, their algorithms, and how they are used.
• Libraries and platforms. Crypto providers in OS, JVM, language runtimes, and frameworks.

CBOM: a Bill of Materials for crypto

A CBOM (Cryptography Bill of Materials) extends the CycloneDX SBOM standard with cryptographic asset components — algorithms, keys, certificates, protocols, and the dependencies between them. Using CycloneDX means CBOMs plug into existing supply-chain tooling and can be generated, stored, and queried alongside your SBOMs.

Field names follow the current CycloneDX schema / tool implementations; the example below illustrates structure and is not guaranteed to be accepted as-is by every tool.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "cryptographic-asset",
      "name": "RSA-2048",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "signature",
          "parameterSetIdentifier": "2048",
          "nistQuantumSecurityLevel": 0
        },
        "oid": "1.2.840.113549.1.1.1"
      }
    },
    {
      "type": "cryptographic-asset",
      "name": "tls-endpoint-payments",
      "cryptoProperties": {
        "assetType": "protocol",
        "protocolProperties": {
          "type": "tls",
          "version": "1.3",
          "cipherSuites": [{ "name": "TLS_AES_256_GCM_SHA384" }]
        }
      }
    }
  ]
}

Each asset records its algorithm, parameters, and — crucially — its nistQuantumSecurityLevel, which flags whether it is quantum-vulnerable. RSA and ECC entries surface immediately as migration targets.

Prioritization

Not everything migrates at once. Rank discovered assets by three factors:

Combine these with Mosca's X + Y > Z: assets with large X (long confidentiality requirement) are the first to migrate because harvested ciphertext is already at risk. Signing roots and external-facing endpoints typically top the list. See the Standards Timeline for the deprecation dates that bound Z and your deadlines.

Templates & tooling

Download these to bootstrap a cryptographic inventory and CBOM. All are dependency-free starting points — review the output by hand; they are heuristics, not an authoritative audit.

Standards & references

• CycloneDX CBOM — the Cryptography Bill of Materials format used for inventory.
• CISA Quantum-Readiness factsheet — guidance on building a cryptographic inventory.
• NCCoE SP 1800-38 — discovery tooling and migration practice guide.
• Resources — full standards register