Updated September 16, 2026.
The three access-control models commonly grouped together are discretionary access control (DAC), mandatory access control (MAC), and role-based access control (RBAC). Attribute-based access control (ABAC) is another important model; there is no rule that all access-control design must fit exactly three categories.
These terms describe how authorization decisions are made. They are not three kinds of door lock. A keypad, card reader or mobile credential is a way to present a credential; the policy behind it determines whether access is allowed.
Keep the terminology in context
NIST’s access-control definitions originate in information security. This article explains those models and then uses clearly labeled building examples to make policy choices easier to discuss. The examples are planning analogies, not a claim that a door controller implements every feature of a formal computer-security model.
For equipment and installation decisions, start with our separate door access-control systems guide. First decide the permission policy; then ask a supplier to demonstrate how its actual platform supports it.
1. Discretionary access control: delegated decisions
In NIST’s DAC definition, authorization can depend on identity and permissions that an authorized subject may be able to pass to others. The important question is who is allowed to make or delegate an access decision.
An illustrative building arrangement would let a suite manager approve visitors for that suite while limiting their authority elsewhere. That may be useful, but “the manager can add visitors” does not by itself prove that a product implements a formal DAC model.
For a practical review, ask who can invite a visitor, which locations they can grant, whether grants expire, and who audits those changes. Flexibility needs boundaries and a record of decisions; it does not automatically mean a system has poor logs or no central oversight.
2. Mandatory access control: centrally enforced policy
NIST describes MAC in terms of centrally imposed restrictions, including sensitivity labels and authorization to handle information. Users cannot simply override those restrictions by choosing to share access.
A building analogy is a centrally controlled restricted area whose access cannot be granted by an ordinary local user. Treat that as an analogy. A locked laboratory door and a formal information-classification system are not the same thing.
When discussing a restricted physical area, document the approving authority, eligibility evidence, exception process and review responsibility. Ask what happens when central administration is unavailable and how the platform records emergency exceptions. The hardware and exit arrangements still require their own appropriate design.
3. Role-based access control: permissions by job
NIST’s RBAC definition organizes permissions around roles. Assigning a person to a role gives them the permissions associated with it.
For an illustrative office plan, reception staff might need the lobby and reception office, facilities staff might need plant rooms, and visitors might need only their approved route. These are proposed policy groups, not a recommended universal permission set.
The benefit is a reviewable connection between a job and the access it needs. The work is maintaining that connection. A transfer should prompt review of the old role as well as assignment of the new one. Otherwise, permissions can accumulate even in a role-based system.
Compare the models without ranking them by name
| Model | Main decision | Practical question |
|---|---|---|
| DAC | Who may grant or delegate a permission? | What are the limits on local administrators and invitations? |
| MAC | Which centrally imposed rules cannot ordinary users override? | Who defines eligibility and approves exceptions? |
| RBAC | Which permissions belong to each role? | Who maintains roles as jobs and teams change? |
None of these labels proves that a product is secure for your building. Compare the actual rules, administrative rights, logging and recovery process. A platform may combine several policy mechanisms.
Where attribute-based access control fits
NIST’s ABAC guidance describes decisions made by evaluating attributes against policy. This can include attributes of the requester, the resource, the requested action and relevant conditions.
For a building-planning analogy, discuss whether a contractor’s approved location, visit dates and sponsorship should all affect entry. Verify how the proposed platform actually represents those conditions. A schedule attached to a credential is useful, but it does not establish that a system offers a general-purpose ABAC engine.
Turn policy into an access matrix
Create a table with people or groups down one side and areas across the top. For each permission, record the business reason, approving owner, applicable schedule, expiry and review date. Add a separate list of people who can change those permissions.
Test ordinary access and negative cases. A valid employee should reach the intended area; an expired contractor, transferred employee or visitor at the wrong entrance should produce the documented result. Review the event log to confirm that staff can explain the decision afterward.
Our office access-control guide covers the operational workflow. Contact Monarch to turn the matrix into a demonstration checklist for a proposed system.
Frequently asked questions
Are DAC, MAC and RBAC the only models?
No. They are a common introductory grouping. ABAC and combinations of policy mechanisms also matter. Choose terminology that accurately describes the system you are evaluating.
Is a key card a type of access-control policy?
No. It is a credential format. The same kind of card can be used under different authorization policies depending on the management system and its configuration.
Is RBAC automatically the safest choice?
No model removes the need for appropriate permissions, protected administrator accounts, timely removal of access and reviewable records. Judge the actual configuration and maintenance process.
Can a building use more than one approach?
Yes, its operational policy can combine central restrictions, role groups and limited delegated administration. Ask the supplier to demonstrate the specific combinations and exceptions you need rather than relying on a marketing label.