What breaks when Zero Trust is built without PKI?

Where Zero Trust depends on a cryptographic trust anchor

zero trust only works as a continuous verification model when the trust decision is anchored in something stronger than network location or a sticky session. PKI gives that anchor by binding identities to certificates, enabling mutual TLS, service attestation, device trust and revocation. Without it, the architecture can still use policy, but it loses a durable cryptographic basis for deciding who or what is trustworthy.

That loss matters because Zero Trust is meant to replace ambient trust with repeatable proof. If the only signals left are IP range, browser session, device posture or login freshness, the system becomes easier to game and harder to standardise across users, workloads and services.

When teams are designing that trust anchor for workloads, the operational difference is clearest in SPIFFE and SPIRE, which turns workload identity into something a policy engine can verify on every request.

What degrades first when PKI is missing

The first thing to degrade is consistency. Different applications start compensating with different checks, so one service trusts a session token, another trusts network path, and a third trusts a human-approved login that happened hours earlier. That fragmentation undermines one of Zero Trust's core promises: the same subject should be evaluated the same way wherever it appears.

PKI also supports lifecycle control. Certificate issuance, rotation and revocation create a bounded trust window. Without that lifecycle, stale credentials and long-lived trust paths linger, and the organisation has fewer strong signals for deciding when access should expire or be re-established.

For machine credentials and certificates specifically, the lifecycle problem is why machine identity and certificate lifecycle management matters so much in Zero Trust programmes.

At the architectural level, NIST Cybersecurity Framework 2.0 is useful here because the breakdown shows up across govern, protect and identify functions, not just in one authentication control.

How attackers and failure modes exploit the gap

When PKI is absent, defenders often substitute weaker trust shortcuts, and those shortcuts create attack surface. A stolen session, a replayed token, a mis-scoped shared secret or a trusted network segment can become enough to move laterally or impersonate a service. The problem is not that all of these controls are useless, it is that none of them gives the same cryptographic assurance as certificate-based trust.

The failure mode is especially dangerous in service-to-service environments. Once verification depends on environment, perimeter or prior state, an attacker who crosses the first boundary can often reuse that trust across multiple systems. That is why Zero Trust without PKI tends to drift back toward perimeter thinking even when the policy language still says "verify every request."

For the trust and transport layer itself, NIST SP 800-207 Zero Trust Architecture remains the canonical reference for why per-request verification and explicit trust decisions matter. For cryptographic lifecycle discipline, NIST SP 800-57 Key Management is the better lens for understanding why the underlying keys and certificates must be managed as a lifecycle control, not a one-time setup.

Risk and Threat Considerations

Without PKI, Zero Trust usually fails by substitution, not by instant collapse. Teams compensate with sessions, network controls or manual approvals, and those substitutes are easier to bypass, harder to revoke and much harder to audit consistently.

Failure mechanism: Trust shifts from verifiable cryptographic proof to weaker state such as location, token age, device reputation or user behaviour, creating reusable trust paths after the first approval.

Impact: Attackers who obtain a session, token or foothold can often extend access more easily, while defenders lose a reliable way to prove that each request was authenticated and authorised under the same standard.

Practitioner Guidance

What to verify: Confirm that every major trust decision has a cryptographic identity primitive behind it, especially for service-to-service and device-to-service traffic. If the answer is "we trust the network" or "we trust the session," the Zero Trust model is already weakening.

Decision rule: If a workload can reach another workload on the basis of a long-lived secret, shared perimeter or static allowlist, treat that as a migration gap and prioritise certificate-backed identity before broadening policy logic.

Practitioner takeaway: Zero Trust without PKI is usually not impossible, but it is materially less defensible, because the model stops proving trust and starts assuming it.

Related resources from NHI Mgmt Group

• What breaks when IoT security is built without a PKI-based trust model?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• Why do NHIs complicate zero trust and least privilege efforts?