Picture this: you're the IT admin at a mid-sized company. You've just rolled out role-based access control (RBAC) across your SaaS stack. Everyone's got a role, permissions are tidy. Then the CEO's account gets phished—because he fell for a look-alike login page. The attacker now has a privileged session, and your RBAC structure doesn't care. That's the moment you realize: authorization isn't just about who can do what; it's about the context and the strength of the authentication behind it.
We've been there. In this article, we'll answer the questions we actually get from practitioners, and we'll bust a few myths that keep getting teams in trouble. We'll be blunt: if you're not layering your authorization with context and zero trust principles, you're one phishing email away from a breach.
Is RBAC still the gold standard?
RBAC is the default for a reason: it scales. The ANSI INCITS 359 standard defines Core RBAC as the mandatory baseline, and it's what most systems use (NIST RBAC). But RBAC alone has a fatal flaw: it ignores context. A role is a static label. It doesn't care if the request comes from a coffee shop in another country at 3 AM. That's why we say RBAC is a necessary foundation, not a complete strategy.
What's the difference between RBAC and ABAC, and when do I need both?
RBAC assigns permissions to roles; ABAC evaluates attributes like time, location, device state, and resource sensitivity (Cisco Duo; NIST SP 800-162). In practice, you start with RBAC because it's easier to manage—you don't want to write a hundred policies for a hundred users. Then you layer ABAC on top for the decisions that matter: "Sales can access the CRM, but only during business hours and only from a compliant device." That's the pattern we recommend: RBAC for the baseline, ABAC for the edge cases.
Doesn't zero trust mean I have to re-architect everything?
No, but it does mean changing how you think. Zero trust is a set of paradigms that focus on users, assets, and resources, not on network location (NIST SP 800-207). You don't need to rip out your VPN tomorrow. But you do need to start treating every request as untrusted, even if it comes from inside your network. The OMB M-22-09 memo pushed federal agencies to adopt specific zero trust goals, including phishing-resistant MFA, by FY2024—and that's a good benchmark for the private sector too.
Why is everyone talking about phishing-resistant MFA?
Because not all MFA is equal. CISA calls phishing-resistant MFA the "gold standard" and identifies two forms: FIDO/WebAuthn and PKI-based (like PIV cards) (CISA). Regular MFA—like SMS codes or push notifications—can be defeated by phishing, push bombing, and SIM swaps (CISA). The attack on your CEO's account would have failed if he'd used a passkey, because passkeys are origin-bound and can't be presented to a look-alike site (Microsoft Passkeys). That's why we now recommend passkeys (FIDO2) as the default for any privileged role.
What's the deal with OAuth 2.0 and JWT—are they authorization or authentication?
This is a common confusion. OAuth 2.0 is an authorization framework, not an authentication protocol (RFC 6749). A bearer token just says "this party can access this resource"—it doesn't prove who they are (RFC 6750). That's why OpenID Connect (OIDC) was built on top: it adds a signed ID token that proves authentication (OpenID Connect). If you're using OAuth for both, you're doing it wrong. And if you're using JWTs, remember they're self-contained but must be verified—the signature ensures the content wasn't tampered with (RFC 7519).
How do I enforce least privilege without breaking everything?
Least privilege means granting only the minimum access needed for a job (Tenable). It sounds simple, but it's a pain. The trick is to combine it with just-in-time (JIT) access for privileged tasks. Tools like Microsoft Entra PIM give you time-based and approval-based role activation (Microsoft PIM). For example, you can let a support engineer request admin rights for 30 minutes, with approval from a manager, and require MFA to activate. That way, you're not handing out standing privileges that become attack surface.
Is ABAC the answer to everything?
No. ABAC is powerful, but it's complex. NIST SP 800-162 defines it as evaluating attributes of subject, object, action, and environment against policies. That's great for fine-grained control, but it can become a policy spaghetti. We've seen teams try to replace RBAC with ABAC and end up with a mess. The pragmatic answer: use RBAC for the 80% of static permissions, and ABAC for the 20% that need context. And don't forget separation of duties—a principle that splits critical functions so no single person can commit fraud (NIST SP 800-53).
So what's your actual recommendation?
Stop thinking of authorization as a one-time decision. Start with RBAC as your baseline, layer on ABAC for context, enforce least privilege with JIT access, and protect privileged roles with phishing-resistant MFA (passkeys or PIV). And adopt zero trust principles: never trust based on network location, always verify every request (NIST SP 800-207). It's not a one-size-fits-all, but it's a strategy that works.
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!