Authorization Mechanisms — CISSP Study Guide

What authorization is, and the model it sits on

"The user logged in but still can't open the file" is an authorization question, not an authentication one, and spotting that split is the first reflex this subtopic builds. Authorization is the decision a system makes, after a subject is authenticated, about whether that subject may perform a requested action on a particular object: authentication answers who are you, authorization answers what may you do. A subject is the active entity making the request (a user, process, or device); an object is the passive resource being acted on (a file, record, API, or device). The seven models in this subtopic are really seven answers to one question, and reading each as that answer is what keeps the look-alikes apart.

Every model below expresses its rules differently, but they all rely on one enforcement concept: the reference monitor. NIST defines the reference monitor as a set of design requirements on the mechanism that mediates access between subjects and objects: it must be always invoked (non-bypassable, so it sees every request, called complete mediation), tamperproof (protected from modification), and verifiable (small enough to be analyzed and tested for correctness) (NIST glossary: reference monitor^[1]). The model defines the policy; the reference monitor enforces it. Hold this distinction: a security model (RBAC, MAC, ABAC) is a set of rules; it does not itself enforce anything. The reference monitor concept does.

The models divide on a single axis that the rest of this page returns to repeatedly: who holds the discretion to set the permission, and on what basis is the access decision made. Owner discretion, system-enforced labels, job-function roles, global rules, request-time attributes, live risk, and time-boxed need are the seven answers. Read each model below as "who decides, and how," and the choices that look similar will separate cleanly. The figure groups the seven the way the rest of the page reads them: DAC and MAC by who holds the discretion, RBAC and rule-based by identity versus global rule, and ABAC, risk-based, and just-in-time as dynamic or time-bound control layered on top of a base grant.

The seven authorization models on one axis: who holds the discretion to set the permission, and on what basis the access decision is made.

DAC and MAC: owner discretion vs. system-enforced labels

This section covers the two oldest and most-contrasted models, framed as a single delta: who may change the permission. Treat DAC and MAC as the two ends of a discretion spectrum; everything else is a consequence of that one difference.

Discretionary access control (DAC) puts the decision in the hands of the resource owner, at the owner's discretion. That word is the model's name. The owner grants or revokes access, typically through an access control list (ACL): a list attached to the object enumerating which subjects get which permissions (read, write, execute). Standard commercial operating-system file permissions are DAC. Its strength is flexible, decentralized sharing; its inherent weakness is that any owner can pass access to anyone, so a careless or compromised owner can leak data, and a Trojan running as the owner inherits the owner's discretion. DAC is therefore not used where data must be protected regardless of an owner's choices.

