PKI governance is still the backbone of digital identity trust

At a glance

What this is: This is a PKI governance primer showing how certificates, trust chains, revocation, and lifecycle controls support digital identity security.

Why it matters: It matters because PKI now sits underneath human, workload, and device trust, so IAM, NHI, and PAM teams need consistent lifecycle and revocation control.

👉 Read GlobalSign's full guide to PKI management and digital identity trust

Context

Public Key Infrastructure, or PKI, is the trust layer that lets systems prove identity and protect data in transit through digital certificates and asymmetric cryptography. In identity programmes, that makes PKI a control plane for certificates attached to people, devices, applications, and services, not just a back-end encryption mechanism.

The governance problem is that PKI only works when certificate issuance, renewal, revocation, and key custody are managed continuously. Once certificate inventory fragments or private keys are mishandled, identity trust degrades quietly, which is why PKI belongs in IAM, NHI, and lifecycle governance discussions rather than in a narrow cryptography silo.

For organisations trying to mature certificate operations, the operational question is no longer whether PKI is useful. It is whether the trust chain, certificate status checking, and audit discipline are strong enough to support modern identity sprawl without depending on manual intervention.

Key questions

Q: How should security teams govern certificate lifecycle in PKI environments?

A: Security teams should treat certificates as governed identities with named owners, renewal triggers, and revocation criteria. The priority is not only preventing expiry outages but ensuring certificates are issued, rotated, and withdrawn as part of a controlled lifecycle. That means PKI belongs in IAM and NHI governance, with clear accountability for every certificate-bearing service.

Q: Why do revoked certificates still create security risk?

A: Revoked certificates remain risky because trust can persist in caches, misconfigured validation paths, or downstream systems that do not check status properly. A certificate that has not expired is not automatically safe, and a revoked one is only removed from the trust chain if CRL or OCSP checks are consistently enforced.

Q: What breaks when certificate ownership is unclear?

A: When ownership is unclear, renewal, revocation, and incident response all slow down. Teams cannot reliably decide who should approve changes, who should rotate keys, or who should retire the certificate. The result is certificate drift, longer exposure windows, and trust relationships that outlive the systems they were meant to protect.

Q: How do organisations reduce manual PKI mistakes without losing control?

A: Organisations reduce manual mistakes by automating issuance and renewal while keeping policy, inventory, and revocation decisions under governance. Automation should remove repetitive work, not accountability. The best outcome is central visibility into certificates with explicit exceptions for high-risk trust relationships.

Technical breakdown

How PKI establishes trust with public and private keys

PKI creates trust by pairing a public key with a private key and binding that pair to an identity through a digital certificate. The certificate is issued by a certificate authority after an identity check, often via a registration authority, so a verifier can rely on the binding rather than on the raw key alone. In practice, the system depends on correct issuance, valid certificate chains, and matching keys at both ends of the exchange. If any of those steps fail, the cryptography may still function but the identity trust model does not. This is why PKI is an identity governance control, not just an encryption tool.

Practical implication: inventory every certificate-bearing identity and verify that issuance, chain validation, and ownership are defined for each class of asset.

Why revocation and status checking are the real control point

Certificate revocation is where PKI governance becomes operational. Certificate Revocation Lists record certificates that have been invalidated before expiry, while OCSP gives near-real-time status checks for a certificate request. Both exist because certificate lifetime alone is not enough when keys are compromised, ownership changes, or trust must be withdrawn immediately. A certificate that is technically unexpired can still be unsafe. That makes revocation handling part of identity lifecycle management for machines, services, and external trust relationships. Organisations that treat certificates as static artefacts rather than revocable identities leave a gap between policy and enforcement.

Practical implication: connect revocation decisions to asset ownership and lifecycle events, not only to expiry dates.

Managed PKI and certificate automation reduce lifecycle failure

Managed PKI centralises certificate inventory and automates issuance and renewal through APIs, which matters because manual certificate handling is where expiry outages and misissued credentials tend to accumulate. In DevOps and IoT environments, certificate volume and churn make ad hoc administration unrealistic. Automation does not remove governance, though. It shifts the control point to policy, inventory accuracy, and delegated trust boundaries. That is especially important for NHI programmes, where service identities and workloads often outnumber human identities and can outlive the teams that created them.

Practical implication: automate certificate provisioning only after you have ownership metadata, renewal triggers, and revocation workflows under control.

Threat narrative

Attacker objective: The objective is to inherit trusted identity status and use that trust to access systems or data that would otherwise reject the actor.

