RBAC, ABAC, ReBAC: What Actually Holds Up in a Compliance Audit

I've sat in enough audit debriefs to know the pattern. The auditor doesn't start with your architecture diagram. They start with a list of names and a list of systems and they ask you to connect them. If your answer takes more than a few minutes to produce, you've already lost the room.

Role-based access control is the model most compliance teams default to, and for good reason — it's the one regulators have seen a thousand times. But it has a hole in it that shows up the moment someone asks a contextual question. Attribute-based and relationship-based models fill that hole, each in their own way, and each with their own audit headaches. Here's what I've learned about where each one actually holds up.

RBAC: The baseline that auditors already trust

Permissions attach to roles, users attach to roles, and that's the whole story. The ANSI INCITS 359 standard, which NIST maintains, defines Core RBAC as the mandatory floor for any system claiming to be RBAC (NIST RBAC). If you're building toward SOX or PCI, that standard is the vocabulary your auditor is already fluent in.

The practical upside: when someone asks why Jane in accounting can read the general ledger, you point at her role. The role carries the permission. Jane carries the role. You can produce that in seconds, which matters more than people admit. Audit findings often come down to how long it takes you to answer, not whether the answer is technically correct.

Separation of duty is where RBAC earns its keep. The standard spells out two flavors — static separation, where a user can't hold two conflicting roles at all, and dynamic separation, where they can hold both but can't activate them in the same session (NIST RBAC). Both map cleanly onto what SOX and PCI examiners want to see.

Where it falls apart is context. A nurse with the right role can read any patient chart, from any device, at any hour. That's fine until it isn't. I know of a case where a hospital discovered a nurse had pulled her ex-husband's records at 2 a.m. from a personal phone. RBAC had nothing to say about it. The role was valid. The access was not. The audit finding landed anyway.

ABAC: When the rule depends on the situation

Attribute-based access control looks at four things before it decides: the subject, the object, the action, and the environment (Cisco Duo). NIST SP 800-162 frames it as a methodology where you evaluate attributes against policies that describe what's allowed (NIST SP 800-162). Time of day, location, device posture — all fair game.

For compliance work, this is where you can encode regulation directly into policy. A HIPAA minimum-necessary rule becomes something like: allow if subject.role is physician, object.type is patient_record, object.relationship is treatment, and environment.location is hospital_network. That's not just enforceable — it's demonstrable. You can hand a regulator the exact policy that fired and the attributes it evaluated.

The cost is that ABAC policies are hard to write, harder to test, and genuinely painful to walk a non-technical auditor through. One bad attribute mapping and you've granted access to everyone. You also need a policy engine that can evaluate attributes in real time — NIST SP 800-207 describes a Policy Decision Point doing exactly that, weighing user, device, and environment state on every request (NIST SP 800-162).

Here's a concrete case I've seen work. A trading firm wanted to enforce that a trader could only execute trades during market hours, from a company-managed device, on the trading floor. RBAC couldn't express it. They wrote three ABAC conditions and shipped it in a week. The audit finding that had been open for two quarters closed the same month.

ReBAC: The model most auditors haven't seen yet

Relationship-based access control decides based on how subjects and objects are connected — not roles, not attributes, but the graph. It's the newest of the three, and in my experience it's the one that makes compliance teams go quiet for a second.

Picture a document platform. Alice owns a folder. She shares it with Bob. Bob shares a subfolder with Carol. Carol should see the subfolder, not the parent. RBAC can't do that without inventing a role for every sharing pattern, which gets absurd fast. ABAC can, but the policies balloon. ReBAC just walks the relationship path.

Precision is the selling point. Auditability is the problem. When a regulator asks why Carol saw that file, the answer is a chain of relationships, not a single assignment. You need tooling that can export and visualize the graph, or you'll be drawing it on a whiteboard during the exit interview. I've seen that happen. It doesn't go well.

How they compare, honestly

No single model wins. The pattern I keep recommending is RBAC as the base, ABAC layered on where regulation demands context, and ReBAC only when the access problem is genuinely graph-shaped. Start with RBAC because it's the dialect your auditor already speaks. Add ABAC where HIPAA's minimum-necessary rule or PCI's need-to-know requirement for cardholder data forces your hand. Reach for ReBAC when RBAC and ABAC would otherwise explode into thousands of roles.

And don't skip privileged accounts. NIST's own guidance describes them as providing elevated, often unrestricted access, and notes they show up in a disproportionate share of major breaches — the phrase 'keys to the kingdom' is theirs, not mine (NIST PAM). Vaulting, just-in-time elevation, session recording — all three models apply, but the blast radius is bigger. Budget accordingly.

One last thing that took me too long to internalize. Auditors don't care which model you picked. They care whether you can show who had access to what, why they had it, and whether it was appropriate. RBAC gives you clean evidence for stable jobs. ABAC gives you the context to prove appropriateness. ReBAC gives you precision on complex relationships, and charges you for it in audit effort. Layer them, log all three, and you'll get through the audit without the whiteboard.

Sources

• Tenable - https://www.tenable.com/cybersecurity-guide/learn/key-iam-components
• Cisco Duo - https://duo.com/learn/access-control-models
• NIST RBAC (INCITS 359) - https://csrc.nist.gov/projects/role-based-access-control
• NIST SP 800-162 (ABAC) - https://csrc.nist.gov/pubs/sp/800/162/final
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management