Skip to main content
Compliance & Auditing

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

Don't pick an access control model by hype. We compare DAC, MAC, RBAC, and ABAC on auditability, least privilege, and compliance fit—and tell you which one wins.

The Myth of the "Best" Access Control Model

You've heard it a hundred times: "RBAC is the gold standard," or "ABAC is the future." That's wrong. There is no single best access control model—only models that fit your compliance burden and those that will sink you in an audit. The real question isn't which model is trendy; it's which one can survive a regulator's scrutiny. So let's cut through the noise and compare the four big ones—DAC, MAC, RBAC, and ABAC—on the criteria that actually matter when the auditor comes knocking.

What You're Actually Auditing

An access control audit boils down to three things: Can you prove who can access what? Can you show that access is limited to the minimum necessary? And can you demonstrate that no single person has enough power to commit fraud? That last one is called separation of duties, and NIST SP 800-53 defines it as dividing critical functions so no one individual can perpetrate damaging fraud. If your access control model can't answer those questions, you're in trouble.

So here's the comparison. We'll look at four models—Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC). And we'll judge them on four criteria: central control, granularity, scalability, and auditability. Because at the end of the day, an auditor doesn't care how cool your tech is; they care whether you can produce a clean report.

DAC: The Free-for-All That Fails Audits

DAC puts the owner of each resource in charge. The file's creator decides who gets in, typically using access control lists. It's flexible and simple—Unix file permissions are a classic example (Cisco Duo). But that flexibility is exactly what kills you in an audit. When every user can grant access, you have no central control, no consistent policy, and no way to prove least privilege. An auditor asks, "Who has access to this folder?" and you have to chase down fifty different owners. DAC is fine for a home computer, but it's the worst choice for any organization with compliance obligations.

MAC: The Military-Grade Lockdown

MAC flips DAC on its head. A central authority assigns security labels to both users and files, and the system enforces access based on those labels—no exceptions, even for the owner (Cisco Duo). That's why it's common in government and military environments with tiered clearances. MAC gives you absolute central control and impeccable auditability: access is deterministic, and you can trace every decision back to a label. But it's rigid. There's no room for context, and managing labels at scale is a nightmare. If you're not handling classified data, MAC is overkill and will slow your operations to a crawl.

RBAC: The Workhorse, but It Has Limits

RBAC assigns permissions to roles, not individuals. Users get roles, and roles get permissions. The NIST RBAC standard (INCITS 359) makes user-role and permission-role assignments the mandatory core (NIST RBAC). RBAC scales well—you define a role for "Accountant" and you're done. It also supports separation of duty, which NIST defines as a core feature (static and dynamic) (NIST RBAC). Auditors love RBAC because it's straightforward: you can list everyone with the "Admin" role and see exactly what they can do.

But RBAC has a weakness: it's not context-aware. If you want to say "managers can approve expenses, but only during business hours and only from a company device," RBAC can't do that without exploding into thousands of hyper-specific roles. That's where ABAC comes in.

ABAC: The Context-Aware Contender

ABAC evaluates attributes of the subject, object, action, and environment—like time, location, or device state—to make fine-grained decisions (Cisco Duo). NIST SP 800-162 formally defines ABAC as a logical access control methodology that evaluates attributes against policies (NIST SP 800-162). This gives you the granularity that RBAC lacks. You can write one policy that says "managers can approve expenses if the request is under $10,000 and the manager is on the corporate network." That's powerful.

But ABAC has a catch: it's only as good as your attribute data. If your directories are messy, your policies will be messy. And auditors will ask, "How do you know that the 'location' attribute is trustworthy?" That's a fair question. ABAC demands solid identity governance and data quality. Without it, you'll have a beautiful policy engine that makes decisions based on garbage.

The Head-to-Head Comparison

Criterion DAC MAC RBAC ABAC
Central Control None (owner-based) High (central authority) Medium (roles defined centrally) High (policy engine)
Granularity Low (per-resource) Medium (label-based) Medium (role-based) High (attribute-based)
Scalability Poor (per-user chaos) Poor (label management) Good (roles scale) Good (policies scale)
Auditability Poor (no central view) Excellent (deterministic) Excellent (clear role mapping) Good (policy decisions logged)

So Which One Wins?

Here's my recommendation: start with RBAC as your baseline, then layer ABAC on top for context-aware decisions. That's the sweet spot for most organizations, and it's what Cisco Duo suggests for modern practice (Cisco Duo). RBAC gives you a clean, auditable role structure that satisfies the core separation-of-duties requirements. ABAC adds the fine-grained control you need for real-world scenarios—like allowing access only during business hours or from compliant devices.

But don't just take my word for it. Look at what the federal government is doing. OMB M-22-09 pushes zero trust, which requires dynamic, per-session decisions based on user, device, and environment (NIST SP 800-207). That's ABAC in spirit. And NIST SP 800-207 says no implicit trust based on network location, which means you need context-aware policies. So if you're aiming for zero trust, ABAC is non-negotiable.

That said, there's a caveat. If you're handling classified data, MAC is the only way to go—it's the only model that enforces mandatory labels. But for 95% of organizations, RBAC+ABAC is the answer.

The One Thing to Remember

The best access control model isn't the one with the most features—it's the one you can defend in an audit. RBAC gives you structure, ABAC gives you nuance, and together they give you a story you can tell with confidence. DAC is a liability, and MAC is a niche tool. So don't chase trends. Build a layered model that starts with RBAC, adds ABAC for context, and you'll pass the audit every time.

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-162 (ABAC) - https://csrc.nist.gov/pubs/sp/800/162/final
  • 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
  • NIST SP 800-53 - https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

Share this article:

Comments (0)

No comments yet. Be the first to comment!