Skip to main content
Identity Authority
Category: Authorization Concepts

Access Decision

Also known as: Access Control Decision, Authorization Decision
Simply put

An access decision is the outcome of determining whether a particular user, service, or other requester should be allowed to perform a specific action on a resource, such as reading a file or calling an API. In practice, the answer is typically a permit or a deny. This decision assumes the requester has already been identified and authenticated; the access decision itself concerns what they are permitted to do.

Formal definition

An access decision (commonly access control decision or authorization decision) is the result of evaluating whether a subject is permitted to perform a requested action on a protected object or resource, yielding a permit or deny outcome (some frameworks also support indeterminate or not-applicable results, depending on the model and profile). It is an authorization function that follows successful identification and authentication and does not itself establish the subject's identity. In a runtime enforcement architecture the decision is typically rendered by a Policy Decision Point (PDP) based on applicable policy and attributes, and enforced by a Policy Enforcement Point (PEP); the specific inputs and logic vary by access control model (for example RBAC, ABAC, PBAC, or ReBAC) and by deployment configuration. Out of scope for this term are identity governance lifecycle activities such as provisioning and access certification, which determine what entitlements exist rather than evaluating an individual runtime request.

Why it matters

The access decision is the moment where authorization policy becomes an enforceable outcome. Every read of a file, every API call, and every attempt to reach a protected resource ultimately resolves to a permit or deny decision. If that decision is rendered incorrectly, the consequences fall into one of two failure modes: over-permissive decisions expose data and functions to requesters who should not have them, while over-restrictive decisions break legitimate workflows and drive users toward workarounds. Because the decision is evaluated per request at runtime, its correctness depends on the policy, attributes, and context available at the moment of evaluation, which can differ from what was intended when entitlements were originally granted.

It is important to keep the access decision distinct from the steps that precede it. The decision assumes the requester has already been identified and authenticated; it concerns only what the authenticated subject is permitted to do. Conflating authentication with the access decision is a common source of design errors, because a system that correctly verifies who someone is can still make wrong determinations about what they may do. Similarly, the access decision is separate from identity governance activities such as provisioning and access certification, which determine what entitlements exist in the first place rather than evaluating an individual runtime request.

The access decision is also where different access control models express themselves concretely. Whether a system uses RBAC, ABAC, PBAC, or ReBAC changes the inputs and logic that produce the permit or deny result, but the decision itself remains the common enforcement point. This makes it a critical focal point for both security architecture and audit: understanding how, where, and on what basis decisions are rendered is often more revealing than reviewing static entitlement lists alone.

Who it's relevant to

Security Architects
Architects decide where access decisions are rendered and enforced, choosing how to separate the PDP from the PEP and which access control model (RBAC, ABAC, PBAC, or ReBAC) best fits the resources being protected. They must ensure the decision point receives the attributes and policy it needs, and that authentication is cleanly separated from the authorization decision in the overall flow.
IAM Engineers
Engineers implement and integrate the components that produce and enforce access decisions, wiring PEPs into applications and APIs and ensuring the PDP has access to the required policies and attributes. They handle the practical details of how permit and deny outcomes are returned and applied at runtime, and how indeterminate or not-applicable results are handled where the model supports them.
Compliance Officers and Auditors
Auditors need to understand not only what entitlements exist but how individual access decisions are actually made at runtime. Because the access decision is distinct from provisioning and certification, reviewing decision logic and enforcement points provides evidence of whether policy is applied consistently to each request, complementing governance-side reviews of what access has been granted.
System Administrators
Administrators operate the systems that render and enforce decisions day to day, and are often the first to observe the operational impact of misconfigured policy, whether that appears as over-permissive access or as legitimate requests being denied. Their visibility into decision outcomes helps diagnose whether a failure stems from authentication, from the policy inputs, or from the enforcement layer.

Inside Access Decision

Policy Decision Point (PDP)
The component that evaluates applicable policies against the request context and renders the access decision (typically permit or deny). The PDP is the locus of the decision itself and is distinct from the point that enforces it.
Policy Enforcement Point (PEP)
The runtime component that intercepts the access request, forwards relevant context to the PDP, and enforces the returned decision. The PEP acts on the decision but does not itself compute it.
Policy Information Point (PIP)
A source that supplies additional attributes or context (such as user attributes, resource metadata, or environmental signals) needed by the PDP to reach a decision. Depending on the model, these attributes feed ABAC or PBAC evaluation.
Decision Inputs
The request context evaluated by the PDP, which may include the authenticated principal's identity and attributes, the requested resource and action, and environmental factors. The specific inputs depend on the access control model in use (for example RBAC roles, ABAC attributes, ReBAC relationships, or PBAC policies).
Decision Outcome
The result returned by the PDP, typically a permit or deny, and in some profiles an indeterminate or not-applicable result plus obligations or advice that the PEP must act on. Exact outcome semantics vary by policy language and deployment.
Authorization Context (not Authentication)
An access decision determines what an already-identified and authenticated principal may do; it is an authorization step. Verifying who the principal is (authentication) is a prior, separate step and is generally out of scope for the decision itself.

