A per request access decision is an authentication and authorisation check made each time a user or system tries to reach a resource. It is a core Zero Trust concept because trust is not treated as permanent. Access is re evaluated as conditions change, which limits the value of stolen credentials and old sessions.
What Per Request Access Decision Means in Zero Trust
A per request access decision means access is not assumed once and reused indefinitely. Each request is checked against current identity, device, context, and policy conditions so the system can accept, deny, or step up access in real time.
This is the practical opposite of a standing trust model. Instead of treating a login as a long-lived pass, the control point moves to the moment of access, which is why it is a core Zero Trust pattern.
Why Per Request Decisions Matter
Per request evaluation reduces the useful life of stolen credentials, replayed sessions, and stale authorizations. If the user, device, network location, risk score, or resource sensitivity changes, the policy outcome can change on the next request rather than waiting for a session to expire.
That matters most where access is dynamic, high value, or sensitive to context. A per request model is especially valuable for remote work, admin actions, APIs, and environments where the same subject may need different permissions at different times.
How Per Request Evaluation Works
A per request access decision usually combines authentication state with authorization logic. The system may check whether the user or workload is still authenticated, whether the token or session is valid, whether the request matches the expected audience, and whether current attributes still satisfy policy.
The decision can be made by an identity provider, a policy engine, an API gateway, a proxy, or the application itself. The implementation detail varies, but the control principle is consistent: access is re-evaluated at the moment of use, not granted permanently at sign-in.
Where It Fits in Modern Security Architecture
Per request access decisions are most often used with Zero Trust Architecture, conditional access, least privilege, and short-lived credentials. The goal is not to remove identity or session controls, but to make them continuously relevant instead of one-time checks.
They also complement resource-specific controls. A secure design still needs good authentication, strong session handling, and precise authorization boundaries, but per request evaluation adds a critical layer of freshness that helps limit blast radius when trust assumptions change.
Risk and Threat Considerations
Without per request decisions, access can remain valid after the original conditions have changed. That creates exposure when credentials are stolen, devices become untrusted, users leave a network boundary, or a session is hijacked and reused for later requests.
Failure mechanism: The control relies on a one-time or infrequent check, then allows subsequent requests to flow on the strength of an old decision. Attackers can exploit that gap by reusing valid sessions, replaying tokens, or persisting inside the trust window after the original context is no longer safe.
Impact: The organisation can lose the main benefit of Zero Trust, which is limiting the value of compromise after the fact. Stolen access becomes more durable, privilege misuse is harder to stop, and the blast radius of a compromised account or workload can expand across multiple requests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Defines per-request verification and no implicit trust |
| Recommendation — Apply zero trust principles to re-evaluate access at every request. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Access decisions are enforced when a subject requests a resource |
| IA-2 — Identification and Authentication (Organizational Users) | Per-request decisions depend on verified user identity state | |
| IA-5 — Authenticator Management | Short-lived credentials and session validity affect repeat access checks | |
| Recommendation — Enforce policy at the resource and deny requests that no longer satisfy authorization. Require strong authentication before allowing access decisions to proceed. Manage authenticators so expired or compromised credentials stop working promptly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control policies define when requests are allowed or denied |
| A.8.5 — Secure authentication | Per-request access depends on reliable authentication state | |
| Recommendation — Define access rules that require current conditions to be satisfied for each request. Use secure authentication so request-time decisions can trust the asserted identity. | ||
| NIST CSF 2.0 | PR.AA-05 — Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties | Per-request checks operationalize least privilege at decision time |
| Recommendation — Review and enforce permissions so only current, least-privilege access is granted. | ||
Practitioner Guidance
Why practitioners should care: The decision point is only useful if it is actually enforced at request time, not just at sign-in. Teams should verify that policy changes, session age, device state, and resource sensitivity can influence the outcome of real access attempts.
What to watch for: Long-lived tokens, permissive session reuse, and APIs that trust an initial login without rechecking context are common signs that access is not truly per request. If a control can be bypassed by keeping the same session alive, it is not delivering the intended Zero Trust effect.
Practitioner takeaway: Treat the access decision as a continuous control, not a login event. The closer the enforcement point is to the resource and the current request, the more effectively it limits stale trust.
Related resources from NHI Mgmt Group
- What is the difference between a traditional pay-per-request AI API and a capacity-based access model?
- What is the difference between per-request authorization and authenticate once, trust indefinitely access?
- What is the difference between session-based access and per-request authorization?
- What happens when organisations delay updating cookies, automated decision making, and subject access request processes under the DUAA?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
