Stop Picking One Access Control Model: A Case for Layering RBAC and ABAC

Stop treating access control models like a multiple-choice quiz. The common advice says pick one: RBAC is simple and scalable, ABAC is granular and context-aware, so choose based on your needs. That advice is wrong. You need both, and if you try to run a real business on a single model, you will either drown in role explosion or leave gaping security holes. Imagine you are the newly hired security lead at a 200-person SaaS company. You have a legacy app with a homegrown permission system, a sales team that needs access to customer data from anywhere, and a finance team that handles wire transfers. Your predecessor used pure RBAC. It worked until the company grew, and now you have 300 roles, many of which differ by a single permission. You are spending more time managing roles than securing access. You need a better way.

Why pure RBAC breaks at scale

RBAC assigns permissions to roles, and users inherit permissions by being assigned roles (Tenable). That is powerful for defined job functions. The ANSI INCITS 359 standard defines Core RBAC as the mandatory minimum, with user-role and permission-role assignments (NIST RBAC). But when you try to express fine-grained rules like 'sales reps can view customer records only for their assigned region during business hours,' you end up creating a role for every permutation. That is role explosion. You could try to solve it with static separation of duty, which prevents a user from being assigned to conflicting roles, but that does not help with context. The result is a mess that no one understands, and least privilege becomes a fantasy.

What ABAC actually buys you

ABAC evaluates attributes of the subject, object, action, and environment—such as time or location—to make authorization decisions (Cisco Duo). NIST SP 800-162 defines ABAC as a methodology where authorization is determined by evaluating attributes against policies. That means you can write a policy like: allow access if the user's department matches the record's department and the request comes from a managed device. No new role needed. For your sales team, you can enforce that they can only access customer data for accounts in their territory, and only during working hours. For finance, you can require that wire transfers above a certain amount need two approvers. ABAC gives you the granularity that RBAC lacks, but if you go pure ABAC, you lose the simplicity of role management. Policies become complex, and auditing becomes a nightmare.

The hybrid model that actually works

Most modern organizations use RBAC as a baseline for scalable permissions and layer ABAC on top for context-aware decisions, adding MAC only for classified data (Cisco Duo). That is your answer. Start with RBAC for coarse-grained access. Define roles like 'Sales Rep,' 'Sales Manager,' 'Finance Analyst,' and 'Finance Manager.' Assign permissions to those roles. Then use ABAC to refine access based on attributes. For example, a Sales Rep role might grant read access to the customer object, but an ABAC policy restricts that access to records where the customer's region matches the user's region attribute. This keeps your role count manageable while still enforcing least privilege. You get the best of both worlds.

Implementing the hybrid model: a step-by-step walkthrough

Let's walk through the scenario. First, inventory your resources and actions. Identify the objects (customer records, financial transactions) and the operations (view, edit, approve). Next, define roles that map to job functions. Use the principle of least privilege: grant only the minimum access necessary (Tenable). For your sales team, create roles for 'Sales Rep' and 'Sales Manager.' The Sales Rep role gets read access to customer records; the Sales Manager role gets read and edit. Now, layer ABAC policies. For the Sales Rep role, add a policy that allows access only if the user's region attribute equals the customer's region attribute. For the Sales Manager, allow access to all regions but require that the request comes from a corporate-managed device. You can enforce device compliance through a policy engine like Microsoft Entra Conditional Access, which evaluates signals such as user or group membership, IP location, and device state to grant or block access (Microsoft Conditional Access). This is zero trust in action: no implicit trust based on network location (NIST SP 800-207). For finance, create roles for 'Finance Analyst' and 'Finance Manager.' The Analyst can view transactions but not approve them. The Manager can approve, but only if the transaction is below a threshold, and any approval above that threshold requires a second approver. That is separation of duties: dividing critical functions so no single individual can perpetrate fraud (NIST SP 800-53). Enforce this with an ABAC policy that checks the transaction amount and the user's role. If the amount exceeds the threshold, the policy denies access unless a second approval attribute is present.

Authentication is not authorization: don't confuse the two

You cannot talk about access control models without getting authentication right. Authorization happens after authentication and determines what an authenticated user can do (Tenable). But if your authentication is weak, your authorization is moot. For your privileged roles—like the Finance Manager who can approve wires—you need strong authentication. NIST SP 800-63B defines AAL2 as requiring multi-factor authentication with two different factors, and AAL3 as requiring a hardware-based authenticator with verifier impersonation resistance. For your finance approvers, mandate AAL3: a hardware security key like a YubiKey. That is phishing-resistant because the key is bound to the domain, so it won't work on a look-alike site. CISA calls phishing-resistant MFA the gold standard and identifies FIDO/WebAuthn as the only widely available form (CISA Phishing-Resistant MFA). Pair that with just-in-time privileged access: don't give permanent admin rights. Use a PAM solution to vault credentials and rotate passwords, and require MFA for privileged sessions (NIST PAM). Microsoft Entra PIM can provide time-based and approval-based role activation, so a finance manager activates the approver role only when needed (Microsoft PIM). That reduces the window of exposure.

Don't forget the tokens and protocols

When you implement SSO and API access, you will deal with OAuth 2.0, OIDC, and SAML. Remember that OAuth 2.0 is an authorization framework, not an authentication protocol; an access token alone does not prove who the user is (RFC 6749). Use OpenID Connect for authentication, which adds a signed ID token that provides cryptographic proof of authentication (OpenID Connect). For your single-page application, use the authorization code flow with PKCE to mitigate code interception (RFC 7636). And never treat a bearer token as proof of possession; anyone who steals it can use it (RFC 6750). These details matter because a mistake here can bypass your carefully designed access control model.

The one thing you must do

If you take nothing else from this, adopt a hybrid RBAC+ABAC model and enforce it with a policy engine. Do not try to boil the ocean. Start with RBAC for your core roles, then add ABAC policies for the most sensitive resources—customer data and financial transactions. Use conditional access to evaluate context, and require phishing-resistant MFA for privileged actions. This is not theoretical; it is how you scale access control without losing your mind. You will still need to review roles and policies regularly, but you will have a system that can grow with your business.

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
• Microsoft Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
• CISA Phishing-Resistant MFA - https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management