Public key mismanagement turns PKI into a business risk

At a glance

What this is: This is an analysis of how public key and certificate mismanagement turns PKI into an enterprise security and identity trust problem.

Why it matters: It matters because mismanaged keys can disrupt authentication, weaken access control, and create operational risk across NHI, autonomous, and human identity programmes.

👉 Read Keyfactor's analysis of real-world risks in public key mismanagement

Context

Public key infrastructure fails when ownership, inventory, and revocation are fragmented. In identity terms, that turns certificates and signing keys into unmanaged non-human identities that can keep conferring trust long after the organisation has lost track of them.

The article argues that key sprawl, delayed revocation, and poor visibility create outages and breach exposure across cloud and on-prem environments. That is not just a PKI hygiene issue. It is a governance problem that affects authentication, token validation, and service trust at enterprise scale.

Key questions

Q: How should security teams govern public keys across cloud and on-prem environments?

A: They should treat public keys and certificates as governed identity assets with named ownership, inventory, and lifecycle state. The practical goal is to know what is trusted, where it is used, and how quickly revocation will take effect across every relying system. Without that control, PKI sprawl becomes an identity and availability risk.

Q: Why do revoked certificates sometimes remain dangerous after invalidation?

A: Because revocation only matters when every dependent system learns about it quickly enough to stop trusting the credential. CRL, OCSP, token lifetimes, and caches can all extend acceptance after the original key should have lost authority. That delay turns a revoked key into a temporary standing trust window.

Q: What do security teams get wrong about signing key exposure?

A: They often treat it as a storage or scanning problem instead of a trust compromise. If an attacker obtains a signing key, they can create valid tokens or certificates that downstream systems will accept. The right response is to assume forged trust, invalidate dependent artefacts, and review the full issuance path.

Q: Which controls matter most when reducing PKI breach impact?

A: The controls that matter most are ownership clarity, rapid revocation propagation, protected key storage, and crypto-agile replacement paths. Those four controls decide whether a mismanaged key becomes a short-lived outage or a prolonged trust failure across authentication and service access.

Technical breakdown

How key sprawl turns PKI into hidden identity debt

PKI sprawl happens when certificates, signing keys, and trust anchors are distributed across teams, environments, and third parties without a single authoritative inventory. The technical risk is not merely volume. It is the loss of lifecycle state, which means no one can reliably tell what is active, expired, revoked, or still trusted by downstream systems. In identity terms, each key becomes a non-human identity with its own privilege boundary, yet that boundary is often invisible. Once inventory breaks, revocation becomes guesswork and trust chains become brittle.

Practical implication: build a single system of record for certificate and key ownership before scale makes revocation impossible to govern.

Why certificate revocation gaps create a standing trust window

Revocation only works when the relying system checks status quickly enough to matter. The article’s hybrid example shows the failure clearly: if a certificate expires or is revoked faster than CRL or OCSP updates propagate, a previously trusted credential can remain accepted for hours. That creates a trust window where access is technically invalid but still operationally usable. In a PKI context, this is the same class of failure as standing privilege, except the privilege is cryptographic trust rather than an access role. The issue is timing, not just configuration.

Practical implication: align certificate lifetime, revocation propagation, and validation paths so trust cannot persist beyond intended validity.

How forged tokens exploit signing key exposure

When a signing key is exposed, attackers do not need to crack the cryptography. They can mint tokens that look legitimate to downstream services because the signature validates against the trusted key. The Microsoft case described in the article shows the sequence: a key was recovered from an improperly handled crash dump, then used to forge valid JWTs and impersonate users. That is a direct abuse of trust material, not a password theft. The architectural lesson is that token systems inherit the security of the private key, the storage path, and the revocation process.

Practical implication: treat signing keys as high-impact identity assets and place them under strict storage, scanning, and revocation controls.

Threat narrative

Attacker objective: The attacker aimed to impersonate users and gain unauthorized access to trusted enterprise services by abusing the organisation’s own signing infrastructure.

1. Entry occurred when a cryptographic key was unintentionally included in a crash dump and later accessed from an internet-connected environment.
2. Escalation followed when the attacker used the exposed signing key to forge valid JSON Web Tokens and bypass authentication controls.
3. Impact expanded as valid access persisted through long-lived tokens, creating room for impersonation and possible lateral movement across cloud services.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Public keys are non-human identities, not passive configuration artefacts. Once a key signs authentication tokens, validates trust, or anchors a certificate chain, it becomes a governed identity object with lifecycle, ownership, and revocation requirements. Organisations that treat keys as back-end plumbing miss the fact that compromise of the key is compromise of the trust relationship. Practitioners should manage cryptographic assets with the same discipline they apply to other privileged machine identities.

