How to Build a Cryptographic Asset Inventory Across Cloud, CI/CD, and Devices

Most security teams can tell you what their firewall rules look like. Far fewer can tell you exactly how many certificates are running in their environment right now, which ones expire in the next 30 days, whether any of their CI/CD pipelines are shipping a hardcoded private key to production, or where their KMS keys, SSH keys, JWT signing keys, and API authentication secrets actually live.

That gap between “we use cryptography everywhere” and “we know where every cryptographic asset lives” is what a cryptographic inventory is designed to close. The urgency here is real, and it is coming from multiple directions at once. Without a complete and current inventory, organizations have no baseline to act from: no way to know which certificates are expiring, which algorithms are deployed where, or which assets will be affected when a CA is compromised or a standard is deprecated.

Beyond operational risk, the compliance clock is also running. CA/B Forum Ballot SC-081v3, passed in April 2025, has announced a reduction in maximum public TLS certificate lifespans from 398 days to 47 days by March 2029, with phased steps of 200 days effective March 15, 2026, and 100 days effective March 15, 2027.

And on the quantum side, NIST IR 8547, currently an Initial Public Draft (November 2024) and subject to revision, deprecates 112-bit security algorithms (e.g., RSA-2048, ECC P-224) after 2030 and disallows all RSA- and ECC-algorithms, including larger key sizes such as RSA-3072 and ECC P-256, after 2035. A migration cannot begin without knowing where those algorithms are deployed. While certificate lifetimes are shrinking due to operational security concerns, quantum readiness introduces a much longer-term cryptographic migration challenge.

This blog walks through how to build a cryptographic asset inventory that actually holds up across the three environments where most organizations have the biggest blind spots: cloud infrastructure, CI/CD pipelines, and connected devices. In all three environments, cryptographic assets are deployed rapidly, frequently outside centralized security oversight, and often remain invisible to traditional network-based discovery methods. We will cover what to discover, how to discover it, and how to keep the data accurate enough to act on.

Defining the Cryptographic Inventory

A cryptographic inventory is a structured, continuously maintained record of every cryptographic asset your organization uses across its entire infrastructure. Think of it as a living map: not just what cryptographic tools you have deployed today, but where they live, what they protect, who owns them, how they are configured, what depends on them, where they are in their lifecycle, and whether they are still fit for purpose.

As NIST PQC migration guidance, NSA CNSA 2.0, and ETSI crypto-agility recommendations all note, many current systems lack crypto-agility because they were not designed for rapid cryptographic upgrades, and organizations often do not know where all their cryptography is used. That blind spot is exactly what a proper inventory addresses.

A good cryptographic inventory answers four questions for every asset it contains:

• What is it, and where does it live? The asset type, the algorithm and key parameters it uses, its cryptographic purpose (such as TLS termination, data encryption at rest or in transit, code-signing), and key usage (encryption, signing, authentication), the trust chain it participates in, and the specific system, service, or device it is bound to.
• Who owns it? Accountability without an owner is just a list of problems with nobody assigned to fix them. Every asset needs a responsible team.
• What depends on it? Which business services or systems rely on this asset, and how are they connected to it? A certificate may sit in a chain where multiple services share a dependency on the same intermediate CA. Understanding those relationships is what turns a finding from “weak certificate” into “weak certificate whose failure cascades across dependent systems.”
• Is it still acceptable? Does it meet current policy requirements for key length, algorithm, and validity? Is it expiring soon? Does it match what should be there according to the configuration policy?

What Does a Complete Inventory Cover?

The scope is wider than most teams assume. Many start with TLS certificates and stop there. But certificates are just one layer. A complete inventory covers the following assets.

Certificates are the most visible layer: TLS server certificates, client certificates used in mTLS, code-signing certificates, email certificates, OCSP responder certificates, CRL signing certificates, device identity certificates, and the trust stores that determine which root CAs your systems accept. This includes self-signed certificates, which are often forgotten and frequently cause problems in internal systems.

