How to Build a Cryptographic Asset Register for Your Organisation

The most common reason PQC migration programmes stall at the planning phase is not budget, executive buy-in, or algorithm selection. It is the absence of a reliable answer to a simple question: what cryptographic assets do we actually have? Without that answer, no migration can be sequenced. You cannot prioritise what you have not enumerated, and you cannot assign migration risk to systems you cannot see.

A cryptographic asset register, formally structured as a Cryptographic Bill of Materials (CBOM), solves that problem. This article describes how to build one, structured as a four-phase process from initial discovery through to a maintained programme tracking document. Before you start, the framing article on what a cryptographic inventory covers is useful context. The data classification decisions that determine migration priority are informed by the HNDL risk assessment framework described in which data is most at risk from harvest-now-decrypt-later attacks.

What the Register Is and Why It Blocks Migration Without It

A CBOM is a structured inventory of every cryptographic asset in an organisation's IT and OT environment: the algorithms in use, their key lengths, the protocols and library versions implementing them, the systems those protocols protect, and the confidentiality lifetime of the data at stake. The concept is derived directly from the Software Bill of Materials (SBOM) model. Where an SBOM enumerates software components and their versions, a CBOM enumerates cryptographic components (algorithms, key sizes, certificate chains, protocol versions) and their deployment contexts.

CycloneDX has formalised a CBOM schema that extends its SBOM format with cryptographic asset object types: AlgorithmComponent, CertificateComponent, ProtocolComponent. This schema is the current open standard for machine-readable CBOM output and should be the target format for any tooling you adopt. IBM has also published an open-source CBOM schema. Using a standardised format means the register can be consumed by downstream tooling, shared with auditors and regulators, and maintained across staff changes without institutional knowledge loss.

CISA's post-quantum migration strategy directs US federal agencies to use tooling that automates cryptographic characteristic collection and to report their crypto inventory annually. That annual maintenance cycle is the operational standard: a CBOM is not a one-time discovery exercise but a living document that requires regular updates as the environment changes.

Phase 1: Discovery. Finding Every Cryptographic Asset

Discovery has four distinct surfaces, each requiring different tooling and different access patterns. Attempting to cover all four with a single tool will leave gaps.

Network traffic analysis is usually the first surface and the most productive for most environments. TLS handshake inspection reveals cipher suites, key exchange methods, and certificate details negotiated across the network in real time. Tools such as Venafi TLS Protect, Keyfactor Command, and AppViewX can scan and enumerate TLS endpoints across an estate at scale. Passive traffic capture via network taps or SPAN ports identifies cipher suite usage without disrupting live services, which matters for production environments where active scanning could cause stability issues.

Code and dependency scanning reaches assets that network analysis cannot see: local key generation, in-memory encryption operations, local signing that never produces a network event. Applications contain cryptographic API calls embedded in source code and compiled binaries: calls to OpenSSL functions, Java Security library, .NET cryptography namespaces. Static analysis tools that identify these calls produce a list of application-layer cryptographic dependencies that supplements the network view. IBM Guardium Data Encryption and comparable tools can scan codebases and databases for cryptographic implementations. The network scan tells you what is negotiated; the code scan tells you what is generated and used internally.

Certificate inventory leverages the fact that X.509 certificates carry explicit algorithm metadata: signature algorithm, public key algorithm, key size. A certificate management platform with ACME or SCEP integration can enumerate all certificates issued by internal certificate authorities. External internet-facing certificates can be enumerated through external scanning. The output is a list of certificates with RSA or ECDSA keys that are migration targets, organised by expiry date, issuer, and the system on which they are deployed.

HSM and key management platform export typically provides the most accurate view of the keys that matter most. Hardware security modules and key management systems, whether AWS KMS, Azure Key Vault, Thales CipherTrust, or Venafi, hold explicit key inventories with algorithm and key length metadata. Exporting this data directly from the platform is more reliable than inferring it from network observations, because the platform knows what it was asked to generate. The certificates visible at the network layer may be signed by keys whose material only exists in an HSM; the HSM inventory is the definitive source for those.

Automated discovery tools reduce enumeration effort but do not eliminate the need for manual review. Embedded systems, legacy applications, custom-built cryptographic implementations, and OT protocol cryptography (Modbus TCP, DNP3-SA, IEC 61850) are frequently invisible to network scanners. Manual review of architecture diagrams, system documentation, and structured interviews with application and infrastructure owners is required to catch these edge cases. NIST NCCoE SP 1800-38B, the cryptographic discovery volume of the migration guide series, remains the canonical methodology reference for this phase, noting it is currently a preliminary draft.

Phase 2: Classification. Assigning Risk Scores and Confidentiality Lifetimes

Discovery produces a list. Classification turns that list into a prioritised migration plan by assigning two dimensions to every asset: algorithm risk and data confidentiality lifetime.

Algorithm risk is largely determined by NIST IR 8547 (November 2024). RSA and elliptic curve algorithms (ECDH, ECDSA, DH, DSA) are deprecated for new systems from 2030 and must be retired from all systems by 2035. These are unambiguously high-risk. Symmetric algorithms at AES-128 and above are quantum-resistant at their current key sizes: Grover's algorithm halves the effective key space, so AES-128 offers approximately 64-bit post-quantum security, which is in a concerning range for very high-value long-term data; AES-256 remains sufficient. Hash functions at SHA-256 and above retain adequate post-quantum security. The primary migration target is asymmetric public-key cryptography.

