Access Control Models: Why ABAC Alone Won't Save You

Imagine You're the New IT Director

Imagine you're the new IT director at a mid-sized financial firm. On your first day, a junior analyst asks for access to the salary database. 'They've been here six months,' the manager says. 'Just give them read-only.' You check the system: it's a flat file share with everyone on the same group. No roles, no policies, no context. That's Discretionary Access Control (DAC) in its rawest form—the owner of the resource decides, and the owner is often wrong.

Most organizations don't start with a plan. They start with a shared drive and a pile of permissions. Then they bolt on roles, then attributes, then wonder why breaches happen. The truth is, no single access control model is a silver bullet. But if you understand the trade-offs, you can build a system that actually works.

The Big Three: DAC, MAC, RBAC

Let's get the basics straight. DAC is the free-for-all: each resource owner sets the rules, like Unix file permissions (Cisco Duo). It's flexible but dangerous—users often over-grant, and there's no central oversight. Mandatory Access Control (MAC) is the opposite: a central authority slaps security labels on everything, and the system enforces rules like 'no read-up, no write-down' (Cisco Duo). That's why MAC is standard in government and military—but it's a pain to manage.

Role-Based Access Control (RBAC) is the sweet spot for most businesses. Permissions go to roles, not individuals, and users inherit permissions by being assigned roles (Tenable). The ANSI INCITS 359 standard, developed by NIST, defines Core RBAC as the mandatory minimum: user-role and permission-role assignments (NIST RBAC). It also gives you separation of duty—static (can't be in two conflicting roles) and dynamic (can't activate both in one session) (NIST RBAC). That's a huge win for compliance.

But here's the catch: RBAC alone doesn't handle context. A user might have the 'Manager' role, but should they access the HR system from a coffee shop at 3 AM? RBAC says yes, because they have the role. That's where ABAC steps in.

ABAC: The Context-Aware Layer

Attribute-Based Access Control (ABAC) evaluates attributes of the subject, object, action, and environment—like time, location, or device state—to make fine-grained decisions (Cisco Duo). NIST defines ABAC as a methodology where authorization is determined by evaluating attributes against policies (NIST SP 800-162). It's powerful. You can say, 'Allow read access to payroll if the user is in HR, the device is compliant, and the time is between 9 AM and 5 PM.'

But ABAC isn't a replacement for RBAC. It's a layer on top. Most modern organizations use RBAC as the baseline for scalable permissions and layer ABAC on top for context-aware decisions, adding MAC only for classified data (Cisco Duo). That's the pattern I recommend: RBAC for the 'who can do what' and ABAC for the 'under what conditions.'

The Zero Trust Imperative

Now, the elephant in the room: zero trust. NIST SP 800-207 says a zero trust architecture grants no implicit trust based on network location; access is granted per session based on dynamic policy (NIST). The federal government has mandated this: OMB M-22-09 required agencies to achieve phishing-resistant MFA by the end of fiscal year 2024 (OMB).

Zero trust isn't a model per se—it's a paradigm. But it forces you to think about access control differently. You need a Policy Decision Point (PDP) and a Policy Enforcement Point (PEP) to make and enforce decisions (NIST SP 800-207). That's where ABAC shines—it gives you the attributes to make dynamic decisions. But you also need the plumbing: protocols like OAuth 2.0 for authorization, OpenID Connect for authentication, and SCIM for provisioning.

Comparison: Which Model Wins?

The table tells the story: DAC is a security nightmare, MAC is rigid, RBAC is scalable but blind, and ABAC is flexible but complex. No single model wins. The winner is a combination.

My Recommendation: RBAC + ABAC + Zero Trust

Here's my straight talk: if you're starting fresh, build on RBAC as your foundation. Define roles based on job functions, apply least privilege (Tenable), and use separation of duty to prevent fraud. Then add an ABAC layer for decisions that depend on context—like location, device compliance, or risk score. And finally, adopt zero trust principles: never trust the network, verify every session, and use phishing-resistant MFA.

Concrete example: At a bank, a teller has the 'Teller' role (RBAC) that allows cash transactions. But with ABAC, you add a rule: 'If the transaction is over $10,000, require manager approval.' That's a simple attribute-based check on top of RBAC. And with zero trust, you enforce MFA on every session, and you don't trust the teller's IP address just because it's on the corporate network.

For privileged accounts, use PAM (Privileged Access Management) with just-in-time access and session recording (NIST PAM). For federated identity, use OIDC and SAML, and for dynamic access, use Conditional Access if you're in Microsoft land (Microsoft).

Bottom Line

Stop asking 'which model?' and start asking 'what combination?' The best move is to implement RBAC as your baseline, layer ABAC for context, and wrap it all in a zero trust architecture. That's not a compromise—it's the only way to handle modern threats.

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
• OMB M-22-09 - https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management