Cryptographic keys and key material sit underneath certificates. Private keys associated with certificates need to be tracked for ownership, storage location, access controls, and rotation status. Beyond certificate keys, symmetric keys used for data encryption at rest, API signing keys, SSH keys, database encryption keys, token-signing keys, cloud KMS keys, and secrets stored in vaults or Hardware Security Modules (HSMs) all belong in the inventory. Key storage location matters too: a key sitting in a software keystore is a different risk posture than one in a FIPS 140-3 Level 3 hardware security module.

Certificate authorities themselves, both internal CAs you operate and external CAs you trust, are cryptographic assets. The key lengths, signing algorithms, validity periods, and CRL/OCSP configuration of your Issuing CAs determine the security baseline for every certificate they issue. The full CA hierarchy needs to be captured: Root CAs, Intermediate CAs, and any Subordinate or Issuing CAs sitting below them. Each level of the chain has its own key material, validity period, signing algorithm, and revocation configuration.

Trust anchors and hardware roots of trust round out the picture. These include TPMs (used in servers and endpoints), secure elements (common in IoT and mobile devices), secure enclaves, secure boot keys that control what firmware and OS images a device is permitted to load, hardware-backed attestation mechanisms that allow devices to prove their identity and integrity to remote systems, and hardware roots embedded in devices. Some of these cannot be updated after manufacturing, which creates specific implications for post-quantum migration planning.

Algorithms, cipher suites, and protocol configurations are the layer most organizations miss entirely. Knowing that a system uses TLS is not enough. Which version is it running? Which cipher suites are actually enabled? Which key exchange mechanisms does it use? Whether a system is configured to accept TLS 1.0 as a fallback or uses 1024-bit RSA is not visible in a single high-level certificate scan. This data comes from a thorough configuration analysis that covers signature algorithms (RSA, ECDSA, EdDSA), key exchange algorithms (ECDH, DHE, and their quantum-safe equivalents), and hash algorithms (SHA-1, SHA-256, SHA-384) in use across each system.

Cryptographic libraries need to be tracked by version and by whether they have known vulnerabilities. OpenSSL, Bouncy Castle, wolfSSL, Botan, and Microsoft CNG form the foundation of cryptographic implementations across applications and services. Outdated or unsupported versions of any of these introduce security risks even when strong algorithms are configured. Because each library has its own vulnerability history, feature set, and support lifecycle, the inventory should record which cryptographic libraries and versions are used across applications and services.

A Cryptographic Bill of Materials (CBOM) is a structured record of the cryptography present in a software system, firmware image, or device. It lists the algorithms, key sizes, cryptographic libraries, certificates, and protocols in use. A CBOM does not discover assets on its own. It captures what is present in a software artifact based on build-time or static analysis. That is different from runtime discovery, which tracks what is actually running in your environment. You need both: the CBOM tells you what was built in; runtime discovery tells you what is live.

Why Inventory Comes Before Everything Else

Inventory is not a preparatory task that happens before the real security work begins. It is the prerequisite for every downstream action.

You cannot rotate a certificate you do not know exists. You cannot respond to an algorithm deprecation if you do not know which systems are using that algorithm. You cannot scope a PQC migration without a map of RSA and ECC deployments. And during a 47-day certificate renewal period, you cannot sustain manual renewal operations across thousands of certificates without an accurate, live inventory to drive automation.

To make this concrete: when a CA compromise occurs, the first question is always, “Which certificates did we issue through that CA?” Organizations without a current inventory spend the first 24 hours answering that question instead of revoking and reissuing. When OpenSSL ships a critical vulnerability, the teams that respond fastest are the ones who can immediately query which applications are running the affected version. When SHA-1 was deprecated, the organizations that were caught flat-footed were those that had no systematic way to identify every SHA-1 certificate in their environment. In each case, the inventory was not a nice-to-have; it was the difference between a measured response and a scramble.

This is also why static spreadsheets fail. An environment that is constantly changing through new deployments, configuration updates, cloud provisioning, and software releases will outpace any manually maintained list within weeks. The inventory has to be continuous and automated to remain useful.

