Stop Overthinking Authorization: RBAC First, ABAC Second, MAC Only If You Must

We've all been there: a new engineer asks for read access to a database, and two weeks later they're still waiting because the 'access control' ticket is stuck in a committee. That's not security; that's bureaucracy. Here's the truth: most organizations don't need a sophisticated authorization strategy. They need a baseline that scales, and then a thin layer of context for the edge cases. The numbers back this up: most modern orgs use RBAC as a baseline and layer ABAC on top for context-aware decisions (Cisco Duo). That's not a trend; it's common sense. Let's cut through the mythology.

What's the Difference Between Authentication and Authorization?

Authentication is 'who are you?' Authorization is 'what can you do?' They're sequential: you can't authorize someone until you've authenticated them (Tenable). Authentication factors come in three flavors: something you know (password), something you have (like a phone), something you are (a fingerprint) (NIST SP 800-63B). But authorization is a separate decision, made after identity is established. If you're still using the same policy for both, you're doing it wrong.

Isn't RBAC Enough? Why Do I Need ABAC?

RBAC is the workhorse. It assigns permissions to roles, and users inherit permissions via roles (Tenable). The ANSI INCITS 359 standard defines Core RBAC as the mandatory minimum for any RBAC system (NIST RBAC). That's a solid start. But RBAC gets clunky when a single role doesn't fit everyone. Take a 'Manager' role: some managers need access to project X, others to project Y. If you create a role for every permutation, you end up with role explosion. That's where ABAC comes in. ABAC evaluates attributes like time, location, and resource type to make fine-grained decisions (NIST SP 800-162). A common pattern: keep RBAC for the baseline, then ABAC for the dynamic bits. For example, your finance team has a role that allows access to payroll, but ABAC adds a rule: only between 9 AM and 5 PM, and only from a corporate device. That's context, and it's powerful.

DAC vs. MAC: Are They Even Relevant Today?

DAC (Discretionary Access Control) is the free-for-all: the owner of a file decides who gets access (Cisco Duo). That's how Unix file permissions work, and it's fine for a personal laptop, but it's a nightmare at scale. MAC (Mandatory Access Control) is the opposite: a central authority assigns labels, and users can't override them (Cisco Duo). That's for governments and the military with classified data. If you're in the private sector and you're not handling classified secrets, you probably don't need MAC. But here's a myth: 'MAC is more secure.' Not necessarily. MAC is more restrictive, but it's also less flexible. And if you can't get work done because everything is labeled 'Secret,' you'll find people working around the system. Use MAC only if you have a compliance requirement that demands it.

What's the Real Risk of Over-Privileged Accounts?

Let's talk about the 'keys to the kingdom.' Privileged accounts provide elevated access, and their compromise plays a role in many major breaches (NIST PAM). That's why you need Privileged Access Management (PAM). But PAM isn't just about vaulting passwords. It's about just-in-time access, session monitoring, and MFA for privileged sessions (NIST PAM). The principle of least privilege is the guiding light: grant only the minimum access needed (Tenable). But 'minimum' isn't static. If you're not reviewing who has admin rights every quarter, you're drifting. And here's a concrete example: AWS IAM denies access by default, and an explicit Deny overrides any Allow (AWS IAM). That's a strong default. But if you give a developer 'admin' because it's easier, you're violating least privilege from day one.

Is OAuth 2.0 an Authentication Protocol? (Spoiler: No)

Here's a common misconception: people treat OAuth 2.0 as if it proves identity. It doesn't. OAuth 2.0 is an authorization framework, and an access token alone does not convey who the user is (RFC 6749). That's a huge distinction. If you're using OAuth for SSO, you need OpenID Connect (OIDC) on top. OIDC adds an ID token, which is a JWT that provides cryptographic proof of authentication (OpenID Connect). So, if you're building a login flow, don't just grab an OAuth access token and assume the user is who they claim to be. Verify the ID token's signature and check the issuer. Otherwise, you're letting anyone with a valid access token into your app, regardless of identity.

What's the Deal with Zero Trust? Is It Just a Buzzword?

Zero trust has been called a buzzword, but it's a real shift in mindset. The core idea: no implicit trust based on network location (NIST SP 800-207). You don't trust a user just because they're on the corporate VPN. Instead, you grant access per session, based on dynamic policy considering the user, device, and environment (NIST SP 800-207). That's the theory. The practice: use conditional access policies. Microsoft Entra Conditional Access is exactly that: a policy engine that makes decisions based on signals like user group, location, and device state (Microsoft Conditional Access). For example, you can require MFA when someone signs in from a new IP or an untrusted device. That's zero trust in action. But don't try to implement all of NIST SP 800-207 overnight. Start with one resource, apply conditional access, and iterate.

MFA Is Good, But Not All MFA Is Equal

You've heard that MFA is a must. True. But not all MFA is phishing-resistant. CISA calls phishing-resistant MFA the 'gold standard' and identifies two forms: FIDO/WebAuthn and PKI-based (like PIV or CAC) (CISA Phishing-Resistant MFA). Regular TOTP codes can be phished—a fake site can ask you for the code and use it. Push notifications can be bombed until you accept. So, if you're serious about security, move to passkeys. Passkeys are phishing-resistant because each one is bound to the specific domain it was created for (Microsoft Passkeys). So a passkey created for 'yourbank.com' won't work on 'yourbank.evil.com.' That's a concrete, real-world win. And passkeys count as MFA: they require something you have (the device) and something you are/ know (biometric or PIN) (Microsoft Passkeys). So, upgrade your MFA to passkeys. It's not just a nice-to-have; it's the direction the industry is heading.

What I'd Actually Do

Stop chasing the newest authorization model. Start with RBAC. Implement Core RBAC as your baseline, and map your job functions to roles. Don't overthink it. Then, layer ABAC on top for the 10% of cases that need context—like time-of-day restrictions or location-based access. That's what most modern orgs do (Cisco Duo). Next, enforce least privilege by default: deny access unless explicitly allowed (AWS IAM). Use a PAM tool for your privileged accounts, and enable just-in-time access so admins don't have standing access (NIST PAM). Finally, adopt phishing-resistant MFA, preferably passkeys, for all users (CISA Phishing-Resistant MFA). That's it. That's the entire strategy. Don't let a security vendor sell you a complex ABAC-only platform that requires a data science team to maintain. Keep it simple, and review your roles quarterly. You'll sleep better, and so will your security team.

Sources

• Tenable - https://www.tenable.com/cybersecurity-guide/learn/key-iam-components
• Cisco Duo - https://duo.com/learn/access-control-models
• NIST SP 800-162 - https://csrc.nist.gov/pubs/sp/800/162/final
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management
• RFC 6749 - https://www.rfc-editor.org/rfc/rfc6749
• Microsoft Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview