Enterprise key and certificate governance still fails without inventory

At a glance

What this is: This is a governance-focused analysis of enterprise key and certificate security, showing that weak inventory and enforcement remain the core failure points.

Why it matters: It matters because unmanaged keys and certificates create exposure across NHI, IAM, and privileged access programmes, especially where trust depends on assets nobody can accurately inventory or control.

By the numbers:

• 54% admit to having a lack of policy enforcement and remediation for keys and certificates.
• 54% of security professionals say they don’t even know how many keys and certificates they have, where they are located, or how they are used.

👉 Read DigiCert's analysis of enterprise key and certificate security

Context

Enterprise keys and certificates are trust controls, but they only work when organisations can inventory them, enforce policy across their lifecycle, and retire them before they drift out of control. The article’s central problem is not cryptography itself, but the operational gap between what teams believe they manage and what actually exists in production.

For identity and access programmes, that gap matters because keys and certificates increasingly function as non-human identities and privileged trust anchors. When those assets are invisible, the organisation cannot reliably apply least privilege, rotation, revocation, or ownership controls across workloads, applications, and services.

Key questions

Q: How should security teams govern keys and certificates across large environments?

A: Treat keys and certificates as lifecycle-managed trust assets with explicit owners, usage records, renewal dates, and revocation paths. Security teams should maintain a single inventory, enforce policy at issuance and renewal, and verify that every certificate can be tied to a business service or workload. Without that structure, trust sprawl becomes invisible risk.

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: What do security teams get wrong about private key protection?

A: Teams often focus on encryption status and forget the operational controls around storage, ownership, and access. A protected key that no one tracks is still a governance failure if it can be reused, copied, or left in place after the service changes. Key protection has to include lifecycle accountability.

Q: How do organisations know whether certificate governance is actually working?

A: Look for complete inventory coverage, named ownership, timely renewal, documented revocation, and evidence that expired or unused certificates are removed quickly. If teams cannot answer where a certificate lives or who uses it, governance is not working, even if the platform reports that encryption is enabled.

Technical breakdown

Why certificate inventory breaks down at enterprise scale

Keys and certificates are distributed across applications, servers, development environments, and third-party integrations, which makes manual tracking unreliable. The technical failure is not that certificates are hard to create, but that their lifecycle spans many systems and owners. Without a current inventory, security teams cannot tell which certificate supports which service, which ones are expired, or which ones are still trusted by downstream clients. That is why visibility is a prerequisite for any meaningful certificate governance programme.

Practical implication: build authoritative inventory and ownership data before you attempt any rotation or revocation programme.

How private key compromise turns trust into impersonation

A private key proves identity to clients and servers, so compromise of that key lets an attacker impersonate the legitimate owner. The result is not only decryption risk, but also fraud, phishing, and service impersonation that can cascade through TLS-dependent systems. Because certificates bind trust to the key behind them, exposure of the private key undermines the entire trust relationship. In practical terms, the certificate is only as safe as the protection surrounding the key material itself.

Practical implication: treat private key storage and access as a privileged control surface, not a back-office administrative detail.

Why hardware-backed storage changes the risk model

The article points to cryptographic hardware devices because software-stored keys on general-purpose systems are easier to steal, copy, and reuse. Hardware-backed storage narrows the attack surface by making key extraction harder and by reducing the chance that a compromised host yields reusable trust material. This does not remove lifecycle obligations, but it changes the likelihood and scale of compromise. The architecture choice matters because every key copied into software creates a broader blast radius than one anchored in protected hardware.

Practical implication: move high-value keys into hardware-backed storage where compromise of the host does not automatically expose the trust anchor.

Threat narrative

Attacker objective: The attacker aims to turn stolen trust material into impersonation, data access, and fraudulent confidence in systems that appear legitimate.

1. entry occurs when attackers target exposed or poorly protected private keys and certificates that are spread across systems with weak inventory and inconsistent policy enforcement.
2. escalation follows when the attacker uses a stolen private key to impersonate the legitimate owner and establish trust with clients, services, or external parties.
3. impact is achieved through decryption, phishing, service impersonation, and compliance failure, which can lead to customer loss, reputation damage, and operational disruption.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Enterprise certificate governance fails first at visibility, not cryptography: The article shows that organisations cannot secure what they cannot inventory, and the 54% figure for lost visibility is the real warning sign. In practice, keys and certificates behave like non-human identities with hidden ownership, hidden usage, and hidden renewal risk. The practitioner conclusion is that inventory quality is the control surface, not a reporting exercise.

