Skip to main content
Identity Authority
Category: Zero Trust Architecture

Per-Request Access Decision

Also known as: Per-Request Authorization
Simply put

A per-request access decision means that each individual action a user or system attempts is evaluated on its own, rather than granting broad trust once at the start of a session. Every request to reach a resource is checked as it happens, so being allowed in earlier does not automatically permit later activity. This approach is a core idea in Zero Trust, which aims to enforce accurate, least-privilege access one request at a time.

Formal definition

A per-request access decision is an authorization determination evaluated at the point of each individual request rather than being cached or implied by prior session establishment. It is an enforcement-time (runtime) authorization concept, distinct from authentication, which establishes who the principal is, in which each action is checked individually instead of relying on a once-authorized session to cover subsequent activity. In NIST's articulation of Zero Trust, per-request access decisions are intended to minimize uncertainty and enforce least privilege on a per-request basis. The evidence describes the pattern conceptually but does not specify a particular access control model (for example RBAC, ABAC, or PBAC), policy evaluation architecture (such as PDP/PEP/PIP roles), or token validation mechanics; those implementation details are out of scope for this definition and vary by deployment.

Why it matters

The core weakness this concept addresses is implicit trust: many traditional access architectures authenticate a principal once, establish a session, and then treat subsequent activity within that session as trusted. A per-request access decision breaks that assumption by evaluating each individual action on its own, so being admitted earlier does not automatically authorize later activity. This matters because a session that remains trusted after initial establishment can become a vehicle for lateral movement, privilege abuse, or use of a compromised token if conditions change after the initial check.

In NIST's articulation of Zero Trust, per-request access decisions are positioned as a mechanism to minimize uncertainty and enforce least privilege one request at a time. The practical significance is that authorization is treated as an ongoing, enforcement-time concern rather than a one-time gate. This lets an environment respond to changing context and revoke or deny access at the granularity of an individual request rather than waiting for a session to expire.

It is worth being precise about scope: per-request evaluation is an authorization pattern, distinct from authentication, which establishes who the principal is. It does not by itself specify a particular access control model or policy architecture, and its security benefit depends heavily on how each request is actually evaluated in a given deployment. Treated as a design principle rather than a product feature, it shifts the operational question from "is this session trusted?" to "should this specific action be allowed right now?"

Who it's relevant to

Security Architects
For architects designing Zero Trust environments, per-request access decisions are a foundational principle that shapes how trust boundaries and enforcement points are laid out. The design choice to evaluate each request individually, rather than relying on session-level trust, influences where authorization is enforced and how least privilege is realized in practice.
IAM Engineers
Engineers implementing runtime access enforcement need to translate the per-request principle into concrete evaluation flows. Because the evidence does not prescribe a specific policy architecture or token validation approach, engineers must select and configure those mechanics for their deployment while preserving the core behavior that no request is authorized merely because an earlier one was.
Identity Governance Leads
Governance leads should note that per-request decisions are an enforcement-time concept, distinct from lifecycle activities such as provisioning, access reviews, and certification. Understanding this boundary helps clarify that granting an entitlement through governance is not the same as authorizing each runtime action, which is decided per request.
Compliance Officers
For compliance officers evaluating alignment with Zero Trust guidance, per-request access decisions map to the goal of enforcing least privilege on a per-request basis, as articulated by NIST. The concept is useful for framing expectations, though how thoroughly each request is evaluated depends on the specific deployment and is not implied by the principle alone.

Inside Per-Request Access Decision

Policy Enforcement Point (PEP)
The runtime component that intercepts each request to a protected resource and enforces the decision returned by the PDP. In most deployments the PEP sits in the request path (for example an API gateway, proxy, or service-side middleware) and either permits or denies the operation per request.
Policy Decision Point (PDP)
The component that evaluates applicable policies against the request context and returns an authorization decision. In a per-request model the PDP is consulted for each request rather than relying on a decision cached from an earlier session event.
Policy Information Point (PIP)
The source(s) the PDP queries for attributes needed to evaluate policy, such as subject attributes, resource metadata, or environmental signals. Availability and freshness of PIP data typically influence how current a per-request decision can be.
Request context
The set of inputs evaluated for a single request, which depending on configuration may include the authenticated principal, the resource and action requested, and environmental or contextual signals. This context is what makes each decision specific to the request being made.
Authorization scope (not authentication)
A per-request access decision is an authorization step: it determines what an already-identified and authenticated principal may do for this specific request. Verifying who the principal is (authentication) and establishing identity (identification) are separate, prior steps and are out of scope for the decision itself.
Underlying access control model
The decision is expressed against a model such as RBAC, ABAC, PBAC, or ReBAC. ABAC and PBAC in particular lend themselves to per-request evaluation because they can incorporate request-time attributes and context; the model in use shapes what inputs the PDP considers.

Common questions

Answers to the questions practitioners most commonly ask about Per-Request Access Decision.