Key sprawl creates identity blast radius before any attacker arrives. Fragmented ownership means no one can answer basic governance questions about where keys live, who is responsible, or how quickly revocation can propagate. That is why visibility gaps are not cosmetic. They are the precondition for broken trust chains, emergency recovery, and uncontrolled exposure when one team’s certificate decision affects many downstream systems. The practitioner takeaway is that ownership clarity is a security control, not an administrative convenience.

Crypto-agility is a governance requirement because static trust assumptions age badly. Public key ecosystems fail when algorithms, key sizes, and certificate lifetimes cannot change without operational disruption. That makes cryptography a lifecycle problem, not a one-time design choice. The field should stop framing PKI as a purely technical function and start treating it as a continuously governed identity service. Practitioners should design for replacement, rotation, and revocation at speed.

Long-lived tokens amplify public key mistakes into prolonged access. Even when a signing key is invalidated, downstream sessions and issued tokens can continue to function if they are not tracked tightly enough. That extends the attack window and makes response slower than the compromise. The governance lesson is that trust revocation must be matched to token persistence, or the organisation merely moves from key compromise to delayed containment. Practitioners should align token policy with key lifecycle reality.

PKI risk belongs in identity governance, not only infrastructure operations. The article shows that outages, compliance issues, and breach exposure all stem from the same root problem: unmanaged trust material. This connects certificate management to IAM, PAM, and NHI governance because all three depend on knowing what is trusted, by whom, and for how long. The practitioner conclusion is simple: PKI needs identity ownership and lifecycle controls, not just technical maintenance.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly weak identity governance compounds.
• The broader identity lesson is to align certificate and secret lifecycle management with the NHI Lifecycle Management Guide before trust material becomes invisible.

What this signals

Identity teams should treat PKI as part of NHI governance, not as a detached infrastructure function. The same lifecycle logic that governs service accounts applies to certificates, signing keys, and other trust material: ownership, visibility, renewal, and revocation must all be explicit. With 72% of organisations reporting or suspecting NHI breaches, according to The 2024 ESG Report: Managing Non-Human Identities, the governance gap is already large enough to turn routine certificate drift into enterprise risk.

The next maturity step is to connect PKI inventory to access governance and incident response. When signing keys, token lifetimes, and revocation status are not visible in one operational view, teams cannot measure exposure or prove containment. That is where the NHI Lifecycle Management Guide becomes useful as a governance model rather than a product checklist.

For practitioners, the signal is clear: the more distributed your trust fabric, the more your identity programme needs policy-driven certificate oversight, short-lived credentials, and auditable ownership. Without that, PKI failures will keep surfacing as outages first and security incidents second.

For practitioners

• Establish a central key and certificate inventory Track every active certificate, private key, signing key, and trust anchor across cloud, on-prem, containers, endpoints, and third parties. Assign a named owner and expiry state to each item so revocation and renewal are not dependent on tribal knowledge.
• Shorten the trust window for revocation checks Measure the gap between certificate invalidation and downstream enforcement across CRL, OCSP, and application caches. If relying systems can continue to trust revoked credentials, reduce token lifetimes and tighten propagation paths.
• Protect signing keys as high-value identity assets Store signing material in hardened systems, scan crash dumps and logs for accidental exposure, and restrict who can access exportable private keys. Treat any signing-key disclosure as a trust compromise, not just a secrets incident.
• Make crypto-agility part of policy design Require the ability to swap algorithms, key sizes, and certificate profiles without redesigning dependent services. Build policy so replacement and rotation are normal operations rather than emergency projects.

Key takeaways

• Public key mismanagement is an identity governance problem because signing keys and certificates determine who and what is trusted.
• The breach risk is not hypothetical, because exposed signing keys can mint valid tokens and keep access alive even after invalidation.
• Organisations should centralise inventory, tighten revocation timing, and design for crypto-agile replacement before the trust fabric breaks under growth.

Key terms

• Public Key Infrastructure: A public key infrastructure is the system that issues, manages, distributes, and revokes certificates and keys used to establish trust. In identity programmes, PKI underpins authentication and secure communications, so weak lifecycle control can create outages, impersonation risk, and broken trust chains.
• Certificate Revocation: Certificate revocation is the process of marking a certificate as no longer trustworthy before its natural expiry. In practice, revocation only works if relying systems check status quickly enough through mechanisms such as CRL or OCSP, otherwise invalid credentials may still be accepted.
• Crypto-Agility: Crypto-agility is the ability to change algorithms, key sizes, and trust mechanisms without redesigning the surrounding system. For identity teams, it means cryptographic policy can adapt to new threats, compliance shifts, and lifecycle changes without forcing disruptive replatforming.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Keyfactor: Real-World Risks of Public Key Mismanagement. Read the original.