Confidentiality lifetime classification determines which assets are in the harvest-now-decrypt-later window. The Mosca inequality provides the framework: if the migration lead time plus the expected CRQC timeline is less than the period over which the data must remain confidential, migration is urgent. Data with long mandatory retention periods encrypted with RSA or ECDH key exchange is the intersection that generates the highest migration priority. Useful lifetime categories for classification purposes include: personal health and genomic records (multi-decade or lifetime retention); classified government communications (25 to 50 year classification periods); financial transaction records (5 to 10 years under MiFID II Article 25(2) and UK FCA COBS 9A.4.1R); legal privileged communications (duration of matter plus archival periods); and OT/ICS operational data (system lifetime, potentially 20 to 30 years). Any asset in the longest-lifetime categories should be treated as high priority regardless of other factors.

Phase 3: Ownership. Making the Register Actionable

A register without ownership is an audit document. A register with ownership is a migration tool. Every asset in the register needs an identified owner: the system team, application team, or platform team accountable for executing the migration for that asset.

Ownership assignment requires mapping each cryptographic asset to its system in the CMDB, then mapping the system to its responsible team. In practice, this step frequently reveals gaps in the CMDB itself: systems that are in the cryptographic inventory but not in the CMDB, or CMDB records that do not reflect the current state of the system. Those gaps need to be resolved before migration planning can proceed, because a system without a CMDB record does not have an owner, a change management process, or a patch window that can be used for migration activity.

Multi-owner assets require additional structure. A root CA, a shared HSM cluster, or a network-wide IKEv2 PKI serves multiple systems and may be owned by multiple teams. These assets need a designated lead owner and a stakeholder register that identifies who must be consulted for migration decisions. They cannot be migrated unilaterally by individual consuming teams. The migration planning for shared assets must be coordinated, which means it needs to start earlier and requires more governance overhead than per-system migrations.

Phase 4: Migration Tracking. The Register as a Programme Tool

Once discovery, classification, and ownership are complete, the register transitions from a snapshot inventory to an active programme management artefact. Each asset entry should carry: current algorithm, target algorithm post-migration, assigned migration phase (Phase 1 priority, Phase 2, Phase 3), migration status (not started, in planning, in execution, complete), and last verified date. These fields turn the register into the source of truth for programme status reporting and dependency tracking.

Crypto-agility is the mitigation against future algorithm deprecation beyond the current migration cycle. A system built with crypto-agility separates algorithm selection from business logic: the algorithm is a configuration parameter, not a hardcoded constant. When a future deprecation event requires another algorithm change, a crypto-agile system can be updated by reconfiguration rather than by re-architecture. The register should flag systems that lack crypto-agility as high-cost migration targets where refactoring may be required before algorithm substitution is possible. These are the systems that need the most lead time.

Version control and annual maintenance are minimum requirements for a functional register. Algorithm deprecation schedules, new vulnerabilities in candidate algorithms, and changes to regulatory guidance mean that classification decisions taken in 2025 may need revision by 2027. The PKI Consortium's PQC Capabilities Matrix tracks vendor capability changes and is a useful external reference for the annual maintenance cycle; connecting the register update schedule to the PQCCM review reduces manual research effort.

EU NIS2 Article 21(2)(j) supply chain security obligations (applicable to EU essential entities) and DORA Art 9(2) ICT risk management requirements both benefit from a demonstrable, auditable cryptographic asset record. The register is not only a migration planning tool; it is the evidence of systematic cryptographic risk management that regulators and auditors increasingly expect to see, not as a policy statement, but as a maintained operational document.

What a Complete Register Entry Looks Like

A complete register entry for a single asset contains the following fields:

  • Asset identifier: a unique reference, linked to the CMDB record
  • System name and CMDB reference
  • Cryptographic function: key exchange, signing, encryption at rest, MAC, or hashing
  • Current algorithm and key size: for example, RSA-2048 signing, ECDH P-256 key exchange
  • Protocol context: TLS 1.3 cipher suite, X.509 certificate, IKEv2 SA, or equivalent
  • Data classification: confidentiality lifetime category
  • Migration priority tier: Phase 1, 2, or 3
  • Assigned owner: team name and lead contact
  • Target algorithm post-migration
  • Migration status
  • Last verified date

The CycloneDX CBOM schema maps closely to these fields. Starting from the schema rather than a blank spreadsheet ensures the register is machine-readable and compatible with tooling that consumes CBOM data. The NIST NCCoE SP 1800-38B methodology describes the field requirements in greater detail; those requirements should be verified against the final published volumes when NIST completes the series, as preliminary draft field definitions may change.

An organisation with a well-maintained, version-controlled CBOM has a significant operational advantage over one without: faster regulatory disclosure, more credible supply chain risk conversations with customers and auditors, and a migration programme that can be updated when circumstances change rather than started from scratch. The register is the foundation. The migration follows from it, not the other way around.

Quantum technologies are evolving quickly and new developments emerge regularly. This page was last updated on 18/05/2026. For the most current information, we recommend contacting us directly.