How to Build Your Cryptographic Asset Inventory

Knowing what to include in a cryptographic inventory is one thing. Actually, building one that holds up across a real enterprise environment is another matter entirely. Most organizations have cryptographic assets spread across cloud workloads, development pipelines, and physical devices, often with no single team with visibility into all three. The steps below walk through how to approach discovery in each environment, how to bring that data together into something actionable, and how to prevent it from going stale.

Step 1: Establishing Cryptographic Visibility Across Cloud Infrastructure

Cloud infrastructure is where cryptographic sprawl is fastest. Certificates and keys are issued and consumed by compute instances, managed databases, API gateways, container platforms, load balancers, service meshes, and cloud-native CA services.

What to discover:

• Certificates and keys across IaaS and PaaS resources, including those managed by cloud-native CA services.
• Cloud KMS resources, including AWS KMS keys, Azure Key Vault secrets and certificates, Google Cloud KMS key rings, and managed HSMs, which are often treated as opaque infrastructure rather than cryptographic assets requiring inventory.
• Cryptographic configuration on load balancers, gateways, and service meshes, which frequently maintain independent certificate stores.
• Certificates issued directly through cloud provider certificate services that may not route through your internal PKI.

The specific challenge in cloud environments is ownership and scope. A certificate provisioned by a developer through a cloud API may not appear in any central record, and a KMS key used for data encryption may have no associated metadata linking it to the application or team that owns it. Automated, continuous discovery across both certificates and cryptographic services is the only practical approach to keeping pace with the rate of change in cloud-native infrastructure. Point-in-time scans go stale quickly. The goal is a live feed, not a snapshot.

Step 2: Extending Discovery into the Software Delivery Pipeline

CI/CD pipelines are among the most consistent blind spots in cryptographic inventories and among the highest risk. They are also a primary vector for software supply chain attacks. Compromised build pipelines have been used to inject malicious code into signed artifacts that downstream consumers have implicitly trusted. That makes the cryptographic material in your build infrastructure both an inventory gap and an active attack surface.

The cryptographic material baked into applications during the build process does not show up in network-level certificate scans, making pipeline discovery a distinct discipline from infrastructure scanning.

What to look for:

• Certificates and keys embedded in build configurations, Dockerfiles, and infrastructure-as-code templates.
• Cryptographic libraries included in source code or compiled into application binaries, with version and CVE status.
• Hardcoded or reused keys and secrets that have been committed to version control, including historical commits that may no longer be present in the current branch but remain accessible through repository history.
• Code-signing certificates and keys used to sign build artifacts, including integrations with build signing services like Sigstore and Cosign.
• Artifact signing workflows and the keys that back them.
• SBOM and CBOM generation pipelines, which should themselves be treated as cryptographic infrastructure.

The CBOM concept is useful here. Generating a CBOM for each application version provides a structured record of which cryptographic capabilities are built in, enabling organizations to track cryptographic dependencies as applications evolve. But the CBOM must be paired with runtime discovery to close the gap between what the binary supports and what the deployed instance actually does.

Embedding cryptographic inventory practices into the CI/CD pipeline itself, rather than treating them as a post-deployment concern, is the practical approach. Secrets scanning at the pre-commit and pre-merge stages catches hardcoded material before it reaches production. Library scanning at build time flags outdated or vulnerable cryptographic dependencies before they ship.

Step 3: Addressing Cryptographic Exposure in Devices and Firmware

Devices create a category of cryptographic risk that does not exist in cloud or pipeline environments: the assets are hard to reach, hard to update, and often run for years or decades after initial deployment.

Long-lived devices accumulate cryptographic debt in ways that are easy to miss. A firmware image shipped with a specific version of a cryptographic library does not update automatically. A device identity certificate issued at the time of manufacture may have a 10-year validity period and no automated renewal mechanism. The cryptographic decisions made when that device was designed may no longer reflect current standards, and for devices already in the field, remediation may mean a full firmware update or physical replacement.

