Start with discovery, not renewal. Teams need a complete inventory of keys and certificates across the network, including cloud services, containers, service meshes, and other machine-to-machine trust paths. Continuous scanning is essential because new assets can appear without approval or visibility. Once the inventory is known, teams can assign maturity levels and automate issuance, renewal, revocation, and approval workflows.
What an enterprise cryptography inventory must include before automation
A useful inventory starts by treating cryptography as an enterprise control surface, not a list of certificates to renew. Teams need to know what exists, where it runs, what depends on it, who owns it, and how it is used across applications, cloud services, containers, service meshes, and other machine-to-machine trust paths. That means capturing keys, certificates, issuers, lifetimes, locations, dependencies, and replacement paths.
Discovery has to be broader than the obvious certificate management view because many critical assets are embedded in platforms rather than exposed through a single console. A complete picture usually comes from combining host inspection, cloud inventory, network telemetry, repository scanning, cluster discovery, and configuration analysis so hidden or orphaned material does not escape the first pass.
For teams that are building this foundation, the right mindset is described well in the NHI Lifecycle Management Guide, which frames discovery, visibility, and ownership as lifecycle problems, not one-time cleanup tasks.
Why discovery must come before renewal workflows
Automation is only safe when the underlying estate is understood. If renewal workflows begin before inventory, the result is often a local optimisation that masks missing assets, duplicated certificates, stale keys, or hidden dependencies. Teams may successfully automate a subset of known systems while leaving unmanaged cryptographic material in shadow IT, ephemeral infrastructure, or third-party integrations.
This is especially important where short-lived infrastructure changes rapidly. Containers, service meshes, and cloud-managed services can create and replace trust material faster than manual register-maintain-review processes can keep up. Continuous scanning is therefore not optional bookkeeping, it is the mechanism that keeps the inventory current enough to support safe issuance, renewal, revocation, and approval automation.
The enterprise view of this problem is captured in Ultimate Guide to NHIs, Key Challenges and Risks, which ties visibility gaps and unmanaged credentials to the failures that appear when inventory is incomplete.
How to structure the inventory so it can support automation later
Inventory fields should be chosen for operational actionability, not only for reporting. At minimum, teams should be able to answer: what is this object, which system or workload depends on it, where is it deployed, when does it expire, how was it issued, what level of trust does it grant, and what is the approved recovery path if it fails. Without those attributes, automation becomes a blind renewal engine instead of a governed control.
A practical inventory also needs maturity classification. Some assets may be safe to automate immediately, while others need manual approval, exception handling, or environment-specific review first. That tiering helps security teams sequence work so that high-risk or high-blast-radius material gets stricter controls before renewal is delegated to a workflow.
Lifecycle processes for managing NHIs are a useful model here because they connect inventory, classification, ownership, and rotation into one operating picture rather than treating them as separate projects.
Risk and Threat Considerations
An incomplete cryptography inventory creates blind spots that attackers and outages can both exploit. Expired certificates, duplicated keys, unknown trust paths, and unmanaged secrets can break service availability, undermine trust boundaries, or leave hidden credentials in place long after teams believe they are gone.
Failure mechanism: Missing discovery allows orphaned or shadow cryptographic assets to persist, which can block renewal, delay revocation, or leave unauthorized trust material active in production.
Impact: The result can be outage, failed authentication, uncontrolled access, or a larger attack surface when hidden keys or certificates are reused across environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | The question is about key and certificate inventory before automation. |
| Recommendation — Inventory key lifecycles, cryptoperiods, and ownership before automating renewal or revocation. | ||
| NIST CSF 2.0 | ID.AM-01 — Identities and Inventory | Enterprise cryptography inventory depends on knowing what assets and trust material exist. |
| Recommendation — Maintain an authoritative inventory of cryptographic assets and their dependencies. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Cryptography inventory depends on discovering assets across the enterprise before automation. |
| Recommendation — Discover and maintain assets that host or consume cryptographic material. | ||
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | Cloud services are explicitly part of the cryptography inventory scope. |
| A.8.24 — Use of cryptography | The topic is enterprise cryptography and how to govern it before automation. | |
| Recommendation — Record cryptographic dependencies in cloud services and manage them under security controls. Define and manage cryptographic use, including inventory, ownership, and lifecycle handling. | ||
Practitioner Guidance
What to prioritise: Build the inventory around trust paths and ownership first, not around certificate counts. If a key or certificate cannot be tied to a system, owner, expiration date, and dependency chain, it is not ready for automation.
What to verify: Confirm that discovery covers cloud-managed services, containers, orchestration layers, service meshes, and CI/CD-generated material, because these are the places where hidden cryptography most often appears after the first manual pass.
Practitioner takeaway: Automation should inherit a trustworthy register, not create one. The inventory is the control plane, and if it is incomplete, every downstream renewal or revocation workflow inherits that blind spot.
Related resources from NHI Mgmt Group
- How should security teams build cryptographic visibility before starting a post-quantum cryptography transition?
- How should security teams build an accurate inventory of applications running on workloads before enforcing least-privilege policy?
- How should security teams build an accurate inventory of exposed GraphQL APIs before they start testing them?
- How should security teams build an inventory of AI models and tools before enforcing supply chain controls?
