Cryptographic Asset Discovery and Inventory: What Security Leaders Need to Build First

CBOM, CBOM, CBOM: if you haven’t heard the buzzword lately, you’re behind on your cryptographic maturity. Security programs rarely fail because of what they’re actively watching. They fail because of what never made it onto the list in the first place.

Most organizations can produce a half-decent list of their certificate inventories. Almost none can produce a solid cryptographic inventory. That gap stalls migrations and delays remediation.

Organizations are rich in cryptographic data. They’re short of connected cryptographic data. Findings sit scattered across vulnerability scanners, certificate platforms, source code repositories, and cloud consoles, and nothing reconciles them into one accurate picture of what exists, where it lives, and whether it holds up against policy. That gap is measurable: in a 2026 Ponemon Institute study sponsored by Entrust, limited visibility into cryptographic assets was the leading barrier to post-quantum readiness, cited by 41% of respondents, while only 38% of organizations reported actively transitioning to post-quantum cryptography.

This article covers what belongs in a cryptographic asset discovery and inventory program, how to discover it across cloud, CI/CD, and devices, and what tooling supports the work.

A cryptographic inventory isn’t a spreadsheet that someone updates once a quarter. It’s a centralized, continuously updated record of every cryptographic asset an organization actually has, kept current within a constantly growing environment.

A useful inventory has to answer five questions:

• What do we have, specifically? This includes cryptography inherited through acquisitions and embedded in vendor software, the parts most likely to go unaccounted for.
• Where is it, precisely? Knowing cryptography exists “somewhere in the cloud” isn’t actionable. It needs to resolve to a specific host, service, or code path.
• Is it fit for purpose, intentionally? An algorithm acceptable five years ago may already sit below current policy, judged against today’s standard, not the one at deployment.
• How much confidence do we have in it, technologically? A certificate directly observed is a different kind of data point than one inferred from a stale config file. The inventory should reflect that difference.
• What do we remediate first, strategically? Without prioritization tied to business criticality, teams default to fixing what’s easiest, not what’s riskiest to leave alone.

One distinction is worth getting right early: most teams haven’t internalized it, and it changes how this work gets scoped. A Cryptographic Bill of Materials (CBOM) documents what software is capable of, not how it’s configured or what it’s genuinely using at runtime. A complete inventory needs all three layers: capability, configuration, and observed usage. An application can support strong cryptography while running something weaker in production, a gap a CBOM alone won’t catch.

Every one of these efforts rests on the same premise: you can’t migrate, defend, or prove compliance for cryptography you can’t locate. That’s why inventory keeps showing up as step one, not a footnote. Exposure is defined by what you can’t see.

In the US, National Security Memorandum 10 named cryptographic inventory the first step toward quantum-safe federal systems, and OMB M-23-02 turned that into an annual reporting requirement. NIST’s NCCoE runs a project on cryptographic discovery tooling, and its draft IR 8547 lays out the broader migration roadmap.

The pattern isn’t US-only. Singapore’s MAS advisory advises financial institutions to maintain an inventory of their cryptographic assets. The European Commission has recommended a coordinated PQC transition roadmap, with ENISA and ETSI providing technical backing. FS-ISAC has issued PQC guidance specifically for the payment card industry, and PCI DSS 4.0.1 has required a documented inventory of the cipher suites and protocols in use since April 2025, a compliance requirement rather than guidance. That scope is narrower than the full asset inventory described below, but it is binding.

None of this waits on quantum computers. The CA/Browser Forum is separately compressing public TLS certificate validity on a staged schedule, to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029, a set of deadlines, unrelated to quantum risk, driven by operational reality.

Most inventories fail the same way: they cover certificates thoroughly and stop there. A complete inventory spans three categories (operational cryptography, software cryptography, and network cryptography), and within those categories, six specific asset types need to show up.

• Certificates: Public, private, self-signed, end-entity, root CAs, and trust stores, the category most inventories cover and mistake for the whole picture. As post-quantum migration approaches, knowing exactly which certificates you hold becomes the starting point for everything else.
• Keys and key stores: Private and public keys, symmetric secrets, and tokens, held in HSMs, KMSs, and vaults.
• Algorithms, protocols, parameters, and configurations: Key sizes, cipher suites, key exchange methods, MACs, and how systems are configured to use them, not just what they support.
• Cryptographic libraries and APIs: Including version numbers and known vulnerability status, since an outdated library can undermine cryptography that’s otherwise correctly configured.
• Certificate authorities: Internal and external, and how each is governed.
• Trust anchors and roots of trust: Including hardware-resident anchors that can’t be modified once deployed.

The asset classes that get skipped are rarely random. Algorithms, libraries, and trust anchors are harder to discover than certificates. They don’t expire on a visible schedule, so nobody gets an alert when they go stale. That’s why migrations stall: an organization can feel confident about its certificate posture while remaining blind to the layer underneath it, where a post-quantum migration actually has to happen.

Where cryptography actually gets found looks different depending on which layer of the estate you’re searching, and each of the three environments below breaks in its own particular way.

Cloud

Cloud environments generate cryptographic sprawl faster than most teams can track. Compute instances, databases, API gateways, and container orchestration all carry their own certificates and keys, and load balancers and service meshes maintain certificate stores outside central visibility. Each asset needs an owner and a lifecycle status.

What makes cloud discovery different is speed. Instances spin up and tear down in minutes, and a snapshot taken this week can be wrong by next week. Discovery here has to be automated and continuous. A quarterly scan doesn’t just miss things. It is structurally incapable of keeping pace with an estate that changes faster than any manual cycle can follow. If you’ve ever ordered a food delivery, you understand how critical it is to act on freshly delivered food instead of letting it sit at your front door for days.

