Public key mismanagement turns PKI into a business risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Keyfactor's blog post: Public key mismanagement becomes a business problem when visibility, ownership, revocation, and lifecycle control fail.

Why it matters: It matters because IAM, PAM, and NHI programmes all depend on trusted cryptographic identity, and weak key governance can break authentication, availability, and auditability at once.

Context

Public key infrastructure is only as reliable as the ownership, inventory, and revocation process behind it. When public keys and certificates sprawl across cloud, on-premises, and hybrid environments, teams lose track of who owns them, where they live, and when they should be withdrawn.

That gap matters for identity security because certificates and signing keys are not just technical artefacts. They are trust anchors for authentication, access, and service continuity, so weak lifecycle control turns PKI into a governance problem rather than a pure cryptography problem.

Keyfactor argues that this starts to look like business risk when manual handling, inconsistent revocation, and poor visibility create outage potential, audit exposure, and room for misuse. The article’s starting position is typical for organisations that have outgrown ad hoc key management.

Key questions

Q: What breaks when PKI is left unmanaged or gets deprioritised for too long?

A: When PKI is neglected, certificate expiry, misconfiguration, and poor recovery planning can turn routine maintenance into an outage or security incident. Trust chains may fail, applications may stop authenticating, and teams may discover the problem only after services are already affected. The core failure is that PKI is easy to forget until the organisation needs it most.

Q: Why do short-lived certificates and delayed revocation create such a large security risk?

A: Short-lived certificates raise the stakes because their value depends on timely renewal and revocation. If teams cannot revoke certificates quickly, a compromised or outdated certificate can remain trusted long enough to be abused. In remote and cloud-heavy environments, that creates exposure across devices, services, and users, especially when certificate sprawl makes it hard to know what is still valid.

Q: How should teams govern certificate lifecycle management in multi-cloud environments?

A: Teams should govern CLM as part of the broader machine identity stack, not as a standalone certificate tool. That means tying issuance, renewal, revocation, and discovery to secrets management, key protection, and audit evidence so identity state remains consistent across cloud platforms and workloads.

Q: When does manual certificate handling become too risky?

A: Manual handling becomes too risky when the environment contains many distributed certificates, short renewal windows, or systems that must stay continuously available. At that point, the operational burden itself becomes a source of outages and audit failures. Organisations should automate before exceptions become the default operating model.

Technical breakdown

Why PKI ownership breaks down at scale

Public key infrastructure fails operationally when ownership is ambiguous. If no single team owns issuance, renewal, inventory, and revocation, certificates end up scattered across application teams, DevOps pipelines, cloud services, and third parties. That creates shadow keys, orphaned certificates, and inconsistent policy enforcement. The technical problem is not the cryptographic primitive itself. It is the control plane around it: the process that tracks lifecycle state, usage, and trust boundaries. In hybrid environments, that fragmentation is amplified because different validation paths, certificate authorities, and update cadences must stay in sync. Practical implication: assign explicit lifecycle ownership for every certificate and signing key.

Practical implication: Assign explicit lifecycle ownership for every certificate and signing key.

How delayed revocation extends token and certificate risk

Revocation only works when every dependent system can consume it quickly enough to matter. If certificate revocation lists or OCSP checks update slowly, or if long-lived tokens are not tied to prompt invalidation, an attacker can continue to use a compromised key after the original exposure is known. That is why revocation is not a paperwork step. It is a timing control that must align with token lifetime, validation frequency, and propagation across cloud and on-premises services. The Microsoft incident in the article illustrates this clearly: even after key invalidation, some access persisted because residual tokens were still trusted. Practical implication: reduce the gap between compromise discovery and trust removal.

Practical implication: Reduce the gap between compromise discovery and trust removal.

Why manual certificate tracking creates hidden trust gaps

Spreadsheets, calendar reminders, and ticket queues cannot keep pace with modern certificate volume. They miss renewals, fail to reflect ownership changes, and rarely provide a reliable real-time inventory. That creates blind spots in audit evidence and makes it easy for expired or duplicate certificates to linger in production. In hybrid deployments, manual tracking is even weaker because the system must reconcile cloud workloads, internal PKI components, and externally exposed validation services. The result is a trust fabric that looks controlled on paper but behaves unpredictably in production. Practical implication: move certificate state into a centrally governed inventory with continuous validation.

