TL;DR: Certificates and PKI bind names to public keys and let systems prove identity across networks, according to Smallstep, but the hard part is lifecycle governance: issuance, trust distribution, renewal, and revocation. That makes certificate management a machine identity discipline, not just a cryptography topic.
At a glance
What this is: This is a practical explanation of how certificates and PKI work, with the central finding that the real security challenge is not the math but managing certificate lifecycle and trust correctly.
Why it matters: It matters because certificates are the identity layer for code, devices, and workloads, so IAM and NHI teams need to treat PKI as governed identity infrastructure rather than a one-off technical implementation.
Context
Certificates and PKI solve a basic governance problem: how a system can prove who or what it is over an untrusted network. In practice, that means binding a name to a public key so relying parties can verify the claim without sharing secrets directly.
The article frames this as a machine identity problem as much as a cryptography problem. Once certificates are used for TLS, internal services, and device identity, the programme question becomes lifecycle control, not just key generation. For teams building internal trust fabrics, the certificate lifecycle is the control plane.
Use Non-Human Identities as the broader framing when certificates are part of a wider machine identity estate. That is the right lens for service accounts, workload identities, tokens, and certificates that need shared governance.
Key questions
Q: What breaks when certificate lifecycle management is still manual?
A: Manual certificate management breaks at the point where expiry, ownership, and renewal do not line up. Services fail when a certificate expires, teams lose visibility when ownership is fragmented, and outage response becomes reactive instead of governed. The result is avoidable downtime, repeated exceptions, and an estate that grows faster than the people managing it.
Q: Why do trust stores create identity risk in PKI?
A: Trust stores define which certificate authorities can speak for your systems, so every extra root expands the set of parties that can issue accepted identity claims. If you trust too broadly, a compromised or negligent issuer can impersonate legitimate services. Narrow trust stores reduce that blast radius and make policy enforcement more meaningful.
Q: How should security teams govern certificate trust for high-traffic services?
A: They should treat certificates as workload identities and govern them through a lifecycle model that covers issuance, validation, revocation, and retirement. For high-traffic services, that means assigning clear ownership, checking revocation status in production, and making sure validation failures are visible before they become outages or trust gaps.
Q: What is the difference between public Web PKI and internal PKI?
A: Public Web PKI is designed for broad internet trust and depends on many external certificate authorities, while internal PKI is scoped to your own environment and can be tailored to your naming, lifetime, and trust requirements. Internal PKI is usually easier to automate and govern, because you control the policy boundary.
Technical breakdown
How certificates bind names to public keys
A certificate is a signed data structure that pairs a public key with an identity claim. The issuer, usually a certificate authority, signs the certificate to vouch that the subject controls the corresponding private key. Relying parties then validate that signature and chain of trust before they accept the identity claim. This is what makes public key infrastructure useful: it turns cryptographic possession of a private key into a verifiable identity assertion. The operational consequence is that trust depends on both the certificate contents and the issuer hierarchy, not on the key alone. Practical implication: model certificate issuance as an identity control, not a transport setting. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: model certificate issuance as an identity control, not a transport setting.
Why trust stores and CA governance matter
PKI is only as strong as the trust anchors a relying party accepts. If a client trusts too many certificate authorities, or fails to enforce policy checks such as certificate transparency or name restrictions, then a compromised or negligent issuer can mint certificates that look legitimate. That is why public Web PKI and internal PKI have very different governance needs. Internal trust should be scoped to the smallest feasible set of roots, with separate trust stores where possible, so the blast radius of a compromised issuer stays limited. Practical implication: constrain which issuers your systems will accept before you worry about advanced certificate features. Read Guide to SPIFFE and SPIRE.
Practical implication: constrain which issuers your systems will accept before you worry about advanced certificate features.
Why certificate lifecycle is the hard part
The article is explicit that issuance is the easy part and lifecycle is the difficult part. Certificates expire, private keys need protection, revocation is messy, and renewal often needs automation because manual handling does not scale. Short-lived certificates reduce the need for heavyweight revocation processes, while automated renewal reduces the chance that systems fail open or go dark when credentials lapse. The control issue is not whether certificates can be created, but whether the organisation can continuously issue, distribute, rotate, and retire them without interrupting service. Practical implication: treat renewal and revocation as first-class identity operations.
Practical implication: treat renewal and revocation as first-class identity operations.
Threat narrative
Attacker objective: The objective is to impersonate trusted systems or domains so encrypted traffic, service access, or identity assertions can be abused without triggering obvious authentication failure.
- Entry occurs when an attacker gains or fabricates trust through a compromised certificate authority, stolen signing key, or improperly distributed root certificate.
- Escalation follows when the false certificate is accepted by relying parties that do not sufficiently constrain trust or validate policy requirements.
- Impact occurs when systems accept illegitimate peers, allowing interception, impersonation, or unauthorized access through the trusted channel.
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
Certificate lifecycle, not certificate math, is the real governance problem. The article shows that binding names to keys is conceptually simple, while renewal, revocation, trust distribution, and root management are where programmes fail in practice. That is why certificate programmes belong inside identity governance rather than being left to ad hoc platform ownership. Practitioners should think in terms of lifecycle control first.
Trust stores create identity blast radius. Every additional trusted root expands who can successfully assert identity to your systems. When organisations allow broad trust without tight issuer scoping, they create a policy problem that cryptography alone cannot solve. The right control question is not whether certificates exist, but which issuers are allowed to speak for which systems and domains. Practitioners should review trust store scope as an identity boundary.
Short-lived certificates are a governance pattern, not just an operational convenience. The article points out that passive revocation and automated renewal are often better than relying on delayed revocation checks. That shifts the control objective from proving a certificate was later revoked to reducing the time any one credential remains usable. Practitioners should align certificate lifetime with the operational tolerance for exposure.
Internal PKI is where certificate discipline becomes a machine identity strategy. The article makes the case that internal use cases need different trust, naming, and automation assumptions than public web traffic. That is the point where certificates stop being a web security detail and become part of workload identity architecture. Practitioners should govern internal PKI as a core identity service, not a niche cryptography project.
From our research library:
- 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Certificate governance is now a machine identity programme issue. Once certificates are used to identify services, devices, and code, the programme boundary shifts from network security to identity lifecycle management. That means ownership, renewal, revocation, and issuer scope all need the same governance discipline that teams apply to other non-human credentials.
Trust boundary design matters more than certificate volume. A small set of tightly governed trust anchors is more defensible than a broad trust store that accepts too many issuers by default. Practitioners should expect certificate policy to become part of Zero Trust design, not a separate cryptography workstream.
Short-lived credentials reduce exposure windows, but only when automation supports them. Without automated renewal and distribution, shorter lifetimes just move failure earlier in the lifecycle. The practical lesson is to build certificate handling into machine identity lifecycle operations, not leave it as a manual edge case.
For practitioners
- Define certificate ownership and lifecycle boundaries Assign clear ownership for issuance, renewal, revocation, and trust store maintenance so certificate operations do not drift across platform teams, security teams, and application owners.
- Minimise trust store scope Limit each environment to the smallest feasible set of root certificates and separate internal trust from public Web PKI where the use case allows it.
- Automate renewal and rotation Use automation for certificate renewal, replacement, and retirement so expiry does not depend on manual intervention or brittle runbooks.
- Prefer short-lived certificates Shorten certificate lifetime where service continuity permits it, because reducing validity windows lowers the exposure created by compromise or mis-issuance.
- Review relying party enforcement Verify that clients actually enforce name checks, trust chain validation, and issuer policy rather than assuming the controls are present because they exist on paper.
Key takeaways
- Certificates and PKI solve an identity problem by binding names to public keys, but the operational risk sits in trust distribution and lifecycle governance.
- The article’s core lesson is that certificate security fails most often at renewal, revocation, and trust-store scope rather than at the cryptography itself.
- For IAM and NHI teams, internal PKI should be governed as a machine identity service with automation, constrained trust, and explicit ownership.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Guide to SPIFFE and SPIRE · Ultimate Guide to NHIs: What are Non-Human Identities
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 addresses the attack and risk surface, while NIST SP 800-57 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Private key exposure and misplaced trust anchors turn certificate material into reusable identity credentials. |
| NHI-04 — Insecure Authentication | Certificates are the authentication mechanism for machines and services in this article. | |
| NHI-07 — Long-Lived Secrets | The article argues for short-lived certificates and automated renewal to reduce exposure windows. | |
| Recommendation — Scan certificate stores and private-key handling paths for leakage, then revoke exposed material immediately. Validate certificate-based authentication paths and reject configurations that skip path validation or trust checks. Shorten certificate lifetimes where possible and automate renewal before expiry. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article centres on key and certificate lifecycle governance, which is the core of NIST SP 800-57. |
| Recommendation — Apply lifecycle governance to certificate keys from generation through rotation, compromise recovery, and destruction. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Certificate trust determines which systems are authorised to present valid identity claims. |
| Recommendation — Restrict certificate trust and issuer acceptance to the minimum set needed for each environment. | ||
Key terms
- Certificate Authority: A Certificate Authority is a trusted organisation that issues and signs digital certificates binding identities to public keys. Defenders rely on it to establish trust for TLS and other certificate-based systems, while attackers target weak issuance processes, stolen signing keys, or mis-issuance to impersonate services and users.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Trust Store: A set of certificates that a system accepts as trusted for authentication or encryption decisions. If the store is stale or poorly maintained, systems may continue accepting identities that should no longer be valid, which turns trust management into an operational security risk.
- 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.
Deepen your knowledge
NHI governance, machine identity security, and secrets management 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.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org