Does making a per-request access decision mean I'm re-authenticating the user on every request?
No. A per-request access decision is an authorization step, not an authentication step. It evaluates whether an already-authenticated principal may perform a specific action on a specific resource for that request. The authentication event that established the principal's identity typically happened earlier and is represented by a token or session; re-verifying identity (for example through step-up authentication) is a separate concern that would only be triggered under specific policy conditions, not as part of every authorization evaluation.
Is a per-request access decision the same thing as validating the token on each request?
Not exactly. Token validation and the access decision are distinct steps that often occur together. Validating a token confirms it is well-formed, unexpired, correctly signed, and issued by a trusted authority, which establishes trustworthy inputs. The access decision then uses those inputs, claims, attributes, resource, and action, against policy to determine whether the request is permitted. A token can be perfectly valid and the request still be denied by policy. Conflating the two obscures the fact that validation supplies inputs to a PDP, while the decision is the policy evaluation itself.
Where should the decision logic live relative to the enforcement point?
In most externalized-authorization deployments the decision logic sits in a Policy Decision Point (PDP) that is separated from the Policy Enforcement Point (PEP) that intercepts the request and applies the outcome. The PEP calls the PDP, which may in turn consult a Policy Information Point (PIP) for additional attributes. Whether the PDP is embedded as a library, run as a local sidecar, or reached as a remote service is a deployment tradeoff typically weighed against latency, availability, and policy consistency requirements. Colocating decision logic reduces latency but can complicate consistent policy distribution across many enforcement points.
How do teams manage the latency of evaluating a decision on every request?
Approaches vary by deployment and vendor. Common techniques include running the decision engine close to the enforcement point (for example as a sidecar or embedded library), caching decisions or the attributes that feed them for a bounded time, and pre-fetching or distributing policy so evaluation is local. Each technique introduces its own tradeoff: caching a decision can serve stale results if the underlying attributes or policy change, so cache lifetimes are typically tuned against how quickly changes must take effect. The right balance depends on the sensitivity of the resource and tolerance for staleness.
What inputs does a per-request decision typically require, and how are they supplied?
A per-request decision generally needs the subject (who is acting, from validated token claims or a session), the action being attempted, the target resource, and often environmental or contextual attributes such as time, device posture, or network location, depending on the model in use. In an ABAC or PBAC deployment these attributes may be drawn from a PIP at evaluation time; in a ReBAC deployment the relevant relationships between subject and resource are consulted. Which inputs are available and how fresh they are directly affects what policies you can enforce.
How should denied decisions be logged and handled for audit and troubleshooting?
Because the decision happens on each request, capturing both permit and deny outcomes, along with the inputs and the policy or rule that produced them, supports auditing and debugging, though the exact detail available depends on the engine and configuration. Practically, teams should decide how much decision context to record given data-sensitivity and volume concerns, and how a PEP behaves when the PDP is unreachable, since fail-open versus fail-closed handling is a configuration choice with significant security implications. These operational logs are distinct from the periodic access reviews handled under identity governance.

Common misconceptions

A valid token or an established session means the request is already authorized.
A token or session generally attests to authentication (and possibly some granted scopes), but authorization for a specific request is a distinct determination. A per-request model re-evaluates whether the principal may perform this particular action on this particular resource rather than assuming a prior grant still applies.
Per-request access decisions and identity governance (provisioning, access reviews, certification) are the same activity.
Per-request decisions are runtime enforcement carried out by the PEP/PDP at the moment of access. IGA concerns such as provisioning entitlements, periodic access certification, and segregation-of-duties review operate on a different lifecycle and do not, by themselves, make real-time decisions for individual requests.
Evaluating a decision per request guarantees the freshest possible attribute data.
The currency of a decision depends on the freshness and availability of the attributes the PDP obtains from its PIPs, and on any caching in the deployment. Per-request evaluation increases how often policy is applied, but stale attribute sources or caching can still affect the inputs, depending on configuration.

Best practices

Keep the request-time flow ordered explicitly: identify the principal, authenticate them, then perform the authorization decision per request, and design the PEP to fail closed if the PDP is unreachable.
Choose an access control model (for example ABAC or PBAC) that can express the request-time attributes and context you need, rather than forcing per-request logic onto a model that cannot represent it.
Document which attributes come from which PIPs and account for their freshness and availability, since decision quality typically depends on the currency of those inputs.
Be deliberate about any caching of decisions or attributes, and define invalidation behavior so that cached results do not silently outlive the context that justified them.
Keep runtime enforcement (PEP/PDP/PIP) separate from IGA processes such as provisioning and certification, while ensuring entitlement changes made in governance propagate to the attribute sources the PDP reads.
Validate tokens presented with a request (including signature and, where applicable, encryption expectations) as an input to the decision, but do not treat a valid token as equivalent to authorization for the specific action requested.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.