Standing trust is the core failure mode here: Keys and certificates are often treated as persistent trust anchors long after their business owner, application owner, or security owner has lost track of them. That creates a certificate lifecycle problem, not just a secrets problem, because the trust relationship outlives the control relationship. The implication is that lifecycle governance must be enforced as tightly as issuance.

Private key exposure is identity impersonation, not just data compromise: Once an attacker holds the key behind a certificate, they can present themselves as the legitimate party to systems that still trust that certificate chain. That turns certificate theft into a trust collapse event across applications and partner connections. Practitioners should read this as a control-plane failure in identity assurance, not a narrow encryption incident.

Hardware-backed key storage reduces blast radius, but only if ownership is defined: The article’s advice to use secure cryptographic hardware is directionally correct, but hardware alone does not solve orphaned certificates, unknown ownership, or failed revocation. The governance lesson is that stronger storage must be paired with clear accountability and lifecycle control. The practitioner conclusion is to align storage, ownership, and revocation before scaling trust anchors further.

Key and certificate risk is now an NHI governance problem as much as a PKI problem: In modern environments, certificates and keys function as machine identities that authenticate workloads, services, and integrations. That means identity teams, not only PKI specialists, need to own policy enforcement, remediation, and expiry handling. The practitioner conclusion is to bring keys and certificates into the same governance model used for other NHI classes.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is why practitioners should also examine Ultimate Guide to NHIs , Why NHI Security Matters Now when rebuilding ownership and lifecycle controls.

What this signals

Certificate and key governance now belongs in the same programme as NHI lifecycle management: when trust anchors cannot be inventoried, they cannot be owned, rotated, or revoked with confidence. That creates the same structural problem seen in broader NHI sprawl, where hidden identities outpace the controls built to manage them.

The practical signal for security leaders is that visibility has become the first control, not the supporting one. If the team cannot map a certificate to a service, a renewal path, and a revocation owner, the organisation is already operating with unmanaged trust.

For teams maturing their programme, the next step is to align certificate governance with identity inventory and policy enforcement, then anchor the model to NIST Cybersecurity Framework 2.0. That shifts the discussion from isolated PKI upkeep to repeatable governance across identities and trust material.

For practitioners

• Create a complete key and certificate inventory Map every certificate to an owner, system, renewal date, and usage path so that no trust anchor remains unattributed or orphaned. Include infrastructure, application, and partner-facing certificates in the same register.
• Separate issuance, storage, and revocation controls Assign different operational responsibilities for certificate creation, private key storage, and retirement so that one team cannot silently approve all three states. This reduces the chance that stale trust material persists after ownership changes.
• Move high-value private keys into hardware-backed storage Use secure cryptographic hardware for the certificates that protect customer traffic, code signing, and other critical trust paths. Avoid leaving those keys on general-purpose systems where compromise of the host can expose the key material.
• Enforce policy remediation before expiry becomes outage Tie certificate policy checks to alerting, ticketing, and remediation workflows so that weak enforcement is corrected before renewal failures or trust interruptions occur. Make policy drift visible early enough to act on it.

Key takeaways

• Enterprise key and certificate risk is mainly a visibility and enforcement problem, not a cryptography problem.
• When private keys are unmanaged, they become impersonation tools that can undermine trust, compliance, and customer confidence.
• The practical fix is lifecycle governance: inventory, ownership, policy enforcement, and hardware-backed storage for high-value trust anchors.

Key terms

• Private Key: A private key is the secret half of a cryptographic identity pair used to prove ownership and establish trust. If it is exposed, an attacker can impersonate the legitimate holder, decrypt protected traffic, or sign data as if they were the trusted party.
• Digital Certificate: A digital certificate binds a public key to an identity and is used to establish trust between systems, services, and users. In practice, certificates become lifecycle assets that must be issued, tracked, renewed, and revoked with clear ownership.
• Certificate Lifecycle Management: Certificate lifecycle management is the process of issuing, tracking, renewing, replacing, and revoking certificates across the enterprise. It becomes a governance discipline when teams need reliable ownership, policy enforcement, and visibility into where trust is in use.
• Hardware-backed Key Storage: Hardware-backed key storage keeps private keys inside dedicated secure devices rather than leaving them on general-purpose servers. This reduces the chance that a host compromise or routine administrative access will expose reusable trust material.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Securing Enterprise Keys and Certificates Should Be a Priority. Read the original.