Stop Handing Out Keys: Why RBAC Is Failing Your Zero Trust Goals

Everyone's telling you to adopt zero trust, and they're all pointing at RBAC as the foundation. I'm here to tell you that's a trap. RBAC, as your primary authorization strategy, is actively undermining your zero trust ambitions. It's a static model in a world that demands dynamic decisions. If you're serious about zero trust, you need to stop thinking in terms of roles and start thinking in terms of attributes.

The RBAC Comfort Zone

I get why RBAC is so popular. It's simple. You define a role for "marketing manager," assign permissions to that role, and then any user who gets that role inherits those permissions. It scales reasonably well for defined job roles, as Cisco Duo notes. The ANSI INCITS 359 standard, developed by NIST, even gives you a formal framework with Core RBAC as the mandatory minimum. It's a tidy, manageable system.

But that tidiness is an illusion. RBAC assumes that your organization is a stable hierarchy of job functions. In reality, people wear multiple hats, projects shift, and context matters. A marketing manager might need access to the CRM, but what if they're working on a sensitive campaign from a coffee shop? Under RBAC, they still have the same access, regardless of location or device. That's exactly the kind of implicit trust that zero trust is supposed to eliminate.

The Zero Trust Reality Check

Zero trust, as defined by NIST SP 800-207, grants no implicit trust to assets or user accounts based solely on their physical or network location. Access to individual enterprise resources is granted on a per-session basis, determined by dynamic policy considering the state of the user, device, and environment. That's a far cry from a static role assignment that persists until someone revokes it.

RBAC simply cannot deliver per-session, context-aware decisions. It's like having a key that opens every door in the building, regardless of what time it is or who's inside. You might have separate keys for different floors, but the moment you hand out a key, the holder has access until you take it back. That's not zero trust; that's just traditional access control with a new label.

ABAC: The Context-Aware Contender

The solution, I believe, lies in Attribute-Based Access Control (ABAC). NIST SP 800-162 defines ABAC as a logical access control methodology where authorization is determined by evaluating attributes associated with the subject, object, requested operations, and environment conditions. In plain English, you make access decisions based on who you are, what you're trying to access, what you're doing, and the current context—like time, location, and device posture.

ABAC is granular. You can say, "Allow marketing managers to view the campaign report, but only if they're on a company-managed device and connecting from the office network between 9 AM and 5 PM." That's the kind of dynamic policy that zero trust demands. It's not about assigning a role; it's about evaluating a set of conditions in real time.

A Concrete Scenario: The Marketing Manager

Imagine you're a security architect at a mid-sized SaaS company. You have a marketing manager, let's call her Priya. Under RBAC, Priya has the "Marketing Manager" role, which grants her access to the company's campaign management tool, the CRM, and the analytics dashboard. That's fine for her day-to-day work.

But one evening, Priya is at a conference and decides to check the latest campaign metrics from her personal laptop. With RBAC, she can log in and access everything, because her role doesn't care about the device or the network. She's authenticated, so she's authorized. This is a classic example of the implicit trust that zero trust explicitly rejects.

Now, let's reimagine this with ABAC. The policy engine evaluates Priya's request: subject (Priya, with attributes like "employee type: full-time" and "department: marketing"), object (the analytics dashboard), action (read), and environment (device: personal laptop, location: external network, time: 8 PM). The policy might say: "Allow read access to analytics if the subject's department is marketing AND the device is company-managed AND the location is the office network." Since Priya's device is personal and she's not on the office network, the access is denied. This is a per-session decision, exactly as NIST SP 800-207 prescribes.

Why You Need Both, But Not as You Think

Now, I'm not saying you should throw RBAC out the window entirely. Cisco Duo notes that most modern organizations use RBAC as a baseline for scalable permissions and layer ABAC on top for context-aware decisions. That's a reasonable starting point, but it's not enough. The problem is when RBAC becomes the default and ABAC is an afterthought. You end up with a hybrid where roles still grant broad access, and ABAC only adds a few extra checks. That's better than pure RBAC, but it's still not zero trust.

The real shift is to invert the model: Start with ABAC as the core authorization engine, and use RBAC only as a convenience layer for grouping common attributes. For example, instead of having a "Marketing Manager" role, you might have a policy that says, "If the subject has the attribute 'department = marketing' and 'job level = manager,' then allow access to the campaign tool, subject to additional environmental constraints." That way, the role is just a shorthand for a set of attributes, not a source of implicit trust.

Making the Transition: Practical Steps

So, how do you actually make this shift? First, you need a policy engine that can evaluate attributes in real time. This could be a next-generation access control solution, or you could build it with open-source tools like OPA (Open Policy Agent). But before you start buying tools, you need to define your attributes and policies.

Start by identifying the critical resources and the attributes that matter for each one. For example, for your financial systems, you might require that the user is in the finance department, the device is compliant, and the access request occurs during business hours. You can use NIST SP 800-53's separation of duties principle to ensure that no single individual can perform critical functions alone—a key control that ABAC can enforce through attribute combinations.

Second, you need to integrate your identity provider and device management to feed attributes into the policy engine. This is where standards like SCIM (RFC 7643) come in handy for automating identity lifecycle management, ensuring that user attributes are up to date. And for authentication, you should already be moving to phishing-resistant MFA, as CISA recommends, to ensure that the identity behind the attributes is trustworthy.

Comparison Table: RBAC vs. ABAC

What I'd Actually Do

Here's my blunt recommendation: If you're building a new system or seriously modernizing an existing one, skip RBAC as your primary model. Go straight to ABAC. Don't just layer ABAC on top of RBAC; replace it. Use RBAC only as a convenience for grouping attributes, but never as the basis for a security decision.

Yes, it's more work upfront to define attributes and policies. But the payoff is that you can actually achieve zero trust: no implicit trust, per-session access decisions, and the ability to adapt to changing context. Your users will experience fewer access headaches because policies can be more nuanced, and your security team will finally have control that matches the complexity of your environment. Don't let the comfort of roles lull you into a false sense of security. The keys are in the attributes.

Sources

• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• NIST SP 800-162 - https://csrc.nist.gov/pubs/sp/800/162/final
• Cisco Duo - https://duo.com/learn/access-control-models
• NIST RBAC (INCITS 359) - https://csrc.nist.gov/projects/role-based-access-control
• CISA Phishing-Resistant MFA - https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• RFC 7643 (SCIM) - https://www.rfc-editor.org/rfc/rfc7643