Should IAM teams treat PKI as part of zero trust architecture?

Why PKI Belongs Inside a Zero Trust Design, Not Beside It

PKI is not a separate trust model that sits outside zero trust. It is one of the mechanisms zero trust relies on to establish identity for workloads, services, devices, and encrypted channels. In practice, certificates often become the proof point that lets policy decisions happen continuously, especially where human login flows do not exist.

That is why zero trust thinking breaks down if PKI is treated as a background utility. When certificate issuance, renewal, and revocation are weak, the architecture may still look modern while trust decisions become stale, opaque, or impossible to enforce at machine speed.

Zero trust architectures assume the verifier can repeatedly test who or what is asking for access, then apply policy before each meaningful interaction. For non-human flows, PKI is often the mechanism that binds an endpoint, workload, or service to a cryptographic identity and supports mutual TLS, attestation, and service-to-service trust. The NIST SP 800-207 Zero Trust Architecture model is built around continuous evaluation, least privilege, and explicit verification, which means certificate-based trust needs operational discipline, not one-time setup.

That operational discipline also includes lifecycle control. PKI is not only about encrypting traffic. It also governs issuance, rotation, renewal windows, revocation, key protection, and the blast radius of compromise. When those controls are missing, the trust fabric can outlive the risk it was meant to manage, especially in environments with short-lived workloads, automation, or service-to-service dependencies. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is useful here because it ties certificate handling to machine identity lifecycle rather than treating PKI as a static infrastructure component.

What Changes for IAM Teams When PKI Is Treated as Zero Trust Infrastructure

For IAM teams, the practical shift is that certificate services become part of identity governance. The team must be able to answer who can issue certificates, what policy determines issuance, how the identity behind the certificate is validated, and how quickly a compromised or expired trust anchor can be retired. That makes PKI a governance problem as much as a cryptography problem.

This is especially true when certificates represent service identities, workload identities, or device identities. A certificate that is easy to mint but hard to trace creates the same kind of exposure as an overprivileged account: it can authenticate successfully while bypassing the intent of the policy model. NHIMG’s Zero Trust Identity Guide is a good complement because it frames zero trust around identity-centric policy rather than network location alone.

IAM teams should also treat revocation and renewal as operational controls, not administrative hygiene. If certificates live too long, are renewed manually, or are never revalidated against current ownership and environment, the trust chain becomes brittle. In that case, zero trust can still be claimed architecturally, but it is not being exercised dynamically in the places that matter most.

What Good PKI Practice Looks Like Under Zero Trust

Good practice is to make PKI observable, policy-driven, and short-lived by default. That means issuance tied to verified identity, tight scope for certificate use, automated renewal where possible, and revocation paths that are fast enough to matter operationally. It also means treating private keys, certificate authorities, and enrollment workflows as high-value security assets.

For practitioners working across machine and workload identity, the most useful mental model is that the certificate is the credential, but the trust system is the control plane. If the control plane cannot discover, rotate, or revoke at the speed the environment changes, then zero trust degrades into a static allow-list with encryption attached. NHIMG’s Guide to SPIFFE and SPIRE is relevant because it shows how workload identity and attestation can make certificate-backed trust more explicit and more automatable.

For teams standardising the platform, a useful implementation signal is whether certificate policy can be enforced consistently across all trust domains, not just one application stack. If different teams issue certificates differently, or if revocation is dependable in some environments but not others, zero trust becomes uneven and hard to audit. The question is not whether PKI exists, but whether it is governed tightly enough to support continuous verification.

Risk and Threat Considerations

When PKI is weakly governed, the main risk is trust persistence after the underlying identity should no longer be trusted. Compromised keys, stale certificates, and delayed revocation can let an attacker or rogue automation continue authenticating even after the original issue has been noticed.

Failure mechanism: Expired, orphaned, or excessively long-lived certificates create a hidden access path that bypasses normal account controls, while poor revocation and renewal processes let that access survive beyond the intended trust window.

Impact: The result can be unauthorized service access, lateral movement, broken segmentation assumptions, and a zero trust posture that appears sound on paper but is brittle in production.

Practitioner Guidance

What to verify: Confirm that certificate issuance, renewal, and revocation are owned, logged, and testable, not just delegated to platform teams. If you cannot prove how quickly trust can be removed, the zero trust claim is weaker than the diagram suggests.

Decision rule: If a certificate authenticates anything with production reach, treat its lifecycle as a governance control with the same seriousness as privileged access review. Short-lived, automated, and inventory-backed certificates are the safer default; manual renewal is an exception condition.

Practitioner takeaway: Zero trust is only as strong as the identity and trust mechanisms that back it, and PKI belongs in that core control set when certificates are used to prove machine or service identity.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do AI agents complicate zero trust architecture for IAM teams?
• Why do NHIs complicate zero trust architecture for IAM teams?
• How should security teams use OAuth as part of a cloud native zero trust architecture?