Without strong identity and PKI controls, Zero Trust becomes a policy statement rather than an enforced architecture. Access requests cannot be reliably authenticated, encrypted, or tied to trustworthy identities, so internal and external threats can still move through the environment. That weakens control over sensitive transactions and undermines the promise of continuous verification.
Why Zero Trust Fails Without Identity and PKI
zero trust depends on trustworthy proof, not just policy language. If identity cannot be authenticated with confidence and encryption cannot be anchored in reliable certificate and key management, the architecture loses the ability to make per-request decisions that are actually enforceable. The result is a framework that looks restrictive on paper but still leaks trust across users, devices, workloads, and sessions.
That is why NIST SP 800-207 Zero Trust Architecture matters here, because its core model assumes strong verification at every access decision. For the identity side of that foundation, Zero Trust Identity Guide shows how identity-centric policy turns the architecture from a slogan into an operational control plane.
PKI is the other half of the problem. Without certificates, signing keys, and lifecycle controls that can be trusted, access requests and service-to-service connections lose cryptographic assurance. That is especially important when organisations rely on machine or workload connectivity, because the system may still route traffic while no longer being able to prove who or what is requesting access.
What Breaks in the Access Decision Path
The failure is usually not an immediate outage. It is a gradual collapse in decision quality. Authentication becomes weak or inconsistent, sessions are easier to forge or replay, and policy engines start making decisions on incomplete signals. At that point, Zero Trust can still segment networks, but it cannot reliably distinguish a legitimate request from a spoofed or stolen one.
Strong certificate practice is therefore not a back-office detail. CA/Browser Forum baseline requirements and the broader Machine Identity, PKI and Certificate Lifecycle Guide both point to the same operational reality: if certificates expire, keys are not protected, or rotation is not automated, the trust chain degrades faster than most teams expect.
That matters for both human and non-human access. When an organisation cannot reliably validate the principal, every downstream rule, from least privilege to continuous evaluation, becomes easier to bypass through stolen credentials, misissued certificates, or over-trusted internal paths.
Why Continuous Verification Needs Trustworthy Identity Signals
Zero Trust is often described as “never trust, always verify”, but verification only works when the signals are good. If identity proofing is weak, certificate hygiene is poor, or keys are long-lived and poorly governed, the policy engine is forced to accept requests it cannot truly validate. The architecture may still enforce some friction, but it will not deliver the intended assurance at the point of access.
That is why NIST SP 800-57 Key Management is relevant, because cryptographic trust depends on lifecycle discipline, not just strong algorithms. Where organisations want a practical zero-trust implementation path, Zero Trust for AI Agents and Guide to SPIFFE and SPIRE illustrate the same principle for runtime principals: verify the entity, bind the request to a trustworthy identity, and keep the trust material short-lived and auditable.
When those controls are missing, continuous verification becomes a label rather than a control. Access is then based on assumptions about provenance and integrity that the organisation cannot actually defend.
Risk and Threat Considerations
The main risk is not only weaker authentication, it is trust erosion across the whole control stack. Attackers benefit because stolen identities, forged certificates, replayed sessions, and over-permissive internal trust paths can all look legitimate enough to pass policy checks that were designed for a stronger identity layer.
Failure mechanism: Weak identity proofing, poor certificate lifecycle management, or uncontrolled key material breaks the trust anchor that Zero Trust needs for per-request enforcement.
Impact: Internal and external threats can move laterally, sensitive transactions may be authorised on false premises, and the organisation may believe it has Zero Trust while still operating with implicit trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-57 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of authenticators and keys used to prove access. |
| IA-9 — Service Identification and Authentication | Applies where services and workloads authenticate to each other in Zero Trust flows. | |
| Recommendation — Enforce authenticator lifecycle, rotation, and revocation before relying on Zero Trust decisions. Require strong service-to-service authentication for every workload access path. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Policy Enforcement Point / Policy Decision Point | Zero Trust depends on trustworthy identity inputs at enforcement and decision points. |
| Recommendation — Bind policy decisions to verified identity and cryptographic trust signals. | ||
| NIST SP 800-57 | 1 — General | Key lifecycle management is central when PKI trust underpins Zero Trust. |
| Recommendation — Manage key generation, protection, rotation, and destruction as part of access assurance. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptographic trust is a core dependency when Zero Trust relies on PKI. |
| Recommendation — Apply cryptographic controls that keep identity and transport trust verifiable. | ||
Practitioner Guidance
What to verify: Confirm that every access path depends on a real cryptographic trust anchor, not only on network location or a policy label. If you cannot explain how the principal is proven, how the certificate is issued, and how the key is rotated or revoked, the Zero Trust control is incomplete.
Decision rule: If a workload, user, or service can still access critical resources after its identity material is stale, untrusted, or unverifiable, treat that as a design failure rather than an exception to accept.
What good looks like: Access decisions are bound to strong identity, certificate lifecycles are automated, revocation is operationally real, and the policy engine can reject requests without relying on hidden trust in the network.
Practitioner takeaway: Zero Trust only works when identity and PKI are strong enough to make trust measurable, revocable, and enforceable at request time.
Related resources from NHI Mgmt Group
- What happens when organisations try to use zero trust without changing access control first?
- What happens when organisations try to enforce zero trust without integrated identity stores?
- What happens when organisations try to stop ransomware without strong identity controls?
- What happens when organisations try to defend against modern attacks without a Zero Trust identity model?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
