Every guide to access control types presents the same menu of DAC, MAC, RBAC, ABAC, and maybe PBAC, listed side by side as if you pick one and implement it. The menu is a myth. These aren't parallel options; they're different kinds of things entirely. Two are founding philosophies, one is a workhorse, several are refinements, and one is a governance layer. Here's what each type actually is, what job it does, and the combination real organizations end up running.
Ask what types of access control exist and you'll get a list. Four items, sometimes six, occasionally eight, presented like flavors. Discretionary, mandatory, role-based, attribute-based, pick the one that suits your organization.
The list format hides the most useful fact about these models, which is that they aren't the same kind of thing. DAC and MAC are answers to a philosophical question, who gets to decide access, written decades ago for operating systems and classified networks. RBAC is a provisioning workhorse that runs most of the corporate world. ABAC is a refinement that extends RBAC where one input isn't enough. PBAC is a governance layer that guards everything the others grant. ReBAC and context-based control are specialists that live inside particular applications and particular decisions.
Presenting them as a menu produces the wrong question, "which type should we choose?" The right question is "which jobs need doing, and which type does each job?" Most organizations, whether they know it or not, run four or five of these types simultaneously, each in its lane. This guide goes type by type, and then assembles the honest answer.
The Two Founding Philosophies: DAC and MAC
Before anything else, access control had to answer one question. Who decides? Two opposite answers produced the two oldest models, and every later model descends from how they resolved this.
Discretionary Access Control (DAC)
DAC's answer is that the resource's owner decides. You created the document, so you decide who reads it, who edits it, and who it gets shared with. Access is at the owner's discretion, hence the name.
DAC is the model you use every day without naming it. Sharing a Google Doc, adding a collaborator to a repository, granting someone access to a folder. All of it is owner-controlled, per-resource decision-making. It's intuitive, flexible, and maximally granular, which is why applications keep building it in.
It's also ungovernable at scale, and this isn't a flaw to fix but the model's nature. Thousands of owners making millions of individual sharing decisions produces an access landscape nobody can see whole, audit meaningfully, or clean up systematically. The confidential deck shared "temporarily" with an agency three years ago is DAC working exactly as designed.
DAC belongs inside applications, for collaboration-level decisions, under a governance umbrella that watches the applications themselves. It fails as an organization's primary access model.
Mandatory Access Control (MAC)
MAC's answer is that the system decides, and nobody overrides it. Resources carry classifications (confidential, secret, top secret), users carry clearances, and the system enforces the match. Not even the resource's owner can share it downward; the policy is mandatory.
MAC comes from military and intelligence environments, and it remains the right model there. When the cost of a single wrong disclosure is catastrophic and the data has formal classification levels, rigid centralized enforcement is the point.
For commercial organizations, MAC is almost always the wrong answer wearing an impressive uniform. The rigidity that protects state secrets suffocates a business, with every access decision routed through classification logic and no flexibility for the collaboration that commercial work actually is. Vendors occasionally pitch MAC-style controls to enterprises as maximum security. The pitch confuses maximum rigidity with maximum protection.
MAC belongs in government, defense, intelligence, and the rare commercial enclave handling formally classified material. It fails nearly everywhere else.
The Workhorse: Role-Based Access Control (RBAC)
RBAC answered the question neither philosophy handled. How does a company with hundreds of employees and hundreds of applications grant access predictably, at scale, without per-resource or per-classification decisions?
Permissions attach to roles, and people inherit access by holding roles. Define Sales Manager once, attach its applications and access tiers, and every sales manager receives exactly that set. The decision evaluates one input, the role this person holds.
That single-input design made RBAC the default access model of the corporate world, and it has stayed the default for decades because its three properties are exactly what organizations need most. Access becomes predictable (know the role, know the access), auditable (review 30 roles instead of 40,000 grants), and well-fitted to how companies already work, since organizations are structured around jobs and access genuinely follows the job 80 to 90 percent of the time.
RBAC's failure modes are equally well known. Roles multiply when second dimensions get encoded into role names, Sales Manager EMEA, Engineer-Contractor, until the directory holds 200 variants of 30 real jobs. Exceptions accumulate outside the model when no formal path exists for them. And roles are static, unable to express time, location, device, or combination conditions, because a role is a label, not a rule.
RBAC belongs as the baseline layer of nearly every organization's access model, kept at 20 to 40 job-function roles. It fails as the only layer, forced to express dimensions it structurally can't.
A note on a term you'll see alongside it. Group-Based Access Control (GBAC) is RBAC as it's actually implemented in identity providers, roles realized as directory groups, with applications assigned to groups and people inheriting through membership. Practically, GBAC is RBAC's deployment mechanism rather than a separate type.
The Refinement: Attribute-Based Access Control (ABAC)
ABAC extends the workhorse where one input stops being enough.
Access decisions evaluate combinations of attributes. These span properties of the user (role, department, location, employment type, clearance), the resource (sensitivity, category), and the context (time, device), joined with AND/OR logic. Production access requires Role equals Engineer AND Employment Type equals Full-Time AND Clearance equals Approved. Three questions instead of one, at the doors that warrant it.
The menu framing obscures the crucial fact that ABAC doesn't replace RBAC. Role sits inside nearly every ABAC rule as its first condition. ABAC is what happens when the decision genuinely depends on more dimensions than role, and instead of minting another suffixed role variant, you add the dimension as a condition. Roles stay flat; rules gain exactly the precision the real policy requires.
ABAC's honest cost is that attribute data quality becomes load-bearing. A five-condition rule fails silently through its least-maintained attribute, granting or denying against stale data with nothing announcing the failure. Under ABAC, directory sync stops being plumbing and becomes a security control.
ABAC belongs layered on RBAC, exactly where second dimensions are real, regional rules, employment-type constraints, clearance requirements. It fails when applied to every decision indiscriminately, buying complexity for grants that needed one question.
Two related terms resolve into ABAC's family. Rule-Based Access Control (confusingly also abbreviated RuBAC) means access governed by condition rules, if outside business hours, deny, which in practice is ABAC's environmental attributes under an older name. Context-Based and Risk-Based Access Control evaluate the circumstances of the access moment, device posture, network, location, behavioral risk scores, and represent ABAC's environmental dimension matured into adaptive decisions, like step-up authentication on an unusual login or restricted access from unmanaged devices. Useful, real, and structurally attribute logic applied to the session rather than the person.
The Governance Layer: Policy-Based Access Control (PBAC)
Every model so far answers grant questions about who should receive what. PBAC answers a different question entirely. What must hold true across all access, provably, regardless of how it was granted?
Explicitly authored policies define violations and consequences. No identity holds both vendor creation and payment approval. Every finance application has an owner. No contractor holds production access. Policies evaluate the actual access landscape, whatever granted it, and act on violations by logging them, alerting on them, or automatically remediating them.
Here's the distinction that matters, because PBAC's evaluation logic looks like ABAC and the resemblance misleads. What makes a policy a policy is structural, not logical. A policy is owned by a named person, versioned on every change, testable in a detect-only mode before it enforces, and auditable through its own independent trail of runs, violations, exemptions, and remediations. A clever condition buried inside a workflow has none of those properties. PBAC is a governance model, and the governance is the point.
PBAC belongs as a deliberately small guard layer, a dozen owned, validated policies enforcing the invariants with audit weight, above whatever grant models operate below. It fails as a replacement for grant models, running policy evaluation on every routine provisioning decision that a role would have handled in one lookup.
The Specialist: Relationship-Based Access Control (ReBAC)
Access follows relationships between the user and the specific resource. The doctor can access records of patients they treat. The manager can approve expenses of their direct reports. The document owner's delegate can edit that owner's documents. The decision isn't about the user's role or attributes in general; it's about their relationship to this exact resource.
ReBAC powers the sharing models of the applications you use daily, Google Drive's ownership chains, GitHub's repository relationships, and it's the natural model for fine-grained, resource-level authorization inside multi-tenant and collaboration platforms.
ReBAC belongs inside applications, implemented by the application, for resource-level decisions the application's own data model defines. It fails as an organization-wide model, because relationships live in application databases, not in your identity layer. ReBAC is the reminder that some access control is the application's job, and the organization's job is governing the applications.
The Types at a Glance
The Combination You Actually Run
Strip away the menu myth and the realistic architecture looks the same in most organizations.
RBAC as the baseline. Twenty to forty job-function roles determining default access, handling the 80 to 90 percent of decisions that follow the job.
ABAC as the refinement. Attribute conditions layered onto the roles exactly where decisions depend on more than one dimension, region, employment type, clearance, with the context and risk-based variants handling session-level adaptation where it matters.
PBAC as the guard. A small set of owned, versioned policies enforcing what must never be true, regardless of what the grant layers did, producing the execution history that turns audit assertion into audit evidence.
DAC and ReBAC inside the applications, doing the resource-level work that belongs to applications, under a governance layer that at least knows the applications exist and who holds access to them.
And MAC nowhere, unless you're reading this from a defense contractor.
The layers aren't rungs on a maturity ladder. They coexist from the day an organization passes a few dozen employees, whether anyone architected them or not. The difference between organizations with good access control and everyone else isn't which type they picked. It's whether each rule sits in the layer built for it, or whether roles are absorbing attribute pressure by multiplying, invariants are scattered across unowned workflow conditions, and application-level DAC sprawl proceeds with no umbrella above it.
How the Types Map in Zluri
One clarification before the mapping, because it keeps every expectation honest. Zluri is not an authorization runtime engine. It doesn't sit in the request path deciding, in the moment, whether a user's click on a resource goes through. That runtime job belongs to the applications themselves or to dedicated authorization services embedded in them.
What Zluri does is manage and govern access to third-party SaaS applications (via its Access Management module inside the IGA product,) deciding who gets provisioned into what, at which tier, under which conditions, and continuously evaluating the access that exists. The types map onto that governance layer.
The RBAC layer runs on condition-based playbooks. Designation and Department sync from your HR system, Add and Apply Conditions scope applications and tiers per role, and Automation Rules fire provisioning whenever a role attribute matches.
The ABAC layer is the same condition system with the checklist lengthened. Rules combine multiple attributes with AND/OR logic, drawing on standard fields plus unlimited Custom Fields, so moving from role-only to role-plus-attributes is configuration rather than migration.
The PBAC layer runs in a dedicated Policy module. Each policy carries named Owners and Assignees, a scoped population, and testable rules. Monitor mode validates a policy against real data before enforcement switches on, every publish is versioned, and violations stay traceable end to end. Segregation of Duties operates as a specialized policy type on the same model.
The DAC and ReBAC activity happening inside applications sits under the discovery and governance umbrella. The platform can't make a Google Drive sharing decision, but it knows Drive exists, who has access, at what tier, and whether that access survived its last review. That umbrella is exactly what those in-app models need above them.
Stop Choosing From the Menu
The types of access control were never flavors of one thing. Two are founding philosophies about who decides. One is the workhorse that runs the corporate world. One is the refinement for decisions with real second dimensions, one is the governance layer that guards everything below it, and the rest are specialists doing resource-level work inside applications.
The organizations that get this right don't pick a type. They run the stack. Roles grant the baseline, attributes refine the exceptions, policies guard the invariants, and application-level models do their local jobs under a governance umbrella that sees the whole.
Choose jobs, not flavors, and give every rule the layer it was built for.
Frequently Asked Questions
What are the main types of access control?
The commonly listed types are Discretionary (DAC), Mandatory (MAC), Role-Based (RBAC), Attribute-Based (ABAC), Policy-Based (PBAC), and Relationship-Based (ReBAC), with rule-based, context-based, and risk-based control operating as ABAC's environmental family and group-based control (GBAC) as RBAC's deployment mechanism in identity providers. They aren't parallel options. DAC and MAC are founding philosophies, RBAC is the grant workhorse, ABAC refines it, PBAC governs above it, and ReBAC works inside applications.
Which type of access control is best?
None individually, because they do different jobs. The realistic architecture for most organizations layers three of them. RBAC serves as the baseline (job-function roles handling most decisions), ABAC as the refinement (attribute conditions where decisions depend on more than role), and PBAC as the guard (owned, versioned policies enforcing global invariants). DAC and ReBAC continue operating inside applications, and MAC stays in government and defense contexts.
What's the difference between DAC and MAC?
They're opposite answers to who decides access. Under DAC, the resource's owner decides, which is flexible, intuitive, and ungovernable at scale. Under MAC, the system decides through classifications and clearances that nobody, including the owner, can override, which protects classified environments and suffocates commercial ones. Most organizations live with DAC inside their applications and have no use for MAC at all.
Is ABAC better than RBAC?
Wrong comparison, because they're not mutually exclusive, and serious implementations run both together. Role is the first attribute in nearly every ABAC rule. RBAC handles decisions that depend on one input, which is most of them, and ABAC lengthens the checklist exactly where decisions genuinely depend on more, region, employment type, clearance, instead of letting role variants multiply. The signal you need the ABAC layer is suffixed roles appearing in your directory.
Where does PBAC fit relative to the other types?
Above them, as governance rather than granting. RBAC and ABAC decide what access should exist; PBAC continuously evaluates what access does exist against owned, versioned policies and acts on violations, whatever granted the access originally. Its distinguishing features are structural, meaning named owners, version history, validate-before-enforce lifecycles, and independent audit trails, which is what makes a rule a policy rather than another condition.
.webp)
.svg)
