Centralise PKI first or in parallel, because Zero Trust depends on accurate, current trust decisions. If certificate state is fragmented, service identity and mutual TLS controls will rest on stale assumptions. Central governance makes the trust backbone visible enough for Zero Trust to work as designed.
Why PKI Timing Matters in a Zero Trust Programme
zero trust treats identity and trust as dynamic signals, not one-time setup work. That makes PKI a foundational dependency rather than a later optimisation. If certificate issuance, renewal, revocation, and trust store management are fragmented, Zero Trust policy decisions can be based on outdated certificate state, stale identity bindings, or inconsistent trust anchors.
Centralising PKI first, or at least in parallel, gives the programme a single source of truth for certificate policy, lifecycle, and trust distribution. That matters most where mutual TLS, service-to-service authentication, and workload identity all rely on certificates as the proofing and binding layer.
When PKI is centralised early, teams can align certificate lifecycle controls with a Zero Trust architecture instead of trying to retrofit governance after services are already depending on local CAs, ad hoc renewal scripts, or embedded trust decisions.
What “Centralise PKI” Means in Practice
Centralising PKI does not mean every certificate request must become manually gated. It means the organisation governs certificate policy, issuance authority, renewal paths, revocation handling, and trust anchor distribution through one accountable operating model. That model may still federate to domain-specific or platform-specific issuers, but the rules and visibility should be central.
This is especially important when the environment includes machine identity and certificate lifecycle management, because the failure mode is usually not a single expired certificate. It is certificate sprawl, uneven ownership, and a growing set of systems that trust different roots, policies, or renewal assumptions.
For Zero Trust, the practical requirement is that certificate state must be auditable, current, and enforceable across the estate. A central PKI model makes it possible to see which services are authenticating with which certificates, which trust bundles are active, and where renewal or revocation could break access paths.
How PKI Supports Zero Trust Controls
Zero Trust depends on continuous verification, narrow trust boundaries, and policy that can respond to current context. PKI supports those goals by giving the architecture a cryptographic basis for mutual authentication, service identity, and trust propagation. Without that basis, Zero Trust controls often degrade into policy overlays on top of weak or inconsistent identity evidence.
That is why many organisations pair PKI centralisation with workload identity patterns such as SPIFFE and SPIRE, where the trust bundle, identity issuance, and workload authentication flow are designed for east-west traffic and short-lived credentials. In practice, this gives Zero Trust a cleaner control plane for service-to-service trust than unmanaged certificates spread across teams.
The architecture also aligns with the core Zero Trust model in NIST SP 800-207 Zero Trust Architecture, which assumes breach and requires policy to be applied based on current signals. PKI centralisation helps those signals stay trustworthy because identity assertions and trust anchors can be governed consistently rather than left to local implementation drift.
Risk and Threat Considerations
Decentralised PKI creates a trust problem as much as an operational one. If teams manage their own roots, renewal schedules, or revocation processes, Zero Trust decisions can silently inherit stale certificates, orphaned trust bundles, and uneven enforcement of service identity.
Failure mechanism: Attackers and accidental failures both benefit from certificate fragmentation, because inconsistent trust state makes it harder to detect invalid certificates, retire compromised issuers, or enforce rapid trust changes across the environment.
Impact: The result can be authentication failure, unexpected service outage, or worse, acceptance of a certificate that should no longer be trusted. In a Zero Trust programme, that weakens the very assumption that access decisions reflect current, verified identity.
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-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PKI depends on certificate lifecycle control and revocation hygiene. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Service-to-service and workload PKI enables non-organizational authentication. | |
| Recommendation — Centralize certificate lifecycle management and rotation under IA-5. Use IA-9 to govern machine and service authentication with certificates. | ||
| NIST Zero Trust (SP 800-207) | 3.2 — Zero Trust Architecture Core Principles | The question is explicitly about sequencing PKI with Zero Trust adoption. |
| Recommendation — Align PKI governance before or alongside Zero Trust policy enforcement. | ||
| NIST SP 800-57 | 3 — Key Management Lifecycle | PKI centralisation hinges on controlled key and certificate lifecycle handling. |
| Recommendation — Apply key lifecycle governance to issuance, rotation, and revocation. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Certificates and private keys become risky when lifecycle control lags. |
| Recommendation — Eliminate long-lived certificates and rotate identity material on schedule. | ||
Practitioner Guidance
What to prioritise: Establish a central certificate authority model, a single inventory of trust anchors, and a clear owner for revocation and renewal policy before extending Zero Trust enforcement to critical east-west paths.
What to verify: Confirm that service and workload certificates can be rotated without manual exceptions, that revocation is operationally tested, and that no production traffic depends on undocumented local CAs or embedded trust bundles.
Decision rule: If a certificate can authenticate to production systems, treat its lifecycle and trust distribution as part of Zero Trust readiness, not as a separate infrastructure cleanup task.
Practitioner takeaway: Zero Trust works best when the trust fabric is already governed, observable, and current; if PKI is fragmented, the architecture may look modern while still relying on stale trust decisions underneath.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org