Access control and permissions — SY0-701
Security+ SY0-701 reference: access control and permissions — models (DAC, MAC, RBAC, ABAC), least privilege, and authorization vs. authentication distinctions.
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 SP 800-12 Rev. 1 / FIPS 201-3). A permission is "authorization to perform some action on a system" (NISTIR 7316). Together, these two ideas form the mechanism that enforces who can do what to which resource.
Authorization — "the right or a permission that is granted to a system entity to access a system resource" (NIST SP 800-82r3) — is the decision that access control enforces. A privilege is "a right granted to an individual, a program, or a process" (CNSSI 4009-2015).
Mental model
Think of access control as a door policy, not the door lock itself. The lock is authentication ("are you who you say you are?"). The door policy is access control ("even if it's really you, are you allowed in here, to do this, right now?"). Every access control model answers that second question differently — by ownership, by label, by role, or by attributes.
When to use it
The exam frequently requires you to distinguish the four main access control models. Each model answers the question "who decides access?" in a fundamentally different way.
| Model | Deciding authority | Core mechanic | Grounded definition (NIST) |
|---|---|---|---|
| Discretionary (DAC) | Object owner | Owner grants or passes rights to others | "A subject that has been granted access to information can… pass the information to other subjects or objects; grant its privileges to other subjects" (CNSSI 4009-2015) |
| Mandatory (MAC) | Central policy authority | Sensitivity labels + clearance levels enforce access; owners cannot override | "Restricting access to system resources based on the sensitivity… of the information… and the formal authorization (i.e., clearance) of users" (NIST SP 800-192) |
| Role-Based (RBAC) | Role assignment | Permissions tied to roles, not individuals; roles align with organizational functions | "A model for controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities" (NIST SP 800-95) |
| Attribute-Based (ABAC) | Policy engine | Access granted or denied by evaluating subject attributes, object attributes, and environment conditions against policy | "Subject requests… are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies" (NIST SP 800-162) |
Quick signal: If a scenario gives an owner the power to share their own files, think DAC. If a scenario enforces labels that even the owner cannot override, think MAC. If access is assigned by job function across many users, think RBAC. If the decision requires multiple factors — user department AND time-of-day AND resource classification — think ABAC.
COMMON MISCONCEPTION
The most common trap is treating authentication and access control (authorization) as the same thing. They are sequential but distinct steps. Authentication establishes identity; access control uses that established identity to decide what actions are permitted. A user can be successfully authenticated and still be denied access to a specific resource — that denial is access control working correctly, not an authentication failure.
A second trap is believing that DAC is inherently less secure than MAC simply because owners control access. The distinction the NIST definitions draw is about who holds authority, not about strength of enforcement. MAC prevents owners from bypassing sensitivity labels; DAC grants owners discretion. Neither label implies a global security ranking.
Third: the principle of least privilege — "a security architecture is designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function" (NIST SP 800-53 Rev. 5) — is a design principle that can be applied within any of the four models above. Least privilege is not itself an access control model.
How it shows up on the exam
The cognitive target for this concept is analysis: you are given a scenario describing an organizational context and asked to identify the appropriate access control model, or to identify a gap between what is in place and what the principle of least privilege requires.
Signal phrases that indicate an access control question:
- "Users can grant access to their own files" — points toward DAC
- "Access is determined by classification labels and clearance levels" — points toward MAC
- "Access is assigned based on job function" — points toward RBAC
- "Access depends on department, time, device type, and resource sensitivity simultaneously" — points toward ABAC
- "A user has more permissions than needed for their role" — points toward a least-privilege violation
Candidates often confuse authorization (the decision) with authentication (the verification step that precedes it). Grounding your reasoning in NIST SP 800-82r3 — "the right or a permission that is granted to a system entity to access a system resource" — keeps the two concepts cleanly separated in scenario analysis.
Related concepts
- Network Segmentation — divides a network into zones, complementing access control by limiting lateral movement even if permissions are misconfigured.
- Least Privilege — the design principle that scopes permissions to the minimum necessary; applies across all access control models.
- System Hardening — the process of reducing a system's attack surface, of which tightening access permissions is a central activity.
Sources
Every claim on this page traces to the public exam blueprint and official documentation: