What Is Access Control? Models and the AAA Flow

Most breaches you will investigate are not exotic. They are an account that could reach something it never should have. A help-desk technician's token that opened a domain controller. A service account with a password from 2019 that still held write access to a finance share. A contractor who kept their access two months after the contract ended. In every case the malware, if there was any, was the easy part. The access was already there, granted and forgotten, waiting for whoever logged in.

Access control is the discipline that decides who can do what to which resource, and the set of controls that enforce that decision. NIST defines it as "the process of granting or denying specific requests to obtain and use information and related information processing services." This guide covers what that means in practice: the three questions every access decision answers, the AAA flow that structures the answer, the four models that implement it (DAC, MAC, RBAC, and ABAC), how they compare, and how least privilege and zero trust set the bar a real deployment has to clear. It is written for the people who reason about access after the fact: SOC analysts, DFIR responders, and identity engineers who have to explain why a request was allowed.

What is access control?

Access control is the process of deciding whether a given subject is allowed to perform a given action on a given resource, and enforcing that decision. A subject is whoever or whatever makes the request: a user, a process, a service account, a workload calling an API. The resource is the thing being acted on: a file, a database row, an API endpoint, a building door. The action is the verb: read, write, delete, execute, approve.

Every access decision answers three questions. Who are you? What are you allowed to do? And, after the fact, what did you do? Those three map to the AAA model that structures most access systems: authentication, authorization, and accounting. Authentication establishes identity. Authorization decides what that identity may do. Accounting records what it actually did. Confusing the first two is the single most common source of access failures: proving who you are is not the same as being allowed to act, and a system that treats a valid login as automatic permission is the system that hands a stolen credential the keys.

Access control is not one product. It is a property enforced by many: the operating system's file permissions, the directory that holds group memberships, the application's own authorization logic, the cloud provider's IAM policies, the firewall's rules. The model below is what gives those scattered enforcement points a common language, so a decision made in the directory is honored at the resource.

The AAA flow: authentication, authorization, accounting

AAA is the spine of access control. It splits a single access event into three distinct steps, and keeping them distinct is what makes the system auditable.

Authentication answers "who are you?" The subject presents a credential, a password, a certificate, a hardware key, a token, and the system verifies it against what it knows. Multi-factor authentication strengthens this step by requiring more than one kind of proof. Authentication produces an identity, nothing more. It does not grant access. A successfully authenticated attacker with a phished password is still authenticated; that is precisely why authentication alone is never the control.

Authorization answers "what are you allowed to do?" Given a verified identity, the system evaluates whether this subject may perform this action on this resource. This is where the access control models live: DAC, MAC, RBAC, and ABAC are four different ways of computing the authorization answer. NIST defines authorization as the "access privileges granted to a user, program, or process." Authorization is the step that actually protects the resource, and it is the step most worth getting right.

Accounting answers "what did you do?" The system logs the access: who, what, when, from where, allowed or denied. Accounting is the step defenders live in. Without it, an investigation has no record of what an account touched, and a permission review has no evidence of what access was actually used versus merely granted. Log the inputs to a decision, not just its outcome, or post-incident reconstruction becomes guesswork.

The three run in order, and each depends on the one before. Skip authentication and authorization has no identity to reason about. Skip authorization and authentication becomes a free pass. Skip accounting and you lose the only record that lets you answer "what happened?" later.

The four access control models

Authorization needs a model: a consistent rule for turning a request into an allow or a deny. Four models dominate, and they differ in who sets the rules and what the decision is based on. Each emerged to solve the limits of the one before it.

Discretionary access control (DAC) lets the owner of a resource decide who else can access it. The classic example is Unix file permissions or a shared folder where the creator grants read or write to specific users. It is flexible and intuitive, which is why it is everywhere. Its weakness is also the owner's discretion: access spreads informally, owners over-grant to avoid friction, and there is no central policy guaranteeing that confidential data stays confidential. A user who can read a file can usually copy it somewhere with weaker permissions.

Mandatory access control (MAC) removes that discretion. A central authority sets the policy, and it is enforced uniformly across every subject and object regardless of what an owner wants. NIST defines MAC as "an access control policy that is uniformly enforced across all subjects and objects within a system," where subjects cannot pass their access to others or change security attributes. The textbook implementation labels every resource with a classification (confidential, secret, top secret) and every subject with a clearance, and permits access only when the clearance dominates the classification. MAC is rigid and high-assurance, which is why it shows up in military, government, and systems like SELinux, and why it is overkill for an ordinary business file share.

Role-based access control (RBAC) grants permissions to roles, then assigns subjects to roles. Instead of managing permissions per user, you manage them per job function: a "finance-analyst" role carries a fixed set of permissions, and everyone in finance inherits them by holding the role. RBAC was formalized in 1992 by David Ferraiolo and Rick Kuhn at NIST and standardized as ANSI/INCITS 359 in 2004, and it became the predominant access model in enterprises because it maps cleanly onto how organizations are actually structured. Its failure mode is scale: when access depends on context a role cannot express, teams invent more and more narrow roles to compensate, ending in "role explosion," thousands of roles like finance-readonly-emea-contractor that each freeze one decision in place.

Attribute-based access control (ABAC) computes the decision at request time from attributes of the subject, the resource, the action, and the environment, rather than from a static role. It can express rules a role cannot: permit this export only if the user's clearance dominates the data's classification, the device is compliant, and the request comes from inside the corporate network during business hours. ABAC is the most granular and context-aware model and the enforcement layer underneath most zero trust designs, at the cost of needing clean attribute data and governed policy. It is its own deep topic; see the attribute-based access control (ABAC) breakdown for the PDP/PEP flow and the full ABAC vs RBAC comparison.