What to inventory:

• Device identity certificates and the roots of trust that anchor them.
• Secure Boot keys and firmware signing certificates, which are frequently more operationally critical than TLS certificates on the same device. A compromised firmware signing key means compromised devices at scale.
• Device attestation keys used in remote attestation workflows.
• Private keys stored in dedicated hardware, such as TPMs and secure elements.
• Long-lived code-signing keys used to authenticate firmware and software updates.
• Cryptographic libraries and algorithm configurations in firmware images.

This category deserves particular attention in a PQC context because of the Harvest Now, Decrypt Later (HNDL) threat. Under this threat model, adversaries may collect and store encrypted traffic today with the expectation that future advances in quantum computing could enable decryption of data protected by currently deployed public-key cryptographic algorithms.

Systems and devices that are expected to remain in service for many years are of particular concern because they may continue relying on quantum-vulnerable cryptographic algorithms long after deployment. Identifying such assets with long operational lifespans and long-term confidentiality requirements is therefore essential for assessing future cryptographic exposure and prioritizing PQC migration efforts.

Step 4: Consolidating and Normalizing Inventory Data

Discovery across three environments produces data in three formats from three toolsets. Raw discovery data is not an inventory. It is the input to one. The normalization step is where scattered records become something you can actually query, report from, and act on.

Normalization matters because inconsistent data creates blind spots even after discovery is complete. For example, one source may record an algorithm as “RSA-2048” while another records “RSA 2048” or simply “2048.” Without normalization, these may be treated as distinct assets. Similarly, if certificate fingerprints are not consistently captured, the same certificate discovered through multiple scan paths may appear multiple times in the inventory.

Inconsistent naming conventions and metadata across cloud providers and management platforms can also hinder ownership attribution and asset correlation. Concretely, normalization means standardizing RSA key sizes to a consistent representation across sources, using certificate fingerprints (SHA-256 thumbprints) as the canonical identifier for deduplication, and removing duplicate asset records.

A few things that make centralization work in practice:

• Consistent metadata: Every asset record should capture at minimum the asset type, algorithm, and parameters, expiration date, owning team, environment, and associated compliance scope. Without ownership data, findings cannot be routed to the right people for remediation.
• Integration with existing tooling: The inventory should pull from and push to Certificate Lifecycle Management (CLM) platforms, Configuration Management Database (CMDB) records, and security operations workflows. An inventory that exists in isolation from the tools teams actually use will not stay current.
• Single source of truth: In environments where local regulations or architectures require federated storage, there still needs to be a unified view at the top level. A federated approach that produces no consolidated visibility defeats the purpose.

Step 5: Enriching the Inventory with Risk and Compliance Context

A list of assets is not an inventory in the actionable sense. The inventory becomes a decision-making tool when risk context is attached to each asset. Risk enrichment falls across three dimensions. Each dimension surfaces different types of problems and feeds different remediation workflows.

Security risk flags assets with direct technical exposure: certificates approaching expiration with no automation in place, self-signed certificates in production contexts where a CA-issued certificate is required, algorithms that are deprecated or insufficiently keyed for current standards, libraries with known CVEs, weak key generation practices, unauthorized trust anchors, missing hardware protection for keys that should be in HSMs or TPMs, and orphaned keys with no active application dependency.

Compliance risk flags deviations from regulatory or policy requirements: algorithms scheduled for disallowance under NIST IR 8547; certificates or keys outside approved key management policies; and assets in scope for specific frameworks (PCI DSS, FedRAMP, etc.) that do not meet those requirements.

Operational risk flags assets that are likely to cause incidents: certificates expiring within 30 days, assets with no identified owner, and systems for which renewal or rotation lacks an automated path.

Prioritization should be driven by business criticality and data sensitivity, not just by technical severity. A weak algorithm on a development server is a different risk profile than the same algorithm protecting a production payment system. The inventory should support that distinction.

Step 6: Sustaining Inventory Accuracy as Infrastructure Evolves