CI/CD

CI/CD is the most common blind spot in the inventory. Cryptographic material enters the estate here before it reaches production, so an unscanned pipeline is actively adding assets nobody has recorded. Discovery has to reach into the pipeline itself, flagging hardcoded, reused, stale, or already revoked keys. Compiled binaries deserve particular attention, since a library baked into an artifact will not surface in any network-level scan.

CI/CD is also a common exit point for secrets, not just a blind spot. A hardcoded secret or misconfigured control here maps directly onto STRIDE threat categories, tampering, information disclosure, elevation of privilege, not just a compliance gap.

The governance point matters as much as the technical one: inventory belongs inside the development lifecycle, not bolted on after deployment. By the time something ships, a hardcoded key is already copied into however many downstream builds depend on it.

Devices, Firmware, and Long-Lived Assets

Device identities and embedded certificates, along with long-lived firmware signatures, are the hardest category to discover and the highest priority to get right. Dependency mapping matters especially for machine identities across IoT, OT, and edge devices, where one credential can be inherited fleet-wide.

Field-deployed devices routinely outlast the algorithms protecting them, which is what makes harvest-now-decrypt-later a real concern: data encrypted today can be captured now and decrypted later once the algorithm is broken. That’s not a reason for alarm. It is a reason to prioritize these assets before the rest of the estate.

Finding everything is only step one. Getting from discovery to something usable takes three moves.

• Centralize. Multiple tools feeding separate dashboards isn’t an inventory, it’s partial views. Even federated setups need one reconciling layer above them.
• Enrich with context. A raw inventory shows an asset exists, not whether it matters. Business criticality, ownership, and compliance make it prioritizable, the difference between 40,000 certificates and knowing which 200 matter.
• Maintain continuously. Automated re-discovery, CVE monitoring, and integration with CLM workflows keep the inventory current, not stale the moment scans stop.

None of this works without a named owner: accountability sits with one executive, operational responsibility spreads across security, platform, infrastructure, and DevSecOps, and a RACI model keeps it from becoming no one’s.

A few patterns compound into a certificate list instead of a real inventory.

• Relying on spreadsheets and manual tracking. This works at small scale and breaks past what one person can reconcile, sooner than most expect.
• Inventorying certificates while ignoring keys, algorithms, and libraries. A certificate-only inventory feels complete because it’s the easiest layer to see. It isn’t complete. It is only the visible part.
• Treating discovery as a project with an end date. Discovery that stops once built starts going stale the day after.
• Leaving cloud, CI/CD, or device cryptography out of scope. Each gap undermines confidence in the whole record, since there’s no way to know what else might be missing alongside it.

The market has two approaches: one starts from discovery and analytics, sitting above existing tooling. The other starts from cryptographic infrastructure an organization already operates (PKI, HSMs, key management) and extends it into a unified control plane. The right fit depends on where an organization’s cryptographic center of gravity sits.

Keyfactor AgileSec

Keyfactor positions this as cryptographic posture management: a layer above existing scanners rather than another one alongside them, coming into Keyfactor through its May 2025 acquisition of InfoSec Global and CipherInsights, combining AgileSec Analytics and Agility with CipherInsights’ network monitoring.

Keyfactor describes four capabilities working in combination. It maintains a system of record that stays current across certificates, keys, algorithms, and dependencies. It layers in cryptographic intelligence, scoring risk by business context and flagging quantum-vulnerable algorithms. It integrates operationally, landing inside existing ITSM and remediation workflows, and carries an organization through PQC migration and whatever follows.

Underneath these four capabilities, discovery itself runs on a combination of Command’s orchestration layer and AgileSec Analytics’ sensors, reaching across endpoints, networks, cloud workloads, load balancers, HSMs, and CI/CD binary objects.

Endpoints get scanned through Tanium and CrowdStrike Falcon sensors, with findings flowing into ServiceNow directly, and the integration list extends to cloud platforms, network tooling, HSM vendors, and code repositories. The payoff is a vulnerability map grounded in what’s observed.

Entrust Cryptographic Security Platform

Entrust’s platform unifies PKI, HSMs, and the lifecycle management of keys, secrets, and certificates under one control plane, for organizations already running Entrust infrastructure. Key and secrets management spans vaults, applications, and cloud services, plus agentless file-level encryption for unstructured data. Compliance Manager is the inventory-bearing piece, giving centralized visibility and policy control from a single dashboard.

Root of trust uses nShield 5 hardware, certified to FIPS 140-3 Level 3, on premises or as a service, with HSM Manager handling centralized control across distributed estates, built to sit alongside existing tools. What stands out architecturally is custody: because the inventory sits on top of infrastructure the organization already operates, key material stays under hardware control that can be evidenced directly to an auditor, which matters wherever policy or regulation dictates where keys are permitted to live.

Two adjacent solutions worth noting: Palo Alto Networks’ Quantum-Safe Security integrates with NGTS and its network security stack. AppViewX’s Quantum Trust Hub works the same way inside AVX ONE CLM, an add-on module rather than a standalone product.

 
Most enterprises run more than one of these. Integration matters more than selection.

This gap isn’t a data problem. It’s a connection problem: certificates in one system, keys in another, algorithms nobody’s mapped. Closing it determines whether an organization can move quickly: remediating a known weakness, responding to an audit, replacing a weakening algorithm, or planning a PQC migration on its own timeline instead of scrambling for one.

An inventory that just documents what exists doesn’t do that. Its value shows up once it becomes the surface an organization operates from, current and trusted enough to decide against.

For organizations ready to see where that surface currently stands, a Quantum Readiness Assessment is the place to start.