What breaks when zero trust policy only checks who someone is?

Why Zero Trust Stops Working When Policy Only Checks Identity

zero trust becomes thin if policy treats authentication as the whole decision. Identity proof only answers “who or what is this?” It does not answer whether the request should still be allowed, whether the device is healthy, whether the task is expected, or whether the session has drifted into risky territory. The missing piece is ongoing authorisation based on context, not a one-time login event.

That is why zero trust policy has to be evaluated at decision time, not just at sign-in. If the policy engine cannot see session context, device posture, resource sensitivity, and request intent, it can accidentally preserve access long after the original trust decision is no longer valid. In practice, that turns zero trust into a stronger gate at the front door with weak control inside the building.

For a practical reference point, NIST SP 800-207 Zero Trust Architecture describes the move from static trust to policy-driven, continuously evaluated access decisions, and Zero Trust Identity Guide shows how that model is applied across people, workloads and devices.

Where the Authorization Layer Fails

When policy only checks who someone is, the system may still authenticate correctly while making the wrong access decision. That failure usually shows up in authorization, entitlement scope, or session control, not in identity proof itself. A valid login can coexist with stale privileges, excessive access, or a device that no longer meets trust requirements.

That distinction matters because zero trust is supposed to reduce implicit trust after entry. If policy does not re-evaluate the request against context, then sensitive actions can continue under a session that should have been narrowed, stepped up, or stopped. The result is especially dangerous for admin consoles, data repositories, CI/CD systems, and internal APIs where standing access has high blast radius.

Zero trust designs work best when the policy decision point can factor in more than identity, which is why Zero Trust for AI Agents and Zero Trust Identity Guide both emphasise continuous verification and per-request policy enforcement rather than a single authenticated session.

What Context Adds to the Decision

Context is what lets zero trust answer the second question after identity: should this access still continue, and in what form? Common context signals include device posture, source location, request type, resource sensitivity, time of day, and whether the action matches the user’s or workload’s normal behaviour. Without those signals, policy cannot distinguish a routine read from a privileged change, or a healthy endpoint from a compromised one.

That is why identity and authorisation must work together. Authentication establishes the principal; authorisation determines the scope and duration of trust. If either side is missing, the control can still look modern while behaving like a traditional perimeter model. This is why the strongest zero trust implementations tie policy to ongoing risk rather than to an initial login event alone.

For workload and service-to-service cases, context often includes stronger technical signals such as attestation, trust bundles, or mTLS-backed identity, which is why Guide to SPIFFE and SPIRE is relevant to the same problem. It shows how machine identity and verifiable workload context support finer-grained access control than a static credential ever can.

Risk and Threat Considerations

When zero trust checks only identity, the main risk is overexposed access that survives beyond the conditions that made it acceptable. An attacker does not need to defeat the login flow again if they can reuse a valid session, inherit stale privileges, or operate from a compromised device that the policy never re-evaluates.

Failure mechanism: The policy engine authenticates once, then fails to re-check whether the session, device, or request still meets the conditions for access. That leaves privileged sessions, sensitive resources, and high-value workflows open to abuse after the original trust decision has already become invalid.

Impact: Compromised or poorly governed sessions can be used for lateral movement, privilege misuse, data exposure, or sensitive action execution with very little friction. The longer the session remains valid without contextual review, the larger the blast radius becomes.

Practitioner Guidance

What to verify: Treat any zero trust design as incomplete unless it can explain what happens after authentication. Verify that policy can still narrow, step up, or terminate access when device posture, session risk, or request context changes.

Decision rule: If your control only answers “is this the right identity?”, add a second rule that answers “is this the right access for this request, right now?”. If you cannot express that decision, you do not yet have zero trust, only stronger login.

What good looks like: High-risk actions require fresh context, privileged sessions are short and observable, and access to sensitive systems is explicitly tied to current conditions rather than to the fact that a user or workload once authenticated.

Practitioner takeaway: Zero trust fails when it becomes an identity check without a continuing authorisation decision, because the real control is not admission, it is ongoing permission.

Related resources from NHI Mgmt Group

• What breaks when machine identities are excluded from Zero Trust policy?
• What breaks when Zero Trust segmentation policy has to be written as strict device-by-device rules?
• What breaks when organisations try to implement Zero Trust with ad hoc firewall rules and manual policy handling?
• What breaks when Zero Trust still depends on periodic identity checks?