Practical implication: Move certificate state into a centrally governed inventory with continuous validation.

Threat narrative

Attacker objective: The objective was to impersonate users and maintain unauthorized access by abusing a trusted signing key and the tokens it could mint.

1. Entry occurred when a cryptographic key from a Microsoft consumer signing system was unintentionally included in a crash dump and later reached an internet-connected environment.
2. Credential abuse followed when attackers retrieved the key and used it to forge valid JSON Web Tokens.
3. Impact came through authentication bypass, user impersonation, unauthorized access to Microsoft 365 services, and lingering access from long-lived tokens even after invalidation.

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.
• Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PKI governance fails first at the ownership layer: when no team owns issuance, renewal, inventory, and revocation end to end, cryptographic trust becomes fragmented. That fragmentation is the real control failure behind most key sprawl stories, because it turns a trust anchor into an unmanaged asset. Practitioners should treat ownership mapping as a security control, not an administrative courtesy.

Crypto agility is now a business continuity requirement: static key policies create brittleness when certificate lifetimes shorten and validation paths multiply across hybrid estates. The article shows that resilience depends on being able to change keys, algorithms, and trust relationships without service interruption. The implication for practitioners is to design for rapid trust replacement, not just strong initial issuance.

Revocation latency is the decisive failure mode: a key can be invalidated and still remain operationally useful if dependent tokens, caches, and validation systems continue to trust it. That is why delayed revocation is not a secondary issue but the moment at which compromise turns into persistent access. The practitioner takeaway is to measure trust decay time, not just revocation policy existence.

Public key mismanagement is a lifecycle problem, not a cryptography problem: the article makes clear that outages, audit failures, and token forgery all emerge when keys outlive ownership and monitoring. The named concept here is identity trust decay, where cryptographic trust persists after governance has disappeared. That should push teams to govern keys as living identities with explicit offboarding and validation state.

Hybrid PKI needs one control model across cloud and on-premises: split enforcement creates timing gaps between certificate expiry, revocation publication, and trust consumption. Those gaps are where valid-looking certificates remain accepted longer than intended. Practitioners should align PKI governance, validation cadence, and service dependencies under one operational model.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity trust decay: cryptographic trust outlives governance when signing keys, certificates, and validation state are not retired in sync. That is the point where a valid-looking key stops being a security asset and becomes an exposure path for authentication and availability alike.

The operational lesson for practitioners is that revocation latency matters as much as initial issuance hygiene. If trust removal lags behind compromise detection, the control boundary has already failed, even if the key itself has technically been invalidated.

For practitioners

• Map every public key and certificate to an accountable owner Create a living inventory that records who issues, approves, renews, and revokes each certificate, including keys embedded in applications, cloud services, and third-party integrations.
• Shorten the trust window after key exposure Align revocation workflows, token lifetime, and validation refresh intervals so a compromised key stops being trusted as quickly as possible across dependent services.
• Replace manual tracking with central lifecycle control Move from spreadsheets and ticket reminders to a single system of record that can detect expiry, ownership drift, and orphaned certificates in real time.
• Test hybrid revocation paths under real timing gaps Validate what happens when CRL or OCSP updates lag behind certificate expiry so you can see where revoked certificates may still be accepted.
• Treat signing keys as high-impact identity assets Apply the same governance discipline you would use for privileged access by tracking where signing keys are stored, how they are used, and when they must be retired.

Key takeaways

• Public key mismanagement becomes a business problem when ownership, inventory, and revocation are fragmented across teams and environments.
• The Microsoft token-forgery case shows how one leaked signing key can translate into authentication bypass and residual access.
• The control that matters most is lifecycle governance, especially fast revocation and centralised visibility across hybrid PKI.

Key terms

• Public Key Infrastructure: Public Key Infrastructure is the trust system that issues, manages, and revokes digital certificates used to prove identity. In practice it binds keys to entities and policies, making authentication, encryption, and non-repudiation possible across users, devices, and services.
• Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.
• Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
• Identity Trust Drift: The gap between the access model an organisation thinks it operates and the access reality created by constant change. It shows up when ownership, entitlements, and business context fall out of sync, leaving identity controls technically present but operationally stale.

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.