RBAC, ABAC, MAC, or DAC: The Access Control Choice Behind Most Breaches
October 13, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Choosing between RBAC, ABAC, MAC, and DAC is not a vocabulary exercise. It is the decision that determines whether a terminated employee's account still opens the finance server, whether a contractor can see records outside their case load, and whether an attacker who steals one login can move freely through your network. Get the model wrong for the system and you have built the exact weakness attackers look for first.
What's the Actual Difference Between RBAC, ABAC, MAC, and DAC?
Each model answers the same question, "who can do what to which resource," but assigns that decision to a different party using different logic. Role-based access control (RBAC) grants permissions based on job function, discretionary access control (DAC) lets the resource owner decide, mandatory access control (MAC) enforces a fixed classification scheme set by a central authority, and attribute-based access control (ABAC) evaluates a combination of user, resource, and environmental attributes at the moment of the request.
The practical differences show up in who can change access and how fast the system can adapt.
| Model | Who decides access | Best fit | Main weakness |
|---|---|---|---|
| DAC | Resource owner | Small teams, file shares | Owners over-grant, permissions drift |
| RBAC | Central admin, by role | Mid-size orgs with stable job functions | Role explosion, stale roles after reorgs |
| MAC | System-enforced classification | Government, defense, highly regulated data | Rigid, expensive to administer |
| ABAC | Policy engine evaluating attributes | Cloud, zero trust, dynamic workforces | Complex policy authoring, harder to audit manually |
None of these models is objectively better. A hospital using MAC-style clearance for a small records room would be paralyzed, and a bank running pure DAC on customer account systems would fail its next audit. The skill CISSP Domain 5 actually tests is matching the model to the operational reality of the system, not reciting definitions.
Why Does Broken Access Control Still Top the Vulnerability Charts?
Broken access control has held the number one spot on OWASP's Top 10 list of application security risks since the 2021 update, and it stayed there because the failure is structural, not a single bad line of code. OWASP's own testing data found that the large majority of applications assessed showed some form of broken access control, which is why the category displaced the risks that had previously held the top spot.
That figure matters because it is not describing exotic attacks. It describes ordinary RBAC roles that were never trimmed, ABAC policies that never accounted for a new attribute, and DAC permissions an owner granted once and forgot. Verizon's 2024 Data Breach Investigations Report reinforces the same pattern from the incident response side, where credential misuse and privilege-related breaches remain among the most common ways attackers establish and expand a foothold once they are inside.
Access control failures also map to specific, catalogued weaknesses. The Common Weakness Enumeration database groups dozens of these flaws under a single OWASP category, which is one reason the exam treats access control models as a foundational topic rather than a footnote.
How Do You Pick the Right Model for a Real System?
You start with how fast the population of users and resources changes, not with which model sounds most modern. A system with a stable set of job functions and infrequent reorganizations is a good candidate for RBAC, because the administrative overhead of maintaining roles stays manageable.
Think about a mid-size hospital billing department versus a research hospital running multiple grant-funded studies. The billing department has a small, stable set of roles, biller, supervisor, auditor, so RBAC keeps administration simple and audits predictable. The research environment has data sensitivity that varies by study, funding source, and consent terms attached to individual patient records, which is a much better argument for ABAC, because no fixed role can encode every combination of who should see what.
A system where access depends on shifting context, device posture, location, time of day, or data sensitivity that varies per record is a poor fit for RBAC and a strong fit for ABAC. This is exactly the logic behind NIST's guide to attribute-based access control, which frames ABAC as a model built for environments where a static role cannot capture every condition that should affect an access decision. Cloud platforms and zero trust architectures lean on this same logic, evaluating attributes continuously rather than granting a role once and trusting it indefinitely.
MAC still earns its place where the cost of a wrong access decision is measured in classified disclosure or life safety, which is why it persists in defense and intelligence systems despite its administrative rigidity. DAC survives in small teams and collaborative file systems precisely because its flexibility is the point, not a flaw, as long as someone is watching for over-sharing.
Most mature enterprises do not run one model in isolation. A common pattern is an RBAC baseline that assigns broad access by job function, layered with ABAC-style conditions that narrow or expand that access based on device compliance, network location, or the sensitivity of the specific record being requested. That layering is exactly why the exam expects you to understand each model on its own before you can reason about how they combine, because a scenario question will often describe a hybrid system and ask you to identify which layer failed.
The access enforcement control inside NIST Special Publication 800-53 does not mandate a single model. It requires that the organization define and enforce approved authorizations consistently, which is the real test: not which acronym you chose, but whether the system actually enforces what you designed.
What Happens When Access Control Decays Over Time?
Access control fails less often at design time and more often during the joiner-mover-leaver lifecycle, when nobody owns the cleanup. A promotion that adds a new role without removing the old one, a contractor whose access was never scoped to a project end date, or a terminated employee whose credentials remain active for days all turn a correctly designed model into an incorrectly enforced one.
This is where the exam's focus on access control connects directly to incident response. When an investigation traces unauthorized access back to a departed employee's still-active account, the root cause is rarely the model itself. It is the absence of a deprovisioning process that keeps the model honest.
A functioning identity lifecycle process typically closes three gaps that access control models alone cannot:
- Timely removal of access when someone leaves, changes teams, or ends a contract, rather than a quarterly cleanup that leaves weeks of exposure
- Periodic recertification where a manager or data owner actively confirms that existing access still matches a real business need
- A record of who approved each grant, so an auditor or investigator can trace an access decision back to a person, not just a system log
Forge University's resources hub breaks down how access reviews, recertification cycles, and provisioning workflows fit into the broader identity and access management picture the CISSP exam expects you to defend.
Zero trust architectures try to close this gap by removing standing trust altogether. NIST's zero trust architecture framework describes a model where a policy engine evaluates each access request against current attributes rather than relying on a session or role granted earlier and assumed to still be valid. That shift is effectively ABAC applied continuously, and it is a direct response to how badly static access decisions age.
How CISSP Domain 5 Trains You to Own This Decision
Domain 5 does not test whether you can define DAC, MAC, RBAC, and ABAC in isolation. It tests whether you can look at a described system, its data sensitivity, its user population, and its change velocity, and argue for the model that fits, including the tradeoffs you are accepting. That is the same argument a security architect makes in a design review and the same one an auditor expects to hear defended, not recited.
Building that judgment takes more than flashcards, because the exam questions are written as scenarios with competing constraints, not definition matching. Forge University's CISSP certification prep works through access control model selection using the same kind of scenario-based practice, pairing each model with the operational conditions that make it the right or wrong call. If you are ready to start training on this domain alongside the rest of the exam blueprint, you can sign up and work through it at your own pace.
The organizations that get breached through broken access control usually had a model on paper. What they were missing was the discipline to keep enforcement matched to that design as the system changed underneath it. That gap between the model you chose and the access you are actually enforcing is exactly what Domain 5 is built to close.