Common questions

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

Is an access decision the same thing as authenticating the user?
No. Authentication verifies who a principal is, while an access decision is an authorization step that determines what an already-identified and authenticated principal may do. In most deployments authentication happens first and produces the identity and claims that the access decision then evaluates, but the two are separate steps and should not be conflated. A successfully authenticated principal can still receive a deny decision, and the components that make access decisions typically treat the authenticated identity as an input rather than performing the authentication themselves.
Does the component that makes the access decision also enforce it?
Not necessarily, and in a cleanly separated architecture it does not. The decision is typically produced by a Policy Decision Point (PDP), while enforcement is carried out by a Policy Enforcement Point (PEP) that permits or blocks the actual operation. The PDP renders a decision such as permit or deny; the PEP acts on it. Conflating the two blurs the distinction between deciding and enforcing, though in some products both functions may be packaged within the same runtime component depending on configuration.
What inputs does a PDP typically need to render an access decision?
Depending on the access control model in use, a PDP typically evaluates the subject's identity and attributes, the requested action, the target resource, and relevant environmental or contextual conditions against applicable policy. In ABAC and PBAC deployments these attributes may be retrieved at decision time from a Policy Information Point (PIP). In RBAC-oriented systems the decision commonly turns on role assignments, while ReBAC decisions depend on relationships between subject and resource. The exact inputs vary by model, policy language, and vendor implementation.
How does a PEP obtain the authorization data it needs to request or apply an access decision?
This varies by deployment. In some architectures the PEP calls out to a PDP at runtime, passing the request context and receiving a decision. In token-based flows, authorization-relevant claims may instead be carried in a self-contained token that the PEP validates locally, in which case the PEP relies on those claims rather than a live PDP call. Note that a signed token is not the same as an encrypted one, so the PEP should validate the signature and, where required, confirm claims are not exposed in a way that violates confidentiality expectations. Some designs combine both patterns.
How should an access decision behave when a required attribute or policy is unavailable?
This depends on the policy language, combining algorithm, and configured default. Many policy frameworks support explicit outcomes for indeterminate conditions and let operators choose a default of deny (fail closed) or, less commonly and more cautiously, permit. In most security-sensitive deployments a fail-closed default is preferred so that missing inputs do not silently grant access, but the correct choice depends on the resource's risk profile and organizational requirements. The specific mechanisms and terminology differ across implementations.
How do access decisions relate to identity governance activities like access reviews?
They operate at different stages. Access decisions are a runtime enforcement concern, evaluated when a principal attempts an action. Identity governance and administration activities such as provisioning, access certification, and segregation-of-duties reviews determine, ahead of time, which entitlements a principal should hold. Governance shapes the roles, attributes, or relationships that a runtime decision later consults, but reviewing and certifying access is distinct from making a real-time permit-or-deny decision. Keeping these separate helps avoid blurring lifecycle management with enforcement.

Common misconceptions

An access decision authenticates the user.
An access decision is an authorization step that assumes the principal has already been identified and authenticated. Authentication verifies who the principal is and occurs before, and separately from, the authorization decision.
The component that makes the decision is the same one that enforces it.
In most enforcement architectures the PDP renders the decision while the PEP enforces it; they are logically distinct responsibilities even when co-located in a single product. Blurring them obscures where policy is evaluated versus where it is applied.
Access decisions belong to identity governance processes like access certification.
Access decisions are runtime enforcement concerns. IGA activities such as provisioning, access reviews, certification, and segregation-of-duties analysis govern which entitlements exist over the identity lifecycle, but they are separate from the real-time PDP/PEP evaluation of a specific request.

Best practices

Keep the decision function (PDP) architecturally distinct from enforcement (PEP) so policy logic can evolve independently of the systems that apply it.
Externalize authorization policy where practical rather than hardcoding decision logic into applications, so decisions are consistent and auditable across services.
Be explicit about which access control model governs a given decision (RBAC, ABAC, PBAC, or ReBAC), since the required decision inputs and attribute sources differ accordingly.
Ensure the PDP receives the attributes and context it needs from reliable PIPs, and validate that the principal was authenticated in a prior step before evaluating authorization.
Define and handle non-permit outcomes deliberately, including deny and any indeterminate or not-applicable results, plus any obligations the PEP must fulfill, according to your policy language's semantics.
Log decision inputs and outcomes to support auditing and troubleshooting, while keeping runtime enforcement decisions separate from lifecycle governance records.
Application Security Isn’t Optional Anymore.