Mandatory access control (MAC) removes that discretion entirely: the system enforces access from a central policy that no owner (not even the data's creator) can override. Access is decided by comparing security labels: every subject carries a clearance and every object a classification (e.g., Confidential, Secret, Top Secret), and the system permits access only when the labels satisfy the policy. This is why MAC is the model of classified, military, and other multilevel-secure (MLS) systems where one system holds data at several sensitivities at once. The distinction between marking and labeling matters here: a security marking is human-applied metadata, while a security label is the machine-readable association the system actually parses and enforces. MAC runs on labels, not markings (NIST glossary: security label^[2]).

The formal model behind MAC's confidentiality is Bell-LaPadula, whose Simple Security Property forbids reading above one's clearance ("no read up") and whose *-Property forbids writing below one's level ("no write down"), so classified data cannot flow downward to a lower classification (NIST IR 7316, Assessment of Access Control Systems^[3]). For the authorization decision, the takeaway is simply: MAC = labels + clearances enforced by the system; the lattice math lives under security models. Note one nuance NIST raises: even MAC can leak through covert channels, where higher-classified information is inferred by combining lower-classified observations. Labels constrain explicit flows, not every inference.

RBAC and rule-based: roles vs. global rules

This section covers the two models most often confused because their names rhyme, and fixes the confusion with one sentence each. They are unrelated mechanisms.

Role-based access control (RBAC) assigns permissions to roles that mirror job functions, and subjects acquire permissions by being assigned a role. A user inherits exactly the permissions of the roles they hold, and nothing else. The administrative payoff is scale: instead of editing permissions on thousands of users, you manage a handful of roles, and a new hire, a transfer, or a leaver is handled by changing role assignments. This is why RBAC is the default in large enterprises with stable job functions, and why it is the natural control against privilege creep (the accumulation of unneeded rights as people change jobs) provided assignments are reviewed. The authoritative model (the ANSI/INCITS 359 RBAC standard) adds two constraints worth knowing by name: role hierarchies, where senior roles inherit junior-role permissions, and separation of duty constraints, which forbid one user from holding a conflicting pair of roles (e.g., create-vendor and approve-payment), enforced either statically at assignment or dynamically at activation.

Rule-based access control applies global conditions to every subject regardless of identity. A firewall or router ACL is the canonical example: the rule "deny inbound port 23 from any source" applies to all traffic, not to a named user; likewise "no logins outside 08:00–18:00" gates everyone the same way. The defining trait, and the exam discriminator, is that the decision does not depend on who the subject is, only on whether the request matches a rule. Reconcile the naming trap immediately: rule-based and role-based share an acronym fragment but are opposites on the identity axis. Role-based decides by who you are (your role); rule-based decides by what the request is (does it match the rule), ignoring identity. When a question contrasts "based on the user's job" against "the same condition for all users," it is testing exactly this pair.

ABAC, risk-based, and just-in-time: dynamic and time-bound control

This section covers the three modern models, which share a theme: the access decision becomes dynamic (computed from context at request time or limited in time) rather than fixed in an ACL or role.

Attribute-based access control (ABAC) decides access by evaluating a policy over attributes of four things: the subject (clearance, department, training), the object (classification, owner, type), the action (read vs. delete), and the environment (time, location, device posture, threat level) (NIST SP 800-162, Guide to ABAC Definition and Considerations^[4]). Because a single policy rule combines many attributes, ABAC is the most granular and dynamic model and can express decisions RBAC cannot without a "role explosion", e.g., "a nurse may read records of patients on her assigned ward, on a managed device, during her shift." NIST frames RBAC and ABAC as complementary rather than rival: roles can be one attribute among many. ABAC is architected around a Policy Decision Point (PDP) that evaluates the policy and a Policy Enforcement Point (PEP) that allows or blocks the request, the same PDP/PEP split that underpins zero-trust authorization (NIST SP 800-207, Zero Trust Architecture^[5]).

Risk-based (risk-adaptive) access control, often abbreviated RAdAC, extends the attribute idea with a live risk score: the engine weighs contextual signals (device health, anomalous location, behavior deviation, sensitivity of what's requested) and adapts the decision in real time: permit, deny, or step up to additional authentication. The exam-relevant property is adaptivity within a session: the same authenticated user with the same role can be allowed one moment and challenged the next because the computed risk changed. RAdAC is typically realized as ABAC with risk as a first-class environmental attribute, and it is a core building block of adaptive authentication and zero-trust designs.

Just-in-time (JIT) access control addresses when permissions are live rather than who decides them. Instead of leaving privileged rights permanently assigned, JIT grants elevated access only for the duration of a specific task and revokes it automatically afterward, so accounts carry no standing privilege for an attacker to hijack (Microsoft: implementing least-privilege administrative models^[6]). It is least privilege applied to time, and the foundation of zero standing privilege, where a privileged role holds no rights at rest until a scoped, time-boxed, usually approved activation. JIT layers on top of whatever base model is in use: it shrinks the exposure window for DAC/MAC/RBAC/ABAC permissions; it does not replace them. Reconcile the relationship plainly: ABAC, RAdAC, and JIT are not competitors to RBAC. ABAC adds granularity, RAdAC adds adaptivity, and JIT adds a time limit, each on top of an underlying grant.

Exam-pattern recognition: choosing the right model

This section names the question shapes you will see and the decision rule that resolves each. Authorization items are almost always "which model fits this requirement" or "why did access behave this way," not "define RBAC." Train on the discriminator (who decides, on what basis) rather than the label.

Pattern A: "data must be protected regardless of the owner's wishes." Stems mention classified, military, or multilevel data, or explicitly say an owner must not be able to share down. Answer: MAC. The tell is system-enforced labels/clearances and no owner discretion; the distractor is DAC ("owners manage their own files"), which is exactly what the requirement forbids.

Pattern B: "manage access for a large workforce by job function." Onboarding, transfers, audits, and privilege creep appear. Answer: RBAC, permissions to roles, users to roles. Watch the rhyming distractor rule-based, which decides by global condition and ignores job function entirely; if the requirement is "by the user's job," rule-based is wrong by construction.

Pattern C: "fine-grained, context-dependent, too many roles." The requirement combines several conditions (department + device + time + data sensitivity) or notes that RBAC has produced a role explosion. Answer: ABAC, a policy over subject/object/action/environment attributes. If the stem adds "and the decision should change as risk changes mid-session," the answer shifts to risk-based/RAdAC (adaptive, often step-up authentication).

Pattern D: "reduce the danger of always-on privileged accounts." The stem worries about standing admin rights, lateral movement, or stolen privileged credentials. Answer: just-in-time access / zero standing privilege, grant privilege only for the task, revoke automatically. The distractor is "give admins least-privilege permanent roles," which still leaves standing privilege to steal; JIT's whole point is removing the standing part.

Pattern E: "first/best" framing. When asked what a security leader should choose first or as the best fit, anchor on the requirement's discriminator, not familiarity: classified data → MAC; scale by job → RBAC; granular/contextual → ABAC; live-risk adaptive → RAdAC; kill standing privilege → JIT; owner-controlled sharing of unclassified files → DAC. The most common wrong answer pairs are DAC↔MAC (who holds discretion) and RBAC↔rule-based (identity vs. global rule).

Authorization models: who decides, on what basis, granularity, and where used

Model	Who sets the permission	Decision basis	Granularity / dynamism	Typical use
DAC (discretionary)	Resource owner, at their discretion	Owner-defined ACL / permissions on the object	Per-object, static until owner changes it	Commercial OS file sharing, collaboration
MAC (mandatory)	The system, from central policy (no owner override)	Security labels: subject clearance vs object classification	Coarse by label, rigid and non-discretionary	Classified / multilevel-secure government systems
RBAC (role-based)	Administrator, via roles mapped to job functions	Role membership the subject holds	Per-role, static until role/assignment changes	Large enterprises with defined job functions
Rule-based	Administrator, via global rules	Conditions applied uniformly to all subjects	Per-rule, same for everyone regardless of identity	Firewall ACLs, time-of-day or location rules
ABAC (attribute-based)	Policy author, via attribute rules	Attributes of subject, object, action, environment	Most granular and dynamic, evaluated per request	Cloud / fine-grained, context-aware authorization
Risk-based (RAdAC)	Policy engine, from a live risk score	Real-time contextual risk (posture, location, behavior)	Adaptive: changes within a session	Adaptive / step-up authentication, zero trust
Just-in-time	Approval/automation at moment of need	Time-boxed grant for a specific task	Privilege exists only during the task window	Privileged access management, zero standing privilege

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Authorization decides what an already-authenticated subject may do

Authorization is the access decision a system makes after authentication has proven the subject's identity, determining whether that subject may take a requested action on an object. Authentication answers who you are; authorization answers what you may do. A scenario where a logged-in user still cannot open a resource is an authorization problem, not an authentication one.

Trap Treating a denied-access-after-login symptom as a failed login. The identity was already proven, so the fix is the authorization policy, not the credential.

The reference monitor enforces the policy; the model only defines the rules

A security model such as RBAC, MAC, or ABAC is a set of access rules and does not enforce anything by itself: enforcement is the job of the reference monitor, the conceptual mediator that must be always invoked (non-bypassable, giving complete mediation), tamperproof, and verifiable. Every authorization model assumes some reference-monitor implementation underneath it. Distinguishing the rule set from its enforcer is a recurring exam framing.

Trap Picking the access model itself as what enforces the decision when a question asks for the always-invoked, tamperproof mediator; the model is only the rule set, and the reference monitor is the enforcer.

The authorization models differ on who holds the discretion to set the permission

The single discriminator that separates the models is who decides the permission and on what basis: the owner (DAC), the system via labels (MAC), an administrator via roles (RBAC), an administrator via global rules (rule-based), a policy over attributes (ABAC), a live risk score (RAdAC), or a time-boxed grant at moment of need (JIT). Identifying who owns the decision in a scenario resolves most model-selection questions. Reading each model as an answer to who-decides-and-how keeps similar choices distinct.

DAC lets the resource owner grant access at their discretion via ACLs

Discretionary access control puts the access decision in the hands of the object's owner, who grants or revokes permissions, typically through an access control list attached to the object enumerating which subjects get read, write, or execute. Standard commercial operating-system file permissions are DAC. Its weakness is structural: any owner can pass access to anyone, so a compromised owner or a Trojan running with the owner's rights can leak data, which is why DAC is unsuitable for data that must be protected regardless of an owner's choices.

Trap Choosing DAC when the requirement says data must be protected regardless of the owner's wishes. Owner discretion is exactly what that requirement forbids.

5 questions test this

MAC enforces access from system-set labels and clearances that no owner can override

Mandatory access control removes owner discretion: the system decides access by comparing a subject's clearance against an object's classification under a central policy that not even the data's creator can override. This is the model for classified, military, and multilevel-secure systems holding data at several sensitivities at once. The exam tell is system-enforced labels plus the explicit absence of owner control.

Trap Confusing MAC with DAC because both deal with file access. The discriminator is discretion: MAC is system-enforced and non-overridable, DAC is owner-controlled.

3 questions test this

A security label is machine-enforced; a security marking is human-applied metadata

MAC runs on labels, not markings: a security label is the machine-readable association between a sensitivity level and a subject or object that the system parses and enforces, whereas a security marking is human-applied metadata that informs people but is not self-enforcing. Marking is human-enforced; labeling is system-enforced. MAC's mechanism depends on labels because the reference monitor must read sensitivity programmatically to mediate every access.

Trap Assuming a human-applied marking is what the reference monitor mediates on; only a machine-readable label is system-enforced, whereas a marking merely informs people.

Bell-LaPadula is MAC's confidentiality model: no read up, no write down

The formal confidentiality model behind MAC is Bell-LaPadula, whose Simple Security Property forbids reading above one's clearance (no read up) and whose Star property forbids writing below one's level (no write down), so classified data cannot flow down to a lower classification. For the authorization decision, the practical takeaway is that MAC enforces these label comparisons; the lattice mathematics itself is studied under security models. The pairing of 'no read up' with 'no write down' is the most testable detail.

Trap Swapping the two rules: 'no write down' is the Star property (protects against leaking down), and 'no read up' is the Simple Security Property; reversing them is a classic distractor.

3 questions test this

Even MAC can leak through covert channels by inference

Mandatory access control constrains explicit information flows between labels but does not stop covert channels, where higher-classified information is deduced by combining lower-classified observations. Labels govern direct access, not every inference a subject can draw. This is why a multilevel system needs covert-channel analysis beyond its label policy, and why 'MAC fully prevents data leakage' is an overstatement.

Trap Assuming label enforcement alone makes a multilevel system leak-proof; MAC controls explicit flows but not covert channels or inference, which need separate analysis.

RBAC assigns permissions to roles that mirror job functions, and users inherit them

Role-based access control grants permissions to roles modeled on job functions, and a subject acquires exactly the permissions of the roles they are assigned, nothing more. The administrative payoff is scale: a hire, transfer, or departure is handled by changing role assignments rather than editing thousands of individual permissions, making RBAC the default for large enterprises with stable job functions. Managed by role, it is also the natural control against privilege creep when assignments are reviewed.

Trap Assigning permissions directly to individual users and calling it RBAC; in RBAC permissions attach to roles and users inherit them through role membership, never via one-off grants.

1 question tests this

A database administrator is implementing RBAC using an access control matrix where roles replace individual users as subjects. The matrix…

RBAC role hierarchies and separation-of-duty constraints are part of the standard model

The authoritative RBAC standard (ANSI/INCITS 359) defines role hierarchies, where senior roles inherit the permissions of junior roles, and separation-of-duty constraints, which forbid one user from holding a conflicting pair of roles such as create-vendor and approve-payment. Separation of duty can be enforced statically at assignment time or dynamically at role-activation time. These constraints are how RBAC encodes least privilege and anti-fraud controls beyond simple role assignment.

Trap Treating separation of duty as only an assignment-time check; RBAC also supports dynamic SoD enforced at role-activation time, so a user may hold conflicting roles but not activate both at once.

10 questions test this

Rule-based access control applies the same global conditions to everyone, ignoring identity

Rule-based access control decides by whether a request matches a global rule, applied uniformly to all subjects regardless of who they are: a firewall ACL like 'deny inbound port 23 from any source' or a 'no logins outside business hours' policy gates everyone identically. Its defining trait is that the decision does not depend on the subject's identity, only on the request matching a rule. That identity-independence is the discriminator separating it from role-based control.

Trap Mistaking rule-based for role-based because the acronyms rhyme. Role-based decides by who you are (your role), rule-based decides by what the request is, ignoring identity entirely.

ABAC evaluates a policy over subject, object, action, and environment attributes

Attribute-based access control makes the decision by evaluating a policy over attributes of four categories: the subject (clearance, department), the object (classification, type), the action (read vs. delete), and the environment (time, location, device posture). Combining many attributes in one rule makes ABAC the most granular and dynamic model, able to express decisions like 'a nurse may read records of patients on her ward, on a managed device, during her shift' without RBAC's role explosion. NIST frames RBAC and ABAC as complementary, with a role usable as one attribute among many.

Trap Treating ABAC and RBAC as mutually exclusive; NIST frames them as complementary, with a role usable as just one subject attribute inside an ABAC policy.

5 questions test this

ABAC and zero trust enforce via a Policy Decision Point and Policy Enforcement Point

ABAC and zero-trust authorization are architected around two components: a Policy Decision Point (PDP) that evaluates the policy against the request's attributes and returns a verdict, and a Policy Enforcement Point (PEP) that actually allows or blocks the access. Separating the decision from the enforcement lets one policy engine govern many enforcement points. The PDP/PEP split is the same pattern NIST SP 800-207 uses for zero-trust access.

Trap Swapping the PDP and PEP roles; the PDP evaluates the policy and returns the verdict, while the PEP is the component that actually allows or blocks the access.

7 questions test this

Risk-based (RAdAC) access adapts the decision to a live risk score within a session

Risk-adaptive access control computes a real-time risk score from contextual signals (device health, anomalous location, behavior deviation, sensitivity of the request) and adapts the decision moment to moment: permit, deny, or step up to additional authentication. Its distinguishing property is adaptivity within a single session: the same user with the same role can be allowed one moment and challenged the next because the computed risk changed. RAdAC is typically realized as ABAC with risk treated as a first-class environmental attribute, underpinning adaptive authentication and zero-trust designs.

Trap Reading RAdAC as a one-time decision fixed at login; its defining trait is re-evaluating risk within a live session, so access can change moment to moment for the same user.

2 questions test this

Just-in-time access grants privilege only for the task and revokes it automatically

Just-in-time access control grants elevated or privileged rights only for the duration of a specific task and removes them automatically afterward, so accounts hold no standing privilege for an attacker to hijack. It is least privilege applied to time and the foundation of zero standing privilege, where a privileged role carries no rights at rest until a scoped, time-boxed, usually approved activation. JIT layers over whatever base model is in use, shrinking the exposure window rather than changing who may decide access.

Trap Believing permanent least-privilege admin roles solve the standing-privilege risk. A never-revoked role is still standing privilege; JIT's point is to remove the standing part, not just shrink the role.

3 questions test this

Least privilege caps the maximum; need-to-know decides which specific data within it

Least privilege restricts each entity to the minimum access required to accomplish its assigned tasks, and need-to-know is least privilege applied to information: a clearance sets the ceiling of what a subject could see, and need-to-know decides which specific data within that ceiling they actually require. The two work together: a Top Secret clearance does not grant access to every Top Secret document, only those the subject needs. Every authorization model is a mechanism for implementing least privilege.

Trap Assuming a clearance level alone grants access to all data at that level; clearance sets the ceiling, but need-to-know still gates which specific items the subject may see.

ABAC, RAdAC, and JIT extend an underlying model rather than replace RBAC

The modern models are additive, not rival: ABAC adds attribute-level granularity, RAdAC adds session-level adaptivity, and JIT adds a time limit, each layered on top of an underlying grant rather than substituting for RBAC or MAC. Treating them as mutually exclusive alternatives misreads how real systems combine them, e.g., roles expressed as ABAC attributes, with JIT controlling when privileged roles activate. The exam contrasts them on their distinct contribution, not as either/or.

Trap Reading ABAC, RAdAC, and JIT as either/or replacements for RBAC; they are additive layers that combine, such as roles expressed as ABAC attributes with JIT gating activation.

ABAC roles: PIP supplies attributes, the Context Handler orchestrates, obligations are mandatory

In an ABAC/XACML pipeline the Policy Information Point (PIP) acts as the source of attribute values the PDP lacks, drawn from directories and other sources, and the Context Handler coordinates the workflow, building the request context and requesting attributes from the PIP. The PDP returns Permit/Deny plus directives: an obligation MUST be carried out by the PEP (which denies access if it cannot discharge it), while advice MAY be safely ignored; if required attributes cannot be obtained the decision is Indeterminate.

Trap confusing the PIP (fetches attributes) with the PDP (decides) or treating advice as mandatory like an obligation

11 questions test this

ABAC cures RBAC role explosion by deciding on attributes at request time

Role explosion happens when an organization mints thousands of narrow roles to cover every combination of department, location, time, and project. ABAC eliminates this by evaluating subject, object, and environment attributes dynamically at access time, so no capability has to be pre-assigned to a subject or role before the request, collapsing many static roles into a few attribute policies.

Trap trying to fix role explosion by adding still more fine-grained RBAC roles instead of switching to attribute-based decisions

5 questions test this

Capability tables are matrix rows (subject-centric); ACLs are matrix columns (object-centric)

An access control matrix can be stored two ways: a capability table is a row attached to a subject listing every object it may access, so it answers 'what can this user reach?' efficiently. An ACL is a column attached to an object listing every subject that may access it, so it answers 'who can reach this file?' and makes object-centric revocation/decommissioning simple.

Trap swapping the two: ACLs are object-centric (columns), capability tables are subject-centric (rows)

9 questions test this

In DAC/ACL systems, explicit deny beats group allow, and the creator owns the object

ACL evaluation is order-sensitive: an explicit deny ACE for an individual overrides an allow granted via group membership (canonical order: explicit deny, explicit allow, inherited deny, inherited allow). Under DAC the creator of a new object becomes its owner regardless of the parent's owner. On Windows the DACL holds the access permissions while the SACL configures audit logging of access attempts.

Trap assuming a group allow grants access despite an individual explicit deny, or confusing the DACL (permissions) with the SACL (auditing)

4 questions test this

Also tested in

References

NIST glossary: reference monitor Whitepaper
NIST glossary: security label Whitepaper
NIST IR 7316: Assessment of Access Control Systems Whitepaper
NIST SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations Whitepaper
NIST SP 800-207: Zero Trust Architecture Whitepaper
Implementing Least-Privilege Administrative Models