DAC vs. MAC vs. RBAC vs. ABAC: Which Access Control Model Wins?

Which access control model should you actually use?

If you've ever typed "DAC vs MAC vs RBAC vs ABAC" into a search bar, you know the pain: endless vendor blogs that each claim their favorite model is the best, with no real guidance for someone who just needs to lock down a system. We've been there, and we're going to settle it. After building access control for everything from tiny startups to regulated enterprises, we've formed a strong opinion: RBAC is the baseline, ABAC is the layer you add for real-world nuance, and DAC and MAC are mostly legacy or niche. Here's why.

The contenders: what each model actually does

Let's quickly define the four models, because the trade-offs only make sense once you see them side by side.

• DAC (Discretionary Access Control): The owner of a resource decides who gets in. Think Unix file permissions or Windows ACLs. Flexible, but zero central oversight—a single user can accidentally (or maliciously) grant access to the wrong person.
• MAC (Mandatory Access Control): A central authority assigns labels to users and files, and the system enforces rules like "no read-up, no write-down." It's the military/government standard, but it's rigid and hard to manage in dynamic environments.
• RBAC (Role-Based Access Control): Permissions are tied to roles, not individuals. You assign a user to a role, and they inherit the permissions. The ANSI INCITS 359 standard defines Core RBAC as the baseline, plus separation of duty options. (NIST RBAC)
• ABAC (Attribute-Based Access Control): Access decisions are made by evaluating attributes of the user, resource, action, and environment (like time or location). It's the most granular and context-aware, but it's also the most complex to implement and govern.

How they stack up: our head-to-head criteria

We evaluated the models on four criteria that matter in the real world: flexibility (how quickly you can grant/revoke access), security (how well it enforces least privilege and prevents unauthorized access), scalability (how well it handles thousands of users), and context-awareness (whether it can factor in things like device health or location). Here's the table:

That table matches what we've seen in the field. DAC is flexible but a security nightmare—it's the reason your colleague can accidentally share a folder with the whole company. MAC is secure but so rigid that it's only practical in highly classified environments. RBAC scales beautifully because you define roles once and assign users to them, but it can't handle "allow access only during business hours" or "only from a managed device." ABAC handles those nuances, but it requires a solid policy engine and disciplined attribute management.

The real-world verdict: RBAC + ABAC, with a nod to zero trust

So which model wins? It depends on your context, but for most modern organizations, the answer is RBAC as the foundation, ABAC as the fine-grained layer on top. That's what Cisco Duo suggests: "Most modern organizations use RBAC as a baseline for scalable permissions and layer ABAC on top for context-aware decisions, adding MAC only for classified data." (Cisco Duo) We agree, and we'd add that MAC is overkill for 99% of commercial use cases—stick to RBAC for role-based access, then use ABAC policies to enforce things like "managers can approve expenses only during business hours."

This combination is also the natural fit for zero trust. NIST SP 800-207 defines zero trust as granting no implicit trust based on network location, and instead making access decisions per-session based on dynamic policy that considers the user, device, and environment. (NIST SP 800-207) That's literally ABAC in action. And when you add in the federal push—OMB M-22-09 required agencies to achieve phishing-resistant MFA by the end of fiscal year 2024—you see the direction: context-aware, identity-centric access control. (OMB M-22-09)

What I'd actually do

If you're starting from scratch, don't try to implement ABAC everywhere. It's a recipe for analysis paralysis. Instead:

• First, implement RBAC with well-defined roles based on job functions. Use the Core RBAC model from the ANSI INCITS 359 standard (NIST RBAC).
• Second, layer ABAC policies where you need context. Start with a few high-value cases: access from managed devices, time-of-day restrictions, or location-based rules.
• Third, enforce least privilege relentlessly. AWS IAM's default-deny philosophy is a good pattern: start by denying everything, then allow only what's needed. (AWS IAM)
• Finally, if you're handling privileged accounts, add a PAM solution—credential vaulting, session recording, and just-in-time access are the controls that matter. (NIST PAM)

In short: DAC is for hobbyists, MAC is for the military, and RBAC+ABAC is for everyone else. Build your access control around that, and you'll sleep better.

Sources

• Cisco Duo - https://duo.com/learn/access-control-models
• NIST RBAC (INCITS 359) - https://csrc.nist.gov/projects/role-based-access-control
• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• OMB M-22-09 - https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
• AWS IAM - https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management