RBAC Isn't Dead, and ABAC Alone Won't Save You

I've lost count of how many times someone tells me, "RBAC is old news—you should go full ABAC." And every time, I have to push back. RBAC—Role-Based Access Control—isn't dead. It's the quiet workhorse behind most secure systems. The ANSI INCITS 359 standard, which NIST helped develop, defines Core RBAC as the minimum for any RBAC system (NIST RBAC). And here's why it works: you assign permissions to roles, not individuals. With 500 employees, you might have 30 roles. That's manageable. Try that with ABAC, and you'll drown in attributes and policies unless you're extremely disciplined. Most orgs should start with RBAC, then layer ABAC for the tricky decisions (Cisco Duo). Don't toss the baby with the bathwater.

Yes, ABAC gives you finer control—but at a cost. NIST SP 800-162 defines ABAC as evaluating attributes of the subject, object, action, and environment against policies (NIST SP 800-162). So you can say, "Managers can view financial reports, but only during business hours and only on a compliant device." That's powerful. But you've got to define every attribute and maintain every policy. It's not a flip-the-switch change. For most teams, RBAC keeps the lights on, and ABAC adds nuance where it counts—sensitive data, high-risk actions.

Mandatory Access Control (MAC)? It's strict, sure. The system enforces access based on security labels, and even the resource owner can't override it (Cisco Duo). That's why the military loves it. But for a typical business, it's overkill. You'd label every file and every user with a clearance level, then deal with rules like "no read-up, no write-down." Rigid doesn't even begin to describe it. And Discretionary Access Control (DAC), where owners decide, is too loose for anything beyond the least sensitive data (Cisco Duo). The sweet spot? RBAC with a hint of ABAC.

Now, zero trust. It's not a model like RBAC or ABAC; it's a mindset shift. NIST SP 800-207 says zero trust moves defenses from static, network-based perimeters to focusing on users, assets, and resources (NIST SP 800-207). In practice, you don't trust a user just because they're on your VPN. You grant access per session based on dynamic policy—checking identity, device health, and other signals. That's complementary to RBAC/ABAC. You still decide what roles or attributes allow; zero trust just double-checks that decision with more scrutiny.

But here's a scenario that might hit home: a contractor needs temporary access to your project management tool. With RBAC alone, you'd probably give them the same role as a full-time employee—because creating a custom role is a hassle. That's a classic least privilege violation. With ABAC, you could add a policy that says, "Contractors can access the tool, but only between 9 AM and 5 PM, and only from a company-issued laptop." That's the kind of context RBAC can't touch. NIST SP 800-207 even says access decisions should consider the state of the user, device, and environment (NIST SP 800-207). So, RBAC is necessary but not sufficient. Pair it with ABAC for context, and wrap it in zero trust principles like continuous verification.

Least privilege is a principle, not a model: give users only the minimum access they need (Tenable). The challenge is not to lock people out so much that they can't work. The trick is making access easy to request and grant. That's where Privileged Access Management (PAM) comes in. NIST NCCoE defines PAM as the discipline for monitoring and controlling privileged accounts (NIST PAM). For example, Microsoft's PIM allows just-in-time privileged access—a user can request elevation for a specific task, with approval workflows and time-bound assignments (Microsoft PIM). So you can enforce least privilege without permanently stripping away access that people occasionally need.

Don't think MFA solves everything. It proves who you are, not what you can do. Authentication is separate from authorization. After you authenticate, the system must check whether you're allowed to perform the action (Tenable). If your authorization model is sloppy, an authenticated user could see data they shouldn't. And not all MFA is equal. CISA calls phishing-resistant MFA—like FIDO/WebAuthn or PKI-based—the "gold standard" because ordinary MFA can be phished or hit with push bombing (CISA Phishing-Resistant MFA). So, use phishing-resistant MFA where you can, but don't neglect the authorization layer underneath.

OAuth 2.0 and OpenID Connect? They're protocols, not access control models. OAuth 2.0 is an authorization framework for letting third-party apps access APIs on behalf of users without exposing passwords (RFC 6749). OpenID Connect adds an identity layer, giving you a signed ID token that proves authentication (OpenID Connect). You still need to decide which roles or attributes a user has. In practice, you'll use OIDC for SSO across web apps, and SAML for older enterprise integrations (SAML 2.0). Both are fine; just remember the token is not the permission.

So, what's the takeaway? Stop chasing the shiny object. Use RBAC as your foundation, add ABAC where you need context, and enforce it all with zero trust principles and phishing-resistant MFA. That's the most pragmatic path to robust access control—without losing your mind.

Sources

• NIST RBAC (INCITS 359) - https://csrc.nist.gov/projects/role-based-access-control
• Cisco Duo - https://duo.com/learn/access-control-models
• NIST SP 800-162 - https://csrc.nist.gov/pubs/sp/800/162/final
• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• CISA Phishing-Resistant MFA - https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• Microsoft PIM - https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure