Access control is the process of deciding who gets in and what they’re allowed to do once inside. Whether it’s a keycard opening an office door or a login screen on a website, every access control system follows the same basic logic: figure out who you are, confirm you’re telling the truth, check what you’re allowed to access, and keep a record of what you did. That four-step process applies to everything from your phone’s lock screen to a government data center.
The Four Steps Behind Every Access Decision
Every access control system, physical or digital, runs through four stages. Security professionals call this the IAAA framework: identification, authentication, authorization, and accountability.
Identification is simply claiming to be someone. You swipe a badge, type a username, or scan an ID card. At this point the system hasn’t verified anything. It just knows what identity you’re presenting.
Authentication is where the system checks whether that claim is true. It compares what you’ve provided (a password, a fingerprint, a security token) against what it has on file. If there’s a match, the system believes you are who you say you are.
Authorization happens next. Being authenticated doesn’t mean you can go everywhere or see everything. Authorization determines your specific privileges: which files you can open, which rooms you can enter, which actions you can perform. A junior employee and a department head might both authenticate successfully but have very different levels of access.
Accountability ties everything together by logging what each person does. If a sensitive file is deleted or a restricted door is opened at 2 a.m., the system can trace that action back to a specific individual. Without accountability, there’s no way to investigate problems or enforce rules after the fact.
How Systems Verify Your Identity
Authentication relies on factors, and there are five main categories. Most systems use at least one; high-security environments combine two or more in what’s called multi-factor authentication.
- Knowledge factors: Something you know, like a password, PIN, or security question answer. These are the most common and the easiest to compromise.
- Possession factors: Something you physically carry. A hardware security key, a smart card, or a phone that receives one-time codes all fall into this category.
- Inherence factors: Something you are. Fingerprints, facial recognition, iris scans, and voice recognition all use unique biological traits to confirm identity.
- Location factors: Where you are when you request access. A system might check your IP address or network location and flag requests that come from unexpected places.
- Behavior factors: How you interact with a device. Drawing a specific unlock pattern on a phone screen or the particular rhythm of your typing can serve as authentication.
When you log into your bank and it asks for your password plus a code texted to your phone, that’s two-factor authentication combining knowledge (password) with possession (phone). The more factors required, the harder it is for someone else to impersonate you.
Four Models for Deciding Who Gets Access
Once the system knows who you are, it needs rules for what you’re allowed to do. Organizations choose from several models depending on how much control they need and how flexible access policies should be.
Discretionary Access Control (DAC) puts the owner of a resource in charge. If you create a document, you decide who else can view or edit it. This is how file sharing works on most personal computers and cloud storage platforms. It’s flexible but relies on individual users making good security decisions.
Mandatory Access Control (MAC) takes that choice away from individuals. The system itself enforces access rules based on security classifications, and no user can override them. Government and military environments use MAC because the stakes of a wrong decision are too high to leave to individual judgment.
Role-Based Access Control (RBAC) assigns permissions based on job function rather than individual identity. An “accountant” role might have access to financial records but not engineering files, while a “developer” role gets the opposite. When someone changes jobs, you update their role instead of reconfiguring dozens of individual permissions. Most mid-size and large organizations use some form of RBAC because it scales well.
Attribute-Based Access Control (ABAC) is the most flexible model. Instead of relying on a single factor like role, it evaluates multiple attributes at once: your department, security clearance level, location, time of day, the sensitivity of the resource you’re requesting, and more. ABAC can replicate what any of the other models do, and it handles complex, context-dependent rules that RBAC alone can’t express. A policy like “analysts in the finance department can view quarterly reports only during business hours and only from the office network” is an ABAC rule.
Physical Access Control Systems
When people think of access control, locked doors and security badges often come to mind first. Physical access control systems use dedicated hardware working together in a chain.
The process starts at an access point, which is the physical barrier itself: a locking door, a turnstile, or a gate. Next to it sits a credential reader, the device that reads your badge, smart card, or key fob. In higher-security facilities, a keypad for PIN entry or a biometric reader for fingerprints or iris scans sits alongside the card reader, requiring a second factor before the door opens.
Behind the scenes, a control panel receives data from the reader, checks it against a database of authorized credentials, and makes the access decision. An access control server manages the broader system: registering new employees, enrolling credentials, granting or revoking authorization, and logging every event. If your badge is deactivated after you leave a company, it’s the server that records that change and pushes it to every control panel in the building.
How Digital Access Control Works Behind the Scenes
In software systems, access decisions follow a logical flow between two components. A policy enforcement point is the gatekeeper that intercepts your request. When you try to open a file, load a web page, or call an API, the enforcement point catches that request before it goes through. It then passes the details to a policy decision point, which evaluates the request against the organization’s rules and returns a yes or no answer. The enforcement point carries out that decision, either granting or blocking access.
This separation matters because it means you can change your security policies in one place (the decision point) without rewriting every application that enforces them.
Protocols That Connect Systems
Modern organizations use multiple applications, and employees shouldn’t need a separate login for each one. Three protocols handle this in different ways.
SAML is a standard for single sign-on. It lets a central identity provider authenticate you once and then pass proof of that authentication to other applications and services. You log in once in the morning and can access your email, project management tool, and HR portal without re-entering credentials.
OAuth 2.0 handles authorization, not authentication. When you let a third-party app access your Google Drive files without giving it your Google password, that’s OAuth. The app receives a limited access token instead of your actual credentials, and that token can be restricted to specific actions and set to expire.
OpenID Connect builds authentication on top of OAuth 2.0. It adds a layer that verifies your identity and issues a standardized ID token containing your profile information. Many “Sign in with Google” or “Sign in with Apple” buttons use OpenID Connect under the hood.
The Principle of Least Privilege
One rule ties good access control together: give people the minimum access they need to do their job, and nothing more. This is the principle of least privilege, and it limits the damage that can happen if an account is compromised or a person makes a mistake.
In practice, applying this principle means understanding exactly what permissions each role or application actually requires, then removing everything else. Organizations that do this well audit permissions regularly, revoke access that’s no longer being used, and review privileges whenever someone changes roles. The most common failure isn’t setting permissions too tightly. It’s granting broad access early on for convenience and never scaling it back, so people accumulate permissions over time that they no longer need.
Why Broken Access Control Is the Top Security Risk
Access control that’s poorly implemented is one of the most exploited weaknesses in web applications. The Open Web Application Security Project (OWASP) ranks broken access control as the number one security risk in its most recent Top 10 list. That means it’s more commonly exploited than injection attacks, cryptographic failures, and every other category of web vulnerability.
Broken access control happens when a system fails to enforce its own rules. Common examples include users being able to view other people’s accounts by changing a number in a URL, regular users accessing admin functions because the system only hides the button rather than actually restricting the action, or APIs that don’t verify permissions on every request. These aren’t exotic attacks. They’re straightforward failures of the basic four-step process: the system either skipped the authorization check or implemented it inconsistently.
Building access control correctly means enforcing checks on the server side for every request, denying access by default rather than granting it, and testing regularly to make sure users can’t reach resources outside their intended scope.