TL;DR: PKI underpins digital certificates, trust chains, encryption, revocation, and authentication across organisations, devices, and services, but implementation still breaks down when key management, certificate lifecycle control, and audit discipline are weak, according to GlobalSign. The core issue is not PKI theory; it is whether identity teams can govern certificate trust at scale without creating hidden operational risk.
At a glance
What this is: This is a PKI governance article arguing that digital identity trust still depends on certificate lifecycle control, key management and revocation discipline.
Why it matters: It matters because PKI now underpins human, machine and service trust paths, so IAM and security teams need certificate governance that scales with identity sprawl.
Context
PKI is the certificate-based trust system that lets organisations verify identities, encrypt data in transit and revoke trust when keys or certificates are compromised. The article treats PKI as a governance problem, not just a cryptography problem, because the control value depends on how keys, certificate requests, renewals and revocations are managed across the estate.
The identity connection is broad: certificates are used for organisations, people, servers, websites, IoT devices and DevOps pipelines. That makes PKI part of both identity governance and operational security, because a weak lifecycle process can undermine authentication, confidentiality and non-repudiation even when the underlying cryptography is sound.
Key questions
Q: How should teams govern certificate lifecycles in a PKI programme?
A: Treat certificates as governed identity assets with named ownership, expiry tracking, and explicit revocation authority. The practical test is whether every certificate has a system owner, a renewal path, and a documented response for key compromise or role change. Inventory without ownership is only partial visibility.
Q: Why do PKI environments become risky when revocation is weak?
A: Weak revocation lets a compromised certificate continue to represent trust after the underlying key or identity should have been withdrawn. That creates a gap between the technical state of compromise and the operational state seen by relying systems, which is why CRL and OCSP checking need to be dependable, not optional.
Q: What breaks when certificate inventory is incomplete?
A: Incomplete inventory breaks ownership, renewal planning, and revocation response. Hidden certificates can expire without warning, remain deployed after service changes, or become impossible to audit during incidents. In practice, incomplete visibility turns certificate management into a discovery problem that teams only notice when users see failures or browser warnings.
Q: Should organisations centralise PKI governance or keep it local to teams?
A: Centralisation usually improves visibility, policy consistency and auditability, but only if local teams still retain clear responsibility for the systems that consume certificates. The best model is central policy with distributed operational ownership, so the trust fabric is governed once and implemented where the certificates actually run.
Technical breakdown
How certificate trust chains govern identity validation
PKI works by binding an identity to a public key through a digital certificate issued by a certificate authority. That trust is only as strong as the issuing chain, the registration checks behind certificate issuance and the ability to validate whether a certificate is still trusted. Root and intermediate authorities create the hierarchy, while certificate status checks such as CRL and OCSP determine whether a certificate should continue to be accepted. In practice, the system is less about encryption alone and more about whether trust can be asserted, maintained and withdrawn reliably across many relying parties.
Practical implication: map every certificate trust path to an owner, issuer and revocation method before it enters production.
Why key and certificate lifecycle control is the real failure point
The article shows that PKI failures usually come from lifecycle breakdowns rather than from the cryptographic primitive itself. Certificate requests, renewal, expiry, suspension and revocation all create governance points where stale trust can persist if inventory is incomplete or approval is weak. When private keys are compromised, revocation becomes the decisive control, but that only works if the organisation can find the affected certificate, update the status promptly and ensure dependent systems check it correctly. Without that discipline, certificates outlive the trust they were meant to represent.
Practical implication: treat certificate inventory, expiry monitoring and revocation handling as lifecycle controls, not administrative tasks.
How PKI extends into DevOps, IoT and API-driven automation
PKI is no longer confined to browser TLS. The article ties it to DevOps, IoT identity and automated certificate provisioning, which means certificate governance now sits inside pipelines, devices and service integrations. That expands the attack surface because automation can create scale without creating assurance if certificate issuance, renewal and removal are not governed centrally. ACME-style automation improves speed, but it also increases the need for policy, inventory and exception handling so that trust does not become invisible. In other words, automation changes the operating model, not the need for governance.
Practical implication: place automated certificate issuance behind policy, inventory and renewal oversight before expanding it across pipelines and devices.
Threat narrative
Attacker objective: The objective is to persistently impersonate a trusted identity and exploit accepted certificate-based trust.
- Entry occurs when a certificate, private key or issuance workflow is exposed or mismanaged, allowing an attacker or faulty system to present untrusted identity as valid.
- Credential access follows when the private key or certificate material is reused, copied or left active beyond its intended trust period.
- Escalation happens when relying systems continue to accept the certificate because revocation, expiry or status checking is weak or delayed.
- Impact is achieved when trust persists after compromise, enabling impersonation, encrypted traffic abuse or unauthorized access to systems and data.
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.
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 is an identity lifecycle problem, not a cryptography problem. The article correctly places trust at the centre of digital identity, but the operational failure mode is not weak math. It is weak ownership of issuance, renewal, revocation and expiry across a growing certificate estate. Practitioners should read PKI as a governed identity subsystem, not a standalone security utility.
Certificate trust debt is the hidden risk in mature environments. Certificates often remain valid longer than the teams that issued them expect, especially when inventories are incomplete or revocation checks are inconsistent. That creates trust debt, where the organisation keeps inheriting assurance from a certificate whose operational context has already changed. The practical conclusion is that lifecycle visibility matters more than certificate volume.
Managed PKI becomes a control plane only when it reduces blind trust in automation. The article points toward centralisation and automation, but those only help if they preserve line of sight into who requested what, where it was deployed and when it should disappear. Otherwise, automation accelerates certificate sprawl just as efficiently as it accelerates deployment. Teams should measure whether automation improves governance, not just speed.
PKI control plane sprawl: certificate governance now spans browsers, APIs, IoT, DevOps pipelines and internal services. That cross-domain spread makes PKI one of the few identity controls that touches human, machine and service trust at once. The implication is that identity programmes can no longer isolate certificate management inside infrastructure teams; it belongs in enterprise identity governance.
Revocation is the decisive trust boundary, but only if organisations treat it as an operational dependency. The article’s CRL and OCSP discussion shows that revocation is what turns compromise into containment. When status checking is inconsistent, the organisation has a trust gap even if key generation and issuance were sound. Practitioners should align revocation reliability with the systems that actually consume certificates.
What this signals
PKI now functions as a cross-domain identity control plane. Once certificates cover browsers, APIs, devices and DevOps workflows, the programme can no longer treat them as a narrow infrastructure concern. Identity leaders should fold certificate lifecycle into the same governance model used for other high-trust credentials, because the failure mode is usually inconsistency across ownership, inventory and revocation.
Certificate trust debt is the programme-level risk to watch. When renewal, expiry and revocation are not continuously visible, the organisation accumulates hidden trust dependencies that look stable until they fail. The practical signal is not just certificate volume, but whether the estate can prove that every certificate is owned, monitored and removable on demand.
For practitioners
- Define certificate ownership by service and system Assign each certificate to a named business or technical owner, with explicit accountability for issuance, renewal, revocation and retirement. Shared ownership is where expired certificates and orphaned trust paths usually persist.
- Inventory every certificate and private key path Maintain a live inventory that covers servers, websites, devices, pipelines and internal services, including issuer, expiry, renewal method and revocation status. If a certificate is not in inventory, it is not governed.
- Automate renewal with policy guardrails Use automation to reduce manual renewal failures, but require policy approval for high-risk certificates, short lifetimes and production trust anchors. Automation should shorten exposure windows, not hide them.
- Test revocation behavior in dependent systems Validate that the applications and browsers that rely on your certificates actually check CRL or OCSP status and fail closed when appropriate. Revocation only works when the consumers of trust enforce it.
- Review DevOps and IoT certificate flows together Include CI/CD pipelines, device fleets and service-to-service certificates in the same governance model so renewal, replacement and retirement follow one policy. Separate control planes create blind spots and duplicate trust paths.
Key takeaways
- PKI remains central to digital identity trust, but the real control gap is governance over certificate lifecycle and key ownership.
- The article links PKI to organisations, people, devices, websites and DevOps pipelines, which means certificate sprawl now affects identity programmes broadly.
- Teams reduce risk when they treat inventory, renewal and revocation as operational controls that decide whether trust is still valid.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The article repeatedly centers certificate expiry, renewal and lifecycle control. |
| NHI-01 — Improper Offboarding | Revocation and retirement are essential when certificates or keys must be removed from service. | |
| Recommendation — Track certificate lifetime and renewal windows so trust does not outlive its intended scope. Remove certificates and keys from use as soon as the owning service, device or workflow is retired. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate and key lifecycle management maps directly to authenticator handling. |
| AC-6 — Least Privilege | Certificate-driven access should be constrained to the minimum trust scope needed. | |
| Recommendation — Apply authenticator management to rotation, revocation and replacement of certificate credentials. Limit certificate-based access to the smallest trust scope required for each service or device. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Private key or certificate compromise is the enabling condition behind trust abuse. |
| Recommendation — Hunt for exposed certificate material and revoke any credential paths that enable impersonation. | ||
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 Authority Services: Certificate Authority Services are the trust services that issue and manage digital certificates for users, applications, and machines. They anchor encrypted communication by proving identity and supporting certificate lifecycle controls such as issuance, renewal, revocation, and validation across enterprise systems.
- 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.
- Online Certificate Status Protocol: Online Certificate Status Protocol is a per-certificate revocation check that asks the issuing authority for the current status of one certificate. It improves freshness over list-based checking, but it introduces responder dependency and privacy exposure because each query reveals the certificate being validated.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org