Access Control Models are the formal rules that decide who may use a resource and what they may do with it. Every time you open a shared folder, log into a work system, or view a patient record, a model of this kind is quietly making a decision on behalf of the organization that runs it.
This article explains the main families of these models in plain language. It describes how each one works, where it fits well, where it struggles, and what questions a non-specialist can ask when deciding which approach a team or household should use.
Why a Single Yes or No Answer Hides a Lot of Design
Behind every permission prompt sits a question: should this person, device, or program be allowed to perform this action on this object? Answering that question consistently across thousands of files, accounts, and applications is difficult, and the answer depends on how the rules are organized.
Access control models are structured ways of organizing those rules. They define what counts as a subject, such as a user or service, what counts as an object, such as a file or database row, and what operations, such as read, write, or delete, are possible between them.
Choosing a model is therefore a design decision, not just a setting. A model that is easy to manage for a family may be unworkable for a hospital, and a model built for government classification may be far too rigid for a small business.
The Core Ideas Every Model Shares
Most models rely on three building blocks: subjects, objects, and a policy that links them. The policy is the set of rules, and it is enforced by a reference monitor, which is the part of a system that checks every request before access is granted.
A second idea is the difference between authentication and authorization. Authentication confirms who you are, for example with a password or a fingerprint. Authorization decides what that verified identity may do. Access control models are concerned with the second step.
A third idea is that access decisions should be made by default with no permission, then expanded deliberately. This default-deny stance is common in well-run systems because it limits the damage caused by a forgotten or mistaken grant.
Four Common Models and How They Differ
Security researchers and system designers usually describe four main families of access control models. Each one answers the question of who sets the rules in a different way, and each has characteristic strengths and weaknesses.
- Discretionary Access Control (DAC) lets the owner of a resource decide who else may access it, which is how most personal file sharing works.
- Mandatory Access Control (MAC) lets a central authority set rules that users cannot override, often used where labels such as classification levels matter.
- Role-Based Access Control (RBAC) grants permissions to roles such as accountant or administrator, and assigns people to those roles.
- Attribute-Based Access Control (ABAC) makes decisions from attributes of the user, resource, action, and environment, such as department, location, or time of day.
No model is universally better. DAC is flexible but can spread permissions unevenly. MAC is strict and predictable but harder to administer. RBAC simplifies management in stable organizations, while ABAC handles complex, changing conditions at the cost of more policy design work.
Discretionary Access Control in Practice
Discretionary Access Control is the model most people already use without naming it. When you share a document with a colleague or set a folder to be readable by a family member, you are exercising discretion as the owner of that object.
The advantage is convenience and autonomy. Owners can respond quickly to real needs without waiting for an administrator. The drawback is that permissions can drift. A file shared with a group may be re-shared by someone else, and over time nobody may know exactly who can read it.
To use DAC more safely, review shared items periodically, avoid broad groups such as everyone with link access, and remove access when a project or relationship ends.
Mandatory and Role-Based Models for Structured Settings
Mandatory Access Control moves the power to set rules away from individual owners and into a central policy. Labels attached to users and data are compared under fixed rules, so a user cannot grant access to something they are not cleared to see. This is valuable where confidentiality rules are strict and must be enforced regardless of what individuals prefer.
Role-Based Access Control is widely used in businesses and institutions. Instead of granting permissions person by person, administrators define roles that bundle the permissions a job needs. When someone changes positions, their role changes, and their access follows the new role.
RBAC works best when job functions are stable and clearly defined. Its common failure is role sprawl, where roles accumulate special exceptions until nobody can explain what a role actually permits.
Attribute-Based Control and Choosing Between Models
Attribute-Based Access Control expresses access as a rule over characteristics. A policy might say that engineers may read design files only from company-managed devices during business hours. This precision suits modern environments with remote work and many kinds of devices.
How Attribute-Based Decisions Are Made
An ABAC system evaluates a set of attributes each time a request arrives. Attributes can describe the requesting user, such as job title or clearance, the target resource, such as sensitivity label, the action requested, and the environment, such as the network used or the time.
Because decisions are computed from current attributes, changing an attribute immediately changes what is allowed. This is useful when people move between teams or when risk conditions change. It also means that attribute values must be accurate, since a wrong attribute produces a wrong decision.
Weighing Complexity Against Control
ABAC offers fine-grained control, but policies can become difficult to read and test. Writing a rule that behaves correctly in every combination of attributes requires careful analysis, and mistakes may only appear under unusual conditions.
For many small and mid-sized settings, a simpler combination works well, such as RBAC for everyday roles plus a few attribute conditions for sensitive data. Choosing the least complicated model that meets real requirements is usually the safest path.
Questions to Ask Before Adopting a Model
Begin by asking who needs to make access decisions and how often those decisions change. Ask whether confidentiality rules must be enforced even against the owner of the data, which points toward mandatory control. Ask whether job functions are stable, which suggests roles.
Ask who will maintain the policy and whether they can test it. A model that nobody can audit will drift toward unsafe permissions, regardless of its theoretical strength.
Access Control Models and Least Privilege
Every model becomes more secure when it is paired with the principle of least privilege, which says that subjects should receive only the permissions they need for their current task. Least privilege limits the harm from mistakes, stolen credentials, and malicious software.
In practice this means granting narrow roles, separating administrative accounts from everyday accounts, and removing access promptly when it is no longer needed. A household can apply the same idea by using a standard account for daily use rather than an administrator account.
Least privilege also works against scope creep, the gradual accumulation of access that nobody intended to grant. Periodic reviews, even a simple yearly list of who can reach what, help keep permissions aligned with real responsibilities.
Common Mistakes That Weaken Any Model
The most frequent error is granting broad access as a shortcut, such as giving a whole team administrator rights so that a single task can be completed. This quietly removes the protection the model was meant to provide and is hard to reverse once people depend on it.
Another mistake is leaving stale accounts active. When an employee leaves or a contractor finishes a project, their access should end on the same day. Accounts that outlive their purpose are a frequent route for unauthorized access.
A third problem is inconsistent enforcement, where the policy says one thing but a shared password, an exception list, or a forgotten folder says another. Documentation and regular testing reduce this gap.
A Simple Checklist for Applying Access Control Models
Applying an access control model does not require specialized tools for a small setting. A few disciplined habits can capture most of the benefit, whether you manage a home network, a small office, or a team project.
- Write down what each resource is, who needs it, and which actions each person actually performs.
- Choose the simplest model that matches those needs, and document why it was chosen.
- Grant access to groups or roles where possible instead of to individuals one by one.
- Remove access promptly when responsibilities end, and record who approved each exception.
- Review permissions on a regular schedule and test that the intended restrictions really hold.
These steps turn an abstract model into daily practice. They also make it easier to explain decisions to others and to notice when something has changed unexpectedly. Consistency over time is usually worth more than an elaborate design that nobody maintains.
Where to Go Next With Access Control
Once the basic models are clear, the next practical step is to examine a real system you use. Look at how it names roles, how it shares resources, and whether it offers an audit log that shows who accessed what and when. Comparing these features with the models described above builds useful intuition.
Readers who work in technical roles can deepen their understanding by studying published standards and vendor documentation for specific platforms, since implementation details matter. Public guidance from national standards bodies, such as the National Institute of Standards and Technology, is a dependable starting point, though readers should check current editions because guidance is revised over time.
Access control will remain central as systems become more distributed and devices more varied. Learning the vocabulary and trade-offs now provides a foundation that will serve you across many tools and changing circumstances.