1. Entry occurs when an attacker or error compromises certificate material, misuses a certificate authority relationship, or exploits weak trust validation in a PKI workflow.
2. Escalation follows when the compromised key or certificate lets the actor impersonate a trusted organisation, service, or device and move through protected channels.
3. Impact is achieved when communications, documents, or web services accept the forged trust relationship and expose data or allow unauthorised transactions.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

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

NHI Mgmt Group analysis

PKI is now identity governance infrastructure, not a standalone security layer. The article correctly frames certificates as the basis for trust, but the operational reality is broader: PKI governs how machines, services, and applications prove who they are at runtime. That makes certificate lifecycle control part of identity architecture, alongside IAM, NHI governance, and access review discipline. Practitioners should treat certificate inventory as identity inventory.

Certificate revocation is the governance boundary that most programmes underuse. The article explains CRL and OCSP, but the deeper issue is that many organisations still treat certificates as valid until expiry rather than valid until revoked. That assumption fails as soon as private keys are exposed, ownership changes, or a service is retired. The implication is that certificate status must be tied to lifecycle events, not calendar dates.

Managed PKI only works when ownership metadata is accurate. Centralisation and automation reduce manual error, but they do not solve the underlying problem of who owns each certificate, workload, or device identity. When ownership is unclear, renewal and revocation decisions stall, and the trust chain becomes brittle. The practitioner takeaway is to align PKI with accountable identity ownership, not just with tooling consolidation.

PKI exposes the same lifecycle problem seen across NHI governance. Certificates are non-human identities in practice because they represent systems, services, and device trust without human interaction. That means the same governance failures recur: orphaned credentials, weak revocation discipline, and fragmented oversight. The field should stop treating certificate management as a special case and fold it into standard NHI lifecycle control.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That gap makes certificate and secret lifecycle governance a shared problem, which is why the same research is useful context for PKI and workload identity programmes.

What this signals

Certificate sprawl will increasingly behave like NHI sprawl. As organisations automate more of their trust infrastructure, certificate inventory becomes a live identity surface rather than a static cryptography record. That means renewal, revocation, and ownership data need to be handled with the same discipline as service account governance and workload identity.

With 27 days as the average estimated time to remediate a leaked secret according to The State of Secrets in AppSec, the lesson for PKI teams is simple: slow lifecycle response becomes a trust problem, not just an operational inconvenience.

The next maturity step is not more certificates or more automation in isolation. It is a programme view that ties PKI, NHI lifecycle, and audit evidence together so trust can be proven, revoked, and reassigned without manual detective work.

For practitioners

• Map certificate ownership to identity inventory Create a complete inventory of certificates, issuing authorities, owning teams, renewal dates, and revocation paths so each certificate is tied to an accountable service or business process.
• Automate renewal with policy guardrails Use API-driven automation for certificate renewal only after defining approval rules, service ownership, and exception handling for high-risk certificates.
• Test revocation workflows under change events Validate that CRL and OCSP checks work when keys are compromised, services are decommissioned, or third-party trust relationships change.
• Fold PKI into NHI lifecycle reviews Include certificates in joiner-mover-leaver, offboarding, and recertification processes so machine trust does not outlive the system or team that owns it.

Key takeaways

• PKI is an identity governance control because it determines who and what can prove trust at runtime.
• Revocation and ownership are the weak points that separate secure certificate systems from brittle ones.
• Automation helps only when certificate inventory, lifecycle, and accountability are already well defined.

Key terms

• Public Key Infrastructure: Public Key Infrastructure is the system that issues, manages, and validates digital certificates so systems can prove identity and exchange data securely. In practice, it is a trust framework built around certificate authorities, registration checks, key pairs, and revocation status rather than encryption alone.
• Certificate Revocation: Certificate revocation is the process of invalidating a certificate before its expiry date when trust can no longer be maintained. It matters because a valid-looking certificate can still be unsafe if a private key is compromised, ownership changes, or the identity behind it no longer deserves trust.
• Online Certificate Status Protocol: Online Certificate Status Protocol is a real-time method for checking whether a certificate is valid, revoked, or unknown. It helps relying parties verify trust at the moment of use, which makes it an operational control rather than a historical record.
• Certificate Signing Request: A Certificate Signing Request is the signed request an organisation submits to obtain a digital certificate. It contains the public key and identity details that the certificate authority or registration authority uses to verify the requester before issuance.

What's in the full article

GlobalSign's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanations of how CSR, CA, and RA flows work in practice.
• Detailed breakdowns of CRL and OCSP handling for certificate status checks.
• Examples of PKI use across SSL/TLS, S/MIME, IoT, and DevOps environments.
• Best-practice guidance for managed PKI and certificate automation.

👉 The full GlobalSign post covers PKI components, revocation handling, and implementation guidance.

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 identity security programme, it is worth exploring.