TL;DR: 54% of enterprise respondents lacked policy enforcement and remediation for keys and certificates, while another 54% did not know how many they had, where they were, or how they were used, according to DigiCert citing Ponemon Institute data. That combination turns certificate sprawl into a governance failure, not just an operational one.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Inventory blind spots and weak policy enforcement are the core failure modes in enterprise key and certificate management.
Why it matters: It matters because IAM, PAM, and platform teams cannot control certificate risk, enforce least privilege, or respond to compromise if they cannot inventory, locate, and govern the credentials in use.
By the numbers:
- 54% of enterprise respondents admit to having a lack of policy enforcement and remediation for keys and certificates.
- 54% of security professionals say they do not know how many keys and certificates they have, where they are located, or how they are used.
- More than 20 manual steps are required to update a single certificate in the replacement process described in the article.
Context
Enterprise key and certificate governance fails when organisations lose inventory before they lose control. The first problem is not rotation, cryptography, or TLS policy, but basic visibility into where keys and certificates exist and which services depend on them.
This is a non-human identity governance problem because certificates and private keys are machine credentials that authenticate systems, services, and applications. If teams cannot enforce policy or remediate misuse across that estate, they cannot treat certificates as governed identities.
The article’s figures point to a common operating model failure rather than an edge case. The combination of missing inventory and weak remediation means compromise can persist unseen until renewal, outage, or incident response forces discovery.
Key questions
Q: What breaks when organisations do not know where all their keys are?
A: When organisations cannot locate all their keys, they lose the ability to govern them consistently. Hidden or unmanaged keys are harder to rotate, audit, retire, or detect when compromised. That gap creates blind spots across applications and devices, and those blind spots are where breaches and policy failures most often take root.
Q: Why do unmanaged certificates create more than an outage risk?
A: Because a certificate is tied to a private key that proves identity, unmanaged certificates can enable impersonation, decryption, or fraudulent trust relationships. The problem is not only expiry or service disruption. It is that stale or exposed trust material can let an attacker present themselves as a legitimate system or service.
Q: How should security teams measure whether certificate governance is actually working?
A: Use operational signals, not policy statements. Track certificate expiry outages, provisioning and revocation latency, support ticket volume, and whether teams can identify all cryptographic assets in use. If a trust programme looks compliant on paper but still produces outages, workarounds or blind spots, governance is not working as intended.
Q: What should teams do when certificate replacement requires many manual steps?
A: Treat the process as an operational risk, not a maintenance detail. Long replacement chains increase the chance of delay, partial rollout, and inconsistent trust states across applications. The immediate response is to standardise the workflow so replacement becomes repeatable before a real compromise forces it.
Technical breakdown
Why certificate inventory is the first control that fails
Private keys and digital certificates behave like non-human identities because they authenticate services and secure data flows. When organisations do not know how many they have, where they live, or how they are used, every downstream control becomes partial. Rotation, revocation, policy enforcement, and incident response all depend on a current inventory. Without that inventory, security teams are managing an unknown population of machine credentials rather than a governed estate.
Practical implication: Build a complete inventory of certificates, keys, and their owning services before trying to tune policy or rotation.
How weak remediation turns certificate sprawl into governance debt
Policy without remediation is only documentation. The article highlights a gap where teams may recognise the need for control but cannot consistently enforce it across thousands of keys and certificates. That creates governance debt because each unmanaged credential can remain trusted even after its risk changes. In practice, the problem scales faster than manual teams can close it, especially when replacement requires many operational steps and coordination across applications.
Practical implication: Tie discovery to enforced remediation workflows so unowned or expired credentials cannot remain active by default.
Why private key compromise has a wide blast radius
A compromised private key does not fail in isolation. It can let an attacker impersonate the legitimate owner, intercept or decrypt protected traffic, and force costly replacement across every dependent platform, application, or service. The blast radius is architectural because certificates are embedded into trust relationships, not just stored as files. That is why key compromise quickly becomes an availability, fraud, and compliance problem at the same time.
Practical implication: Map each certificate to the services and trust relationships it protects so compromise response can target the full dependency set.
Threat narrative
Attacker objective: The attacker aims to impersonate trusted systems or decrypt protected communications to gain fraudulent access and disrupt trust relationships.
- Entry occurs when an attacker obtains a private key or certificate and can present it as legitimate trust material to systems that rely on it.
- Credential abuse follows when the attacker uses that key to impersonate the rightful owner, intercept secure communications, or decrypt sensitive data in transit.
- Impact emerges as trust is broken across connected services, forcing certificate replacement, potential compliance exposure, and loss of customer confidence.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate inventory is the control that determines whether governance exists at all: a team cannot enforce policy, scope remediation, or prove accountability for keys and certificates it cannot count. The article shows that visibility is not an operational nicety but the prerequisite for any credible governance model. Practitioners should treat unknown inventory as a control failure, not a reporting gap.
Private keys and certificates are non-human identities, not passive assets: they authenticate machines, establish trust, and carry access authority across systems. That means lifecycle discipline, ownership, and revocation matter as much here as they do for human access. The practical implication is that identity governance must extend beyond user accounts into machine credential estates.
Manual replacement processes create trust debt that compounds with scale: if updating a single certificate takes more than 20 steps, the organisation has already designed a process that will lag compromise and renewal. That lag turns every additional certificate into a future exposure window. The right governance question is not whether certificates are encrypted, but whether they are governable at operating speed.
OWASP-NHI and NIST-CSF both fit this problem because the primary failure is identity lifecycle control, not cryptography alone: the article centres on unknown credentials, weak enforcement, and remediated trust states. This is exactly the kind of machine identity estate where discovery, ownership, and enforcement determine security outcomes. Practitioners should align certificate governance to NHI lifecycle control, not just infrastructure hardening.
The named concept here is certificate governance debt: when organisations cannot inventory, enforce, and remediate keys and certificates in the same cadence, risk accumulates faster than it is reduced. That debt shows up as delayed replacement, hidden ownership, and brittle trust chains. Teams should read the problem as a lifecycle failure that will eventually surface in outage, fraud, or incident response.
From our research library:
- 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Certificate governance debt: when teams cannot inventory, own, and remediate keys and certificates together, risk accumulates faster than renewal schedules can absorb it. The programme impact is simple: governance has to move from periodic review to continuous credential lifecycle control.
Security teams should expect certificate management to behave like any other identity lifecycle problem. The combination of unknown inventory and weak remediation means that discovery, ownership, and revocation are the controls that decide whether trust survives an incident.
For practitioners
- Establish a complete certificate inventory Catalogue every private key and certificate, record where it is deployed, and identify the application, service, or platform that depends on it.
- Assign explicit ownership for each credential Tie every certificate and key to a named system owner so policy enforcement and remediation do not stop at discovery.
- Automate remediation for unknown or expired entries Create workflows that revoke, replace, or quarantine credentials when inventory data is missing, stale, or inconsistent.
- Reduce manual replacement steps Standardise certificate renewal and rotation paths so a single replacement does not require a long chain of handoffs across teams.
- Map trust dependencies before a compromise occurs Document which services, applications, and data flows rely on each key so response teams can assess blast radius quickly.
Key takeaways
- The core risk is not just certificate sprawl, but the inability to govern machine credentials that underpin trust across services and applications.
- The article cites two 54% findings and a replacement process that can require more than 20 manual steps, showing that the problem is both widespread and operationally heavy.
- Teams that cannot inventory and remediate keys and certificates quickly should treat the estate as identity governance debt, not as a background infrastructure task.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Untracked certificates and keys persist because ownership and lifecycle are not closed out cleanly. |
| NHI-02 — Secret Leakage | The article centres on exposed and ungoverned machine credentials that lose control boundaries. | |
| NHI-05 — Overprivileged NHI | Certificates that are not scoped or owned can confer more trust than the service needs. | |
| Recommendation — Inventory every certificate and revoke or retire credentials when ownership or service use changes. Scan for exposed keys and certificates and remove or rotate any credential found outside governed stores. Reduce trust scope for each certificate to the minimum service and connection set it actually requires. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key and certificate rotation, replacement, and revocation are authenticator lifecycle controls. |
| Recommendation — Apply authenticator management controls to enforce issuance, rotation, revocation, and replacement discipline. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about knowing and controlling which machine identities can authenticate where. |
| Recommendation — Maintain current entitlement records for every certificate and key so access and trust can be reviewed. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | Stolen keys enable credential access and then wider trust and service impact. |
| Recommendation — Map compromised certificates to credential-access and impact pathways when prioritising detection and response. | ||
Key terms
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Certificate Inventory: A certificate inventory is the authoritative list of all certificates in use across an environment, including owner, expiry, issuing authority, and deployment location. It is the control foundation for monitoring and renewal because teams cannot govern what they cannot reliably enumerate.
- Trust Chain: The trust chain is the set of delegated relationships that lets one system, token, or integration act on behalf of another. In NHI security, it is often the real attack surface because compromise travels through legitimate permissions instead of obvious malware.
- Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org