Stop Chasing the Perfect Access Control Model—Mix Them Like a Pragmatist

The Perfect Model Is a Myth—Embrace the Hybrid

Everyone wants a single, elegant access control model. They ask, "Should we be RBAC or ABAC?" and treat the choice like a religious conversion. I'm here to tell you that's a trap. The most secure and practical approach is to deliberately combine models, not choose one. In my years as an editor covering identity and security, I've seen too many organizations crippled by dogmatic adherence to one model. The reality is that each model—Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC)—has strengths that address different problems. The winning strategy is to layer them, using each where it shines.

RBAC: The Scalable Baseline You Can't Ignore

Let's start with RBAC, the workhorse of modern access control. It assigns permissions to roles, not individuals, and users inherit permissions by being assigned roles (Tenable). This is scalable for defined job roles—think "accountant," "developer," or "HR manager." The ANSI INCITS 359 standard, developed by NIST, defines Core RBAC as the mandatory minimum for any RBAC system (NIST RBAC). That standard also includes separation of duty constraints, which prevent a single user from being assigned conflicting roles (static) or activating them in the same session (dynamic). This is powerful for reducing fraud risk, as NIST SP 800-53 notes that separation of duties divides critical functions so no single individual has enough access to perpetrate damaging fraud. So, RBAC gives you a solid, auditable foundation. But it has a fatal flaw: it's static. Once a role is granted, it's often granted for a long time, leading to privilege creep. That's where ABAC comes in.

ABAC: The Context-Aware Overlay That Brings Precision

Attribute-Based Access Control evaluates attributes of the subject, object, action, and environment—like time, location, or device posture—to make fine-grained decisions (Cisco Duo). This is the secret sauce for zero trust. NIST SP 800-207 says that in a zero trust architecture, access is granted on a per-session basis, determined by dynamic policy considering the state of the user, device, and environment. ABAC is how you implement that dynamic policy. For example, you might allow a user with the "manager" role to access financial reports, but only from a company device, during business hours, and only if their risk score is low. That's impossible with RBAC alone. So, I recommend using RBAC as the baseline—because it's easy to manage and audit—and layering ABAC on top for context-aware decisions. This is exactly what Cisco Duo suggests: most modern organizations use RBAC as a baseline and layer ABAC for context, adding MAC only for classified data (Cisco Duo).

Don't Forget DAC and MAC: They Have Their Place

But what about DAC and MAC? DAC lets the owner of each resource decide who can access it, using access control lists—like Unix file permissions (Cisco Duo). It's flexible and decentralized, but it's a security nightmare in a large enterprise because it relies on individual discretion. MAC, on the other hand, is centralized and restrictive, using security labels and clearances, and is common in government and military settings (Cisco Duo). It's perfect for classified data with tiered clearance levels, but it's too rigid for most commercial use. Here's my contrarian take: don't dismiss DAC entirely. In small teams or for collaborative documents, DAC's flexibility is a feature, not a bug. And MAC is non-negotiable for any organization handling truly sensitive national security or intelligence data. But for most of us, the hybrid of RBAC + ABAC is the sweet spot.

The Counter-Argument: "But Simplicity Is Safer"

You might argue that mixing models adds complexity, and complexity breeds misconfiguration and security holes. I get it. But the alternative—a single model—is worse. RBAC alone is too coarse; ABAC alone can become a tangled web of attributes that's hard to manage. And pure DAC is chaos. The answer is not to choose one, but to deliberately design a layered system where each model covers the other's weaknesses. For example, AWS IAM, which is essentially a policy-based access control system, defaults to deny all access, and an explicit Deny overrides any Allow (AWS IAM). That's a form of least privilege, which is a core principle: grant only the minimum access necessary (Tenable). If you combine that with RBAC roles and ABAC attributes, you get a defense-in-depth that's far more robust than any single model. So, yes, it's more work upfront, but it's the only way to achieve both scalability and precision in a complex environment.

My Recommendation: Stop Debating, Start Layering

Here's my concrete advice: Start with RBAC as your baseline. Assign roles based on job functions, and use the separation-of-duty rules from the NIST standard to prevent conflicts. Then, overlay ABAC to add context—time, location, device—to every access decision. This gives you fine-grained control without sacrificing manageability. For your most sensitive data, consider MAC-style labels, even if you don't go full military. And don't be afraid to use DAC-style sharing for low-risk collaboration. The key is to be deliberate. Don't let one model dictate your architecture. You're the architect, and you should use the right tool for each job. Remember, the goal is not to be pure; it's to be secure.

The Single Most Important Thing to Remember

Stop trying to find the "best" access control model. The best model is the one you combine with others to fit your specific risks and workflows.

Sources

• Tenable - https://www.tenable.com/cybersecurity-guide/learn/key-iam-components
• Cisco Duo - https://duo.com/learn/access-control-models
• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• NIST RBAC (INCITS 359) - https://csrc.nist.gov/projects/role-based-access-control
• AWS IAM - https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html