Security controls exist to enforce a boundary between what is permitted and what is not. Access control is how that boundary gets defined and enforced at the level of users, systems, and data. Without it, authentication alone is not enough: knowing who someone is matters very little if there are no rules governing what they are allowed to do once inside.
What Access Control Actually Is
Access control is a collection of mechanisms that restrict or permit actions on a resource based on defined rules. Those resources can be files, databases, network segments, applications, physical spaces, or individual functions within a system. The rules can be as simple as "this user account may read this file" or as structured as a full policy engine evaluating roles, context, and environmental conditions before granting access.
NIST defines access control as the process of granting or denying specific requests to obtain and use information and related information processing services. That definition is deliberately broad because access control applies across physical security, network architecture, operating systems, and application logic.
The three core functions of any access control system are:
- Identification: establishing who or what is making a request
- Authentication: verifying that the claimed identity is genuine
- Authorization: determining what that verified identity is permitted to do
Authentication and authorization are often confused. Authentication answers the question "are you who you say you are?" Authorization answers the separate question "given that you are, what are you allowed to do?" Both are required for access control to function correctly.
Why It Matters
Access control failures are one of the most consistently cited causes of security incidents. OWASP lists broken access control as the top web application security risk, noting that access control weaknesses are present in a significant share of applications tested. When authorization logic is missing, misconfigured, or inconsistently applied, attackers can read data they should not see, modify records they should not touch, or escalate privileges beyond their assigned level.
From a CIA triad perspective, access control directly protects confidentiality by preventing unauthorized disclosure, and integrity by preventing unauthorized modification. It also supports availability indirectly: a well-scoped access control policy limits the blast radius of a compromised account, which reduces the damage an attacker can cause before detection.
How Access Control Models Work
Several models describe how authorization rules are structured. Understanding them helps clarify why different environments use different approaches.
Discretionary Access Control (DAC) lets the resource owner decide who has access. A file owner grants or revokes permissions at their own discretion. This is flexible but difficult to enforce consistently at scale, because control is decentralized across many individual owners.
Mandatory Access Control (MAC) removes that discretion. Access decisions are governed by a central policy based on labels or classifications assigned to both subjects and objects. A user with a "confidential" clearance level cannot access a "secret" resource regardless of what any individual owner might prefer. MAC is common in high-security and government environments.
Role-Based Access Control (RBAC) assigns permissions to roles rather than to individual users. A user inherits permissions by being placed in a role, for example "network administrator" or "read-only analyst." This makes large-scale permission management tractable because changing a role's permissions updates every user in it simultaneously. RBAC is the most widely deployed model in enterprise environments.
Attribute-Based Access Control (ABAC) evaluates a broader set of attributes before granting access: user department, device posture, time of day, location, and data sensitivity can all factor into the decision. ABAC is more expressive than RBAC and better suited to environments that need fine-grained, context-aware policy enforcement.
Common Pitfalls
Several patterns consistently weaken access control in practice.
Excessive privilege. Users and service accounts are granted more access than their role requires, often because it is easier to give broad access than to scope it precisely. When that account is compromised, the attacker inherits the excess access. The principle of least privilege, granting only the minimum permissions needed to perform a function, exists specifically to address this.
Inconsistent enforcement. Access rules applied at the user interface but not enforced at the API or database layer are not real controls. Attackers routinely bypass front-end restrictions by interacting directly with backend services. Authorization logic must be enforced at every layer where access to a resource is possible.
Stale permissions. Access granted for a specific project or role does not always get removed when the need ends. Over time, accumulated permissions create a much larger attack surface than any current role justifies. Regular access reviews and automated de-provisioning workflows reduce this drift.
Default configurations. Many systems ship with permissive default settings because they prioritize ease of setup over security. Deploying without hardening those defaults leaves access controls weaker than the system is capable of enforcing.
Access Control and Security Posture
Access control is not a single setting or a one-time configuration. It is an ongoing practice that requires clear policies, consistent technical enforcement, and regular review. A sound posture treats least privilege as a default, enforces authorization at every layer, and audits who has access to what on a defined schedule.
It also connects to broader principles like zero trust, which treats every access request as unverified until proven otherwise regardless of network location. Whether an organization has formally adopted a zero trust architecture or is still working with more traditional perimeter models, the access control fundamentals remain the same: define who can access what, verify identity before granting it, and limit the scope of that grant to what is strictly necessary.