An inventory that was accurate six months ago is not an inventory. It is a historical record. Cloud environments, CI/CD pipelines, and device fleets change continuously, and the inventory has to keep pace.

Practically, this means:

• Event-driven discovery, not just scheduled scans. Cloud provisioning events, KMS key creation notifications, Git hooks on repository changes, and certificate lifecycle events should all trigger inventory updates. New assets get picked up as they are provisioned, not at the next scheduled scan.
• Integration with certificate lifecycle events: When a certificate is renewed, revoked, or replaced, the inventory record should update automatically.
• Monitoring for external changes that affect existing assets: new CVEs against libraries in inventory, algorithm guidance updates, CA distrust events, and changes to compliance requirements.
• Regular review as part of security operations, not just as a compliance exercise. The inventory is most valuable when teams are consulting it routinely, not only when an audit is due.

The health of the inventory itself should be measurable. Useful KPIs include percentage of discovered assets with confirmed owners, percentage of the environment covered by active discovery, count of certificates expiring within 30, 60, or 90 days, and percentage of assets using deprecated algorithms. These give you a concrete signal of whether the inventory is improving or drifting.

Common Mistakes to Avoid

Getting through all six steps does not mean the work is done. It means you have the foundation in place. The value compounds over time: the longer the inventory runs, the more accurate the ownership data gets, the more reliably automation can act on it, and the better positioned the organization is when the next algorithm deprecation, CA distrust event, or compliance deadline arrives. That said, even well-intentioned inventory efforts fall into predictable traps. Here are the most common mistakes to avoid as you build and maintain yours.

1. Focusing only on certificates. Certificates are the most visible layer, but keys, algorithms, cryptographic libraries, cloud KMS resources, and other assets carry real risk too. An inventory that stops at certificates is giving you a partial picture.
2. Missing dependency mapping. Knowing a certificate exists is not enough; you need to know which applications and services depend on it. Without dependency data, you cannot assess the blast radius of a failure or coordinate remediation across the teams that need to act.
3. Treating all findings as equally urgent. Without asset criticality data, every flagged item looks the same. That creates alert fatigue and means high-impact issues are addressed in no particular order. Prioritization requires a business criticality context.
4. Excluding cloud environments, CI/CD pipelines, or endpoint devices. These are now core infrastructure. Gaps here are not edge cases; they are where the most significant unmanaged assets tend to live.
5. Running discovery as a one-time or periodic exercise. Infrastructure does not stop changing between scans. Continuous discovery is the only approach that keeps pace.
6. Relying on manual tracking. Spreadsheets go stale. In dynamic environments, they go stale fast.
7. Maintaining records without ownership data. Identifying an asset is only the first step. Remediation requires a responsible team for every asset.
8. Managing CBOM data separately from runtime inventory. CBOM tells you what cryptographic capabilities are built into an application. Runtime inventory tells you what is actually being used in production. You need both.

These mistakes share a common thread: they treat the inventory as a one-time deliverable rather than a living operational system. Getting the foundation right from the start is what separates an inventory that stays useful from one that goes stale within months.

A Practical Starting Point

If your organization is starting from zero on cryptographic inventory, the practical first step is scoping. Define the boundaries: which environments are in scope for initial discovery, which teams need to be involved, and what a complete inventory looks like for phase one.

A phased approach makes this tractable:

• Phase 1 – Critical Services: Start with the assets where the operational risk of expiry or misconfiguration is highest. Internet-facing HTTPS endpoints, VPN gateways, and API gateways are usually the right starting point; they are the places a cryptographic failure causes an immediate incident. Internal services used by the authentication infrastructure (LDAP over TLS, RADIUS, AD CS OCSP/CRL services) and any service that participates in zero-trust network access policies belong here, too.
• Phase 2 – CI/CD: Get CBOM generation into your build pipelines and secrets scanning into your pre-commit and PR workflows. This closes the software supply chain visibility gap before you expand outward.
• Phase 3 – Cloud: Extend to cloud environments using API-based discovery, covering both certificate stores and KMS resources across providers.
• Phase 4 – Devices: Device and OT environments can follow using passive network monitoring and firmware analysis, prioritized by operational lifespan and data sensitivity.

