Access control models — SY0-701
Master the four access control models — MAC, DAC, RBAC, and ABAC — and the key distinctions CompTIA Security+ (SY0-701) tests in Domain 4.
WHAT IT IS
Access control is the process of granting or denying specific requests to obtain and use information and related information processing services (NIST CSRC Glossary, citing NIST SP 800-192). The model is the policy framework that determines how those decisions are made — who controls access rights, and on what basis.
Four models appear on the exam: Mandatory Access Control (MAC), Discretionary Access Control (DAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC).
Mental model
Think of access control models as answering one question: who — or what — holds the authority to grant access?
- MAC — a central authority holds it, enforced uniformly by policy labels and clearances.
- DAC — the object owner holds it, and can delegate it.
- RBAC — a job role holds it; users inherit permissions by virtue of their assigned role.
- ABAC — a policy engine holds it, evaluating combinations of subject, object, and environment attributes at decision time.
When to use it
| Model | Who controls access? | What drives the decision? | Key characteristic |
|---|---|---|---|
| MAC | Central authority (system/organization) | Sensitivity labels on objects + clearance level of subjects | Users cannot override; access rights are non-discretionary |
| DAC | Object owner | Owner's choice | Owner can grant or pass access rights to others |
| RBAC | Organization (via role assignment) | Role membership | Permissions are tied to roles, not individuals; users inherit via role |
| ABAC | Policy engine | Attributes of subject, object, and environment | Fine-grained; can evaluate dynamic conditions (time, location, etc.) |
MAC — appropriate when the organization must prevent any user from unilaterally reclassifying or redistributing information. NIST SP 800-53 Rev. 5 describes MAC as a policy uniformly enforced across all subjects and objects such that users cannot pass information to unauthorized parties, grant privileges to others, or modify security attributes.
DAC — appropriate when flexibility is needed and owners are trusted to manage access. NIST defines DAC as a policy that leaves a certain amount of access control to the discretion of the object's owner, or anyone else authorized to control that object's access (NIST SP 800-53 Rev. 5 via NIST CSRC Glossary).
RBAC — appropriate when access aligns with defined job functions. NIST defines it as access control based on user roles, where a collection of access authorizations reflects permissions needed for defined organizational functions, and role permissions may be inherited through hierarchies (CNSSI 4009-2015 via NIST CSRC Glossary).
ABAC — appropriate when access decisions require combining multiple attributes. NIST SP 800-162 defines it as access rights granted through policies that combine attributes together, evaluating user, resource, and environmental attributes.
COMMON MISCONCEPTION
The trap: confusing who holds authority with who requests access.
In MAC, the fact that a user owns a file does not allow them to grant another user access to it. The system enforces access based on sensitivity labels and clearance levels — the owner's preference is irrelevant. NIST SP 800-192 states that in MAC, access is restricted "based on the sensitivity (as represented by a label) of the information contained in the system resource and the formal authorization (i.e., clearance) of users."
In DAC, by contrast, the owner does have that authority. A subject authorized to control an object can pass access rights to others (NIST SP 800-53 Rev. 5 via NIST CSRC Glossary).
A second common confusion: RBAC is sometimes mistaken for a form of MAC because an organization centrally assigns roles. It is not MAC. The decision driver is role membership, not sensitivity labels and clearances. RBAC does not prevent a properly-authorized administrator from granting an individual elevated role access — MAC would not allow that unilateral override.
A third misconception: ABAC is often described as "more flexible than RBAC." This is accurate in that ABAC can incorporate environmental attributes (NIST SP 800-162), but flexibility does not make ABAC a replacement for MAC in high-sensitivity environments — the enforcement model is fundamentally different.
How it shows up on the exam
The cognitive target here is distinguishing models by their enforcement mechanism and authority source, not just recognizing their names.
Scenario-based questions will describe an environment — a military classification system, a file server where users set permissions, a healthcare system where access is tied to job titles, a policy engine that evaluates device posture at login time — and ask which model is in use.
Signal phrases to watch for:
- "labels," "clearance," "classification level," "uniformly enforced," "cannot reclassify" → suggests MAC
- "owner controls," "user-defined permissions," "discretion of the owner" → suggests DAC
- "job function," "role assignment," "inherit permissions" → suggests RBAC
- "combination of attributes," "environmental conditions," "subject and object attributes" → suggests ABAC
Candidates often confuse DAC with RBAC because in both models individual users can end up with different permissions than one another. The distinguishing question is: does the owner decide (DAC), or does the role decide (RBAC)?
The principle of least privilege — granting only the minimum access necessary for assigned tasks (NIST SP 800-53 Rev. 5) — is a design goal that any of these models can implement, but it is not a model itself. Exam questions may probe whether a candidate conflates least privilege with a specific access control model.
Related concepts
Sources
Every claim on this page traces to the public exam blueprint and official documentation: