Start with an inventory. Teams need to discover what certificates, keys, and certificate authorities exist, then map issuer, owner, use case, and approver information into a single view. Visibility is the foundation for prioritisation because you cannot secure what you cannot locate, track, or attribute. A cross-functional inventory also exposes duplicate tooling, shadow deployments, and unmanaged certificates before they fail.
Build the first visibility layer around inventory, ownership, and usage
The most useful starting point is not a dashboard, it is a complete inventory of the things that can authenticate or assert trust. That means certificates, keys, certificate authorities, where they are issued from, where they are used, and who owns them. A single view only becomes operationally useful when it also captures approver, business purpose, and environment so teams can distinguish critical infrastructure from forgotten sprawl.
This is the point where visibility turns into security value. Once teams can see the population, they can separate managed assets from shadow deployments, spot duplicate tooling, and identify certificates that are present but not governed. That also creates the first credible baseline for replacement, rotation, and decommissioning work rather than treating every renewal as an isolated event. For a broader NHI inventory and lifecycle model, see Ultimate Guide to NHIs and the Top 10 NHI Issues.
Why certificate visibility depends on trust-chain context, not just asset counts
Counting certificates is necessary but incomplete. Teams need to understand issuer relationships, intermediate authorities, expiry profiles, and where trust anchors are distributed, because the same certificate can have very different operational risk depending on what trusts it and what depends on it. That is why certificate management has to be mapped to use case, ownership, and lifecycle, not just storage location.
The practical objective is to make certificate data usable for prioritisation. A certificate tied to production service traffic, internal API authentication, or a shared trust bundle carries more operational weight than a test certificate in a lab. This is also where expired, duplicated, or unmanaged certificates become visible before they create outages or authentication failures. The certificate lifecycle concerns here align closely with Guide to NHI Rotation Challenges and The Critical Gaps in Machine Identity Management report.
How to structure the inventory so teams can act on it
The inventory should be built as a control dataset, not as a static spreadsheet. At minimum, each record should capture the identity object, issuer, subject, owner, approver, environment, dependency, expiration date, renewal path, and whether the certificate is external, internal, or embedded in an application or workload. Without those fields, teams can see volume but not accountability or blast radius.
For practitioners, the key design choice is to make the inventory queryable by operational questions. That means you should be able to ask which certificates are expiring soon, which ones lack a named owner, which ones appear in production but are approved for non-production, and which ones are shared across services. That kind of structure turns discovery into continuous governance, which is why many machine-identity programmes pair inventory with The State of Non-Human Identity Security as a lifecycle and posture reference.
Risk and Threat Considerations
Visibility failures create immediate exposure because machine identities and certificates are often operational dependencies long before they are treated as security assets. If teams cannot attribute ownership or locate all trust material, they miss orphaned certificates, unmanaged renewals, and hidden service-to-service trust paths that can fail suddenly or be abused quietly.
Failure mechanism: Attackers and internal failure modes both exploit blind spots, such as exposed credentials, stale trust relationships, or certificates that remain valid after the owning team has lost track of them. When the inventory is incomplete, renewal, revocation, and replacement actions become partial and the environment drifts faster than the team can correct it.
Impact: The result can be authentication outages, unintended trust persistence, privilege sprawl, and difficulty proving which system is responsible for a given certificate or key. In larger environments, the same gap also delays incident response because teams cannot quickly determine what else a compromised certificate might unlock.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST SP 800-57 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Orphaned machine identities and certificates need ownership and decommissioning. |
| NHI-02 — Secret Leakage | Visibility starts with finding exposed keys, certificates and related secrets. | |
| NHI-07 — Long-Lived Secrets | Certificate visibility must expose long-lived trust material that needs renewal governance. | |
| Recommendation — Tie every certificate and key to an owner so offboarding and revocation are enforceable. Inventory all secret-bearing assets and flag unknown or unmanaged certificate material. Track expiry and cryptoperiod data so long-lived credentials can be rotated on schedule. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates and keys require lifecycle control, inventory, and renewal oversight. |
| AC-2 — Account Management | Ownership and approver data are needed to govern machine identity use and cleanup. | |
| AU-9 — Protection of Audit Information | A trustworthy inventory depends on tamper-resistant records of trust assets and changes. | |
| Recommendation — Maintain an inventory of authenticators and enforce renewal, rotation, and revocation. Assign accountable owners and remove unmanaged identities from active use. Protect inventory records so changes to certificates and keys remain traceable. | ||
| CIS Controls v8 | CIS-5 — Account Management | Discovery of machine identities and certificates supports control over unmanaged credentials. |
| CIS-6 — Access Control Management | Certificate visibility reveals which trust paths and service access should be reduced. | |
| Recommendation — Inventory and govern all credentials and certificates with clear ownership and lifecycle dates. Review certificate-backed access paths and remove unnecessary trust relationships. | ||
| NIST SP 800-57 | Key Management | The question directly concerns discovering and tracking keys and certificate lifecycle data. |
| Recommendation — Track key lifecycle attributes, including generation, storage, rotation, and destruction. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Inventorying machine identities and certificates is part of controlling identity records. |
| Recommendation — Keep a current register of identities and their associated authentication material. | ||
Practitioner Guidance
What to prioritise: Start with the highest-impact trust material first, meaning production certificates, CA roots and intermediates, and any credentials that authenticate service-to-service traffic. Then add ownership and approver data before chasing advanced automation, because missing accountability is usually the real blocker to renewal and rotation.
What to verify: A useful inventory should answer three questions without manual reconciliation: who owns it, what depends on it, and how it is renewed or revoked. If any of those fields are missing for a production certificate, treat that as a control gap rather than a documentation issue.
Practitioner takeaway: The first win is not perfect coverage, it is a trustworthy baseline that lets teams connect every certificate to an owner, a purpose, and an expiry path so they can reduce hidden trust before they automate it.
Related resources from NHI Mgmt Group
- How should security teams govern cryptographic keys and certificates across human and machine identities?
- How should security teams govern machine identities when API clients rely on shared secrets and certificates across cloud environments?
- How should security teams start building API protection when they do not yet have full visibility into their API landscape?
- How should healthcare security teams implement converged identity platforms to improve visibility across human and machine identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