The inventory is not a project with a completion date. It is an operational infrastructure. Once built, it needs to be maintained, extended as new environments come in scope, and connected to the remediation workflows that make the data actionable. The organizations that get this right treat cryptographic visibility the same way they treat vulnerability management: as a continuous operational discipline, not a periodic audit exercise.

How Encryption Consulting Can Help

For most organizations, building a complete cryptographic inventory and migrating to post-quantum cryptography cannot be done with existing tooling and internal capacity alone. Encryption Consulting works with enterprises at every stage of this process, from initial discovery through full PQC migration, with services and purpose-built tooling designed specifically for the complexity of real enterprise PKI environments.

PQC Advisory Services

Here is what you get from our structured advisory engagement:

• A Cryptographic Asset Register, produced through systematic discovery across your endpoints, applications, APIs, and infrastructure. This is the baseline that makes every subsequent step possible.
• A Risk Assessment Report, evaluating your exposure to quantum threats, identifying RSA and ECC dependent systems, and delivering prioritized findings with risk severity ratings by category: security, compliance, and operational.
• A PQC Migration Roadmap, a phased plan aligned to your risk appetite, regulatory requirements, and NIST timelines, including cryptographic agility so your systems can adapt as standards continue to evolve.
• Vendor Evaluation and Pilot Testing support, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.
• Full Implementation, covering deployment of hybrid classical and quantum-safe models, rollout of PQC across your PKI and infrastructure, and monitoring setup for long-term cryptographic health.

CBOM Secure

A note worth making explicitly: CBOM Secure is not the same thing as a CBOM. A CBOM (Cryptographic Bill of Materials) is a structured artifact, a record of the cryptographic components in a given application or system. CBOM Secure generates and consumes CBOM data, but it also performs continuous discovery and runtime inventory management across the full enterprise environment. The distinction matters because a CBOM alone tells you what was built into an application at a point in time. CBOM Secure tells you what is actually running, where it is running, and how it is changing.

A successful post-quantum transition begins with visibility. Organizations cannot modernize cryptography if they do not know where certificates, keys, algorithms, and cryptographic dependencies exist across their environment.

Encryption Consulting’s CBOM Secure provides a continuous view of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services. Rather than producing a point-in-time inventory, it helps organizations understand how cryptography is being used, where it is deployed, and how it changes over time.

CBOM Secure continuously discovers and tracks certificates, keys, algorithms, and cryptographic dependencies across the enterprise. It provides visibility into asset ownership, certificate and key relationships, algorithm usage, lifecycle events, and cryptographic exposure, helping teams identify unmanaged assets, deprecated algorithms, and systems that may require modernization.

The platform also supports policy-driven governance by validating cryptographic configurations against organizational standards and highlighting deviations before they become operational or compliance risks.

For organizations preparing for post-quantum cryptography, CBOM Secure identifies systems that rely on quantum-vulnerable algorithms and provides the visibility needed to prioritize remediation and migration activities.

Whether your organization is starting from scratch with no formal inventory in place or is looking to operationalize an existing discovery effort into a continuous governance program, Encryption Consulting brings both the advisory depth and the platform capability to move you forward. To learn more about our PQC Advisory Services or CBOM Secure, visit encryptionconsulting.com or reach out to our team directly.

Conclusion

A cryptographic inventory is not a compliance checkbox or a one-time audit deliverable. It is the operational foundation that enables certificate lifecycle management, algorithm migration, and quantum readiness planning. The three environments covered here, cloud infrastructure, CI/CD pipelines, and connected devices, are where most organizations have the weakest visibility today, and where the consequences of that gap are most significant.

Organizations cannot automate, remediate, or migrate cryptography they cannot see. The starting point is the same regardless of environment: know what you have, know where it lives, and keep that knowledge current. Quantum readiness begins with cryptographic visibility. Everything else follows from there.