Zero trust identity: what NIST SP 800-207 asks of the identity layer

NextGen Identity Security desk · 2026-09-29

Editorial assessment · Desk research from public vendor material · Reviewed 2026-09-29

4 min read

Where the term comes from

NIST SP 800-207, Zero Trust Architecture, was published on 11 August 2020 by Scott Rose, Oliver Borchert, Stu Mitchell and Sean Connelly. Its abstract defines zero trust as "an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources". The document's central idea is that being on the corporate network should not grant trust on its own. Authentication and authorization happen as distinct steps before each session with an enterprise resource is established.

CISA's Zero Trust Maturity Model, written to help US federal agencies apply the idea, organizes the work into five pillars and three cross-cutting capabilities. Identity is one of the pillars, and in most organizations it is the one the others depend on: device, network and application decisions all start from knowing who, or what, is asking.

What zero trust identity means in practice

Zero trust identity is the identity layer built to support per-request decisions. Three properties matter most.

1. Decisions per request, with context

The identity provider, or a policy engine next to it, evaluates each access with the signals available at that moment: who the user is, the device, the location, the risk. Microsoft calls Conditional Access its "Zero Trust policy engine"; Okta's Identity Threat Protection re-evaluates risk during a session rather than only at sign-in. For AI agents, the same principle moves down to each tool call, which is what the per-call authorization criterion on the AI agent page measures.

2. Authentication that resists phishing

Per-request decisions are only as good as the authentication behind them. NIST SP 800-63B-4, published on 31 July 2025, sets out three authenticator assurance levels and supersedes the previous edition of SP 800-63B. The practical direction across the vendors on this site is the same: passkeys, FIDO2 keys and platform authenticators in place of passwords and one-time codes that can be relayed by a phishing page.

3. Protecting the token after the decision

Once a user or agent is authenticated, the decision travels as a token or assertion. If an attacker can steal, replay or forge that token, every check before it is bypassed. NIST IR 8587, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse", was finalised on 15 September 2026 after a draft on 22 December 2025, with recommendations for identity providers, authorization servers, key management and token verification. The OpenID Foundation noted that the report recommends two of its specifications, the Shared Signals Framework and the Continuous Access Evaluation Profile.

Vendors approach this differently. Okta's Universal Logout and shared signals with security tools let it end sessions across apps when risk changes. NewCore's Secure Split Key divides signing authority so that neither NewCore's cloud nor the customer's environment can sign a token alone.

A short checklist

1. Can every application decision be tied to an identity, not a network location?
2. Is phishing-resistant authentication required for administrators, and available for everyone?
3. Are sessions and tokens re-evaluated when risk changes, or only at sign-in?
4. Who can sign tokens your applications trust, and what happens if that key is stolen?
5. Do service accounts and AI agents go through the same policy engine as people?

Where to go next

The ITDR page scores tools that detect attacks on identity systems. The workforce IAM page scores identity providers on phishing-resistant sign-in and token-signing protection. The AI agent page applies the same thinking to agents.