Access control models compared

The four models are not a ranking. They are answers to different questions about who controls access and what the decision depends on. The right choice is the simplest model that expresses the policy you actually need.

Two things matter more than the cells. First, these models layer rather than compete. A modern environment often runs RBAC for the broad strokes, a role gets you into the application, and ABAC on top for the context-sensitive cases, where attribute policy decides what that role can actually do given the device, the data sensitivity, and the time. NIST documents this RBAC-plus-ABAC hybrid as a normal and recommended path, not a compromise.

Second, auditability runs opposite to power. DAC and RBAC are easy to inspect: you read the permissions or the role assignments and you know who has access. MAC and ABAC are more expressive but harder to answer "who can reach this?" against, because the decision depends on labels or runtime attributes rather than a static list. That trade-off is the defender's problem at investigation time, and it is the reason accounting matters more, not less, as models get richer.

Least privilege: the principle that governs all four

A model decides how access is computed. Least privilege decides how much access should exist in the first place, and it applies no matter which model you run. NIST states it plainly: a system "should restrict the access privileges of users (or processes acting on behalf of users) to the minimum necessary to accomplish assigned tasks." Grant the least access a subject needs to do its job, and nothing more.

Least privilege is the control that would have stopped most of the breaches in this article's opening. The help-desk token that opened a domain controller, the service account with standing write to finance, the contractor who kept access after leaving, each is a least-privilege failure, not a model failure. The model granted what it was told to grant; the policy told it to grant too much.

In practice least privilege means a few concrete habits. Default to deny, then grant what is needed. Scope permissions to the specific resource and action rather than a broad wildcard. Time-box access that is only needed temporarily, especially for contractors and break-glass administrative use. And review what was actually used against what was granted, because access that is granted and never used is pure risk. The opposite of least privilege is "privilege creep," the slow accumulation of access as people change roles and old grants are never revoked, and it is what gives an attacker who lands on one account a path to everything that account was ever allowed to touch. Over-broad access is also the precondition for privilege escalation: the less standing privilege an account holds, the less an attacker gains by stealing it.

Zero trust: access control with no implicit trust

Zero trust is where modern access control is heading, and it is best understood as a strict reading of the principles above rather than a new model. NIST SP 800-207, the *Zero Trust Architecture* publication from August 2020, defines it as a shift away from "static, network-based perimeters" toward verifying every request on its own merits. The slogan is "never trust, always verify." The substance is that being inside the network, or having authenticated once, grants nothing. Every access request is evaluated in context, every time.

That has direct consequences for access control. Authentication stops being a gate you pass once and becomes a continuous check. Authorization stops being a static role lookup and becomes a per-request decision that weighs context: the device's posture, the user's location, the sensitivity of the resource, the current risk level. NIST's architecture splits this into a policy decision point that makes the call and a policy enforcement point that carries it out, and the model that naturally fits that per-request, context-driven decision is ABAC. Zero trust is the goal; least privilege is the principle; ABAC is the mechanism that turns "verify in context" into a concrete allow or deny.

For a defender, zero trust changes what good telemetry looks like. When every request is authorized in context, every request is also a logged decision with its inputs, which is exactly the accounting record an investigation needs. The same design that tightens access also produces the evidence to reconstruct it, provided someone configured the logging to capture the decision inputs and not just the outcome.

How access control fails in real incidents

The reason access control sits at the center of so many investigations is that its failures are quiet. Nothing alarms when an account uses access it was legitimately granted, even when that grant was a mistake. Four failure patterns recur.

Over-provisioning. The account had more access than its job required, so compromising it returned more than it should have. This is the least-privilege failure, and it is the most common root cause behind a small intrusion becoming a data breach.

Stale access. Permissions that should have been revoked were not: a departed employee, a finished contractor, a deprecated service. Joiner-mover-leaver hygiene is access control's unglamorous core, and the "leaver" step is the one most often skipped.

Standing privilege. Administrative access that exists all the time rather than being requested when needed. Standing admin rights are a permanent target; just-in-time access that grants and then expires shrinks that target to the moments it is actually in use.

Confused authentication and authorization. A system that treats a valid login as automatic permission. This is the design flaw behind broken-access-control vulnerabilities in applications, where the server authenticates a user and then trusts the client to ask only for what it should, instead of authorizing every request on the server side.

The thread is that none of these are exotic attacks. They are access decisions that were made too broadly, never revisited, or never enforced at the right step. That is why access control is a defender's discipline as much as an architect's: the artifacts an investigation produces, who had access, who used it, what was logged, are the same artifacts a sound access control program is built on.

The bottom line

Access control decides who can do what to which resource, and it is enforced through the AAA flow: authentication proves identity, authorization grants action, accounting records the result. The four models, DAC, MAC, RBAC, and ABAC, are different ways of computing the authorization answer, and they differ in who sets the rule and what the decision depends on. They layer more often than they compete, with RBAC for the broad strokes and ABAC for the context-sensitive cases.

The principle that governs all four is least privilege: grant the minimum, revoke what is unused, and the blast radius of a stolen credential shrinks to almost nothing. Zero trust is that principle taken to its limit, every request verified in context, with no trust earned by being inside or by having logged in once. For a defender, the payoff is concrete. The same discipline that grants access tightly is the one that produces the records, who had access, who used it, what was logged, that turn an investigation from guesswork into evidence.