They often assume PKI is a supporting utility rather than a primary trust control. In Zero Trust designs, certificate-backed identity is central because devices and workloads need continuous verification. If PKI is manual, invisible, or siloed, it cannot support the verification model that Zero Trust depends on.
Why This Matters for Security Teams
PKI is often treated as a backend service, but in zero trust it is the trust anchor that proves who or what is connecting at every step. That shifts certificate issuance, validation, and revocation from plumbing to policy. NIST SP 800-207 Zero Trust Architecture makes continuous verification central to the model, which means weak certificate hygiene or slow revocation undermines the design itself.
Teams usually get this wrong by assuming certificates are “set and forget” assets. In practice, long-lived certificates, inconsistent trust stores, and manual renewal processes create silent trust gaps that are easy to miss until an incident forces a review. The Ultimate Guide to NHIs — Standards is a useful reference point because it frames NHI trust as a lifecycle problem, not a one-time configuration task.
The real risk is operational: if PKI is invisible to security operations, then revocation, certificate policy, and workload identity never become part of access governance. In practice, many security teams discover certificate sprawl only after an expired or over-broad certificate has already interrupted service or enabled unintended access.
How It Works in Practice
Zero Trust only works when certificate-backed identity is managed as an active control surface. That means every device, service, and workload needs a verifiable identity, a bounded lifetime, and a revocation path that security teams can actually execute. For workloads, the strongest pattern is to bind PKI to workload identity rather than to static infrastructure alone, using approaches such as SPIFFE/SPIRE and short-lived credentials that are issued per trust decision. The Guide to SPIFFE and SPIRE is relevant here because it reflects the shift from certificate ownership to cryptographic workload identity.
In operational terms, teams should:
- Automate issuance, renewal, and revocation so certificate expiry does not become an outage trigger.
- Use short-lived certificates where possible so compromise windows are narrower than with static secrets.
- Separate trust domains so one compromised CA or trust store cannot validate everything.
- Log certificate use, validation failures, and revocation events into SIEM and identity telemetry.
- Enforce policy at connection time, not just at enrollment time, so trust can be re-evaluated continuously.
This is especially important for non-human identities, where certificate-backed access often gates API calls, service-to-service traffic, and automation workflows. NHIMG’s research in the State of Non-Human Identity Security shows why this matters: only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which is consistent with weak visibility into credential lifecycle and trust boundaries.
These controls tend to break down in hybrid estates where legacy PKI, cloud-native workloads, and manually issued certificates coexist because revocation and policy enforcement become inconsistent across environments.
Common Variations and Edge Cases
Tighter certificate governance often increases operational overhead, so organisations have to balance trust precision against administrative complexity. That tradeoff is most visible when older applications, external partners, or embedded devices cannot handle short-lived certificates or automated renewal.
Best practice is evolving here. Current guidance suggests treating exceptions as temporary and explicitly bounded, rather than allowing “special case” certificates to become permanent. For example, partner integrations may need controlled trust anchors, but they should still follow documented lifecycle rules and review schedules. Likewise, some environments will keep internal CAs for compatibility, but that should not exempt them from revocation testing or certificate inventory.
Another common mistake is assuming Zero Trust can be achieved by adding TLS everywhere. TLS protects transport, but it does not solve identity governance if certificates are over-scoped, stale, or issued without context. The NIST SP 800-207 Zero Trust Architecture remains the clearest reference for this distinction: verification must be continuous, contextual, and tied to policy, not just encrypted.
Where environments rely on long-lived machine certificates, air-gapped systems, or manual CA operations, the guidance breaks down fastest because trust decisions lag behind real-time access changes.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | PKI-backed service identities are NHI trust assets that must be inventoried and governed. |
| CSA MAESTRO | IAM-01 | MAESTRO covers identity assurance and runtime trust for machine and agent workloads. |
| NIST AI RMF | AI RMF supports governance where autonomous workloads depend on certificate-backed trust. | |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication map directly to certificate-backed Zero Trust verification. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification, which PKI must support as a primary trust control. |
Inventory every certificate-backed NHI, assign ownership, and enforce lifecycle controls from issuance to revocation.
