Mandatory vs Discretionary Access Control: The 2026 Enterprise Architecture Guide

Mandatory Access Control and Discretionary Access Control are the two foundational access-control models that the access-management literature has been organized around since the Trusted Computer System Evaluation Criteria (the Orange Book) defined the categories in 1985. Forty years later, the categories still frame how enterprise security architects reason about access policy — even though most production environments mix the two, layer additional frameworks (RBAC, ABAC) on top, and implement enforcement through systems that look very different from the 1985 reference monitor.

The distinction matters in 2026 because the regulatory framework still references it, the zero-trust architectures actively in deployment still depend on it, and the operational reality of mainframe-modern hybrid environments forces enterprise architects to compose both models cleanly. Confusing the two — or treating them as legacy concepts that have been superseded by modern frameworks — produces architectures where the policy intent and the implementation drift apart, which surfaces during audit review or incident response.

This piece is the 2026 reference on the boundary, the frameworks that overlay it, and the architecture that composes them. The companion pieces handle adjacent territory: Best IGA Solutions covers the governance layer that enforces policy, RACF vs ACF2 covers the mainframe-specific implementations, Mainframe Identity Modernization covers the integration architecture, and the ITDR piece covers the detection layer that runs above enforcement. This piece is the conceptual reference that frames all of them.

The defining difference. DAC enforces what owners specify; MAC enforces what the central authority specifies, regardless of owner. Modern enterprise architectures usually compose both — DAC at the resource fabric, MAC-style governance at the policy layer.

What each model actually enforces

Discretionary Access Control gives resource owners the discretion to decide who else can access resources they control. The canonical example is the Unix file permissions model — the file's owner sets the mode bits, the access control lists, and the group membership; other users can access the file only if the owner has granted that access. The system enforces what the owner specifies; the owner specifies what they decide. The discretion is the defining property.

DAC is operationally simple and matches how humans naturally think about ownership and sharing. It works well in environments where the policy intent is "owners know best who should access their stuff" and where the risk of an owner making a bad sharing decision is bounded — a personal computer, a small workgroup, a research lab. It works less well in environments where the policy intent is "the institution decides who accesses what, independent of who currently owns the resource" — defense systems with classification levels, regulated healthcare data with patient-privacy requirements, financial systems with segregation-of-duties controls.

Mandatory Access Control takes the discretion away. The system enforces access decisions based on centrally-defined security policy — classification levels, integrity labels, compartments, security categories — that owners cannot override. A user with Secret clearance cannot access Top Secret data even if the Top Secret owner explicitly grants permission; the system overrides the discretionary grant because the policy invariant takes precedence. MAC is operationally heavyweight (every access decision must consult the centralized policy) and rigid (the policy invariants are global), but it enforces policy invariants that DAC cannot.

The Bell-LaPadula model is the canonical MAC formalization. Users have clearance levels and need-to-know compartments; data has classification levels and category labels; access decisions are computed by comparing them according to the policy rules (no read up, no write down — the simple security property and the *-property in BLP terms). The Biba model is the integrity counterpart — instead of preventing confidentiality leakage, it prevents integrity contamination from low-integrity sources writing to high-integrity destinations. Most modern MAC implementations support both.

The key architectural property is that MAC enforces invariants the system administrator can audit and the user cannot bypass. DAC enforces what owners specify, which is whatever the current operational state of ownership delegations produces. The difference matters most in environments where the gap between policy intent and ownership reality has real security consequences — defense, financial, healthcare, critical infrastructure.

Three structural failures that drive enterprises toward MAC-style enforcement at the policy layer. The failures are not bugs in DAC; they are properties of pure discretionary delegation at enterprise scale.

The three failure modes of pure DAC at enterprise scale

DAC works at small scale and at enterprise scale when the enterprise can tolerate the failure modes. Enterprise environments that cannot tolerate them deploy MAC-style enforcement on top of (or instead of) DAC. Three failure modes drive the choice.

Discretionary delegation drift. In a pure DAC environment, every access grant is a sharing decision by some resource owner. Over time, those decisions accumulate. A user gets access to a project, the project owner moves to a new team, the new owner doesn't audit the inherited access grants, the original user still has access years later. Multiply this pattern across thousands of resources and thousands of ownership transitions, and the actual access state diverges substantially from any coherent policy intent. The access state reflects the historical sequence of owner discretion, not the current authorized state.

Confused-deputy attacks. When a process running on behalf of a user calls a system function that itself runs with elevated privileges, the system function might use the elevated privileges to access resources the calling user couldn't access directly. The classic example is the SUID Unix program — runs as root, can be called by any user, and might access files in ways the calling user wasn't authorized for. DAC alone has no mechanism to track which authority is actually being exercised; MAC enforcement labels can track that and prevent the confused-deputy pattern by enforcing label-flow constraints.

Information-flow leakage. DAC enforces who can read or write specific resources; it doesn't directly enforce constraints on where information can flow once it's been read. A user with read access to Confidential data can copy that data to a less-restricted resource, share it with users who couldn't have accessed the original, or transmit it to external destinations. DAC has no policy framework for this — it's a sharing decision the owner made. MAC enforcement, by attaching labels to data that propagate as the data flows, can detect and prevent these leakages.

The three failure modes are why DAC alone is insufficient for environments with strict policy invariants. They are also why most 2026 enterprise environments don't run pure DAC at the policy level even when DAC is what the underlying file systems support — the IGA and access governance layers add MAC-style enforcement on top, and the file system DAC becomes the enforcement substrate rather than the policy framework.

Where RBAC and ABAC fit, and why they aren't a third model

The most common 2026 architectural confusion is treating Role-Based Access Control and Attribute-Based Access Control as alternatives to MAC and DAC. They are not. RBAC and ABAC are policy-expression frameworks that can implement either MAC or DAC enforcement depending on how role and attribute assignments are governed.

RBAC assigns permissions to roles and roles to users. The role definitions are typically centralized — the IGA platform defines what each role can do — but the role-membership assignment can be either discretionary or mandatory. If individual managers or resource owners can assign roles to their team members, the implementation is effectively DAC at the role-assignment layer. If a central governance authority assigns roles based on HRIS source-of-truth, the implementation is effectively MAC at the role-assignment layer. The role-permission mapping itself is usually mandatory in modern enterprise environments (the IGA platform owns it), but the user-role mapping is where the discretion vs mandate distinction lives.

ABAC evaluates access decisions based on attributes of the subject (user role, employment status, location, device posture), resource (classification, owner, project), action (read, write, share, export), and context (time, risk score, recent behavior). The attribute definitions can be centralized or distributed, and the policy decisions can be discretionary (owners specify attribute-based rules for their resources) or mandatory (a central policy authority specifies enterprise-wide rules). ABAC is more expressive than RBAC for context-sensitive decisions, but more operationally complex; it composes with RBAC rather than replacing it.

The 2026 enterprise pattern is RBAC for everyday access decisions (which functional permissions does this role have), ABAC for context-sensitive overlays (allow this access only from managed devices during business hours), and MAC enforcement underneath for invariants that must not be bypassed (no Confidential data egress to personal email regardless of role or context). The composition is what makes the architecture work.

The implementation question is who controls the role-assignment, attribute-definition, and policy-rule layers. If these are governed centrally and the enforcement is system-wide, the architecture is functionally MAC enforcement implemented through RBAC/ABAC frameworks. If these are delegable to resource owners and managers, the architecture is functionally DAC enforcement using the same frameworks. The framework choice doesn't determine the model; the governance pattern does.

How mainframe security managers handle both models

The mainframe security managers — IBM RACF, CA ACF2, CA Top Secret — predate most of the modern access-control framework conversation, but they implement both MAC and DAC enforcement with high operational maturity. Understanding how they handle the distinction matters for any enterprise architecture that includes mainframe workloads, which is most large financial-services and government environments.

RACF (Resource Access Control Facility) defaults to a DAC-style enforcement posture for most resource classes. Dataset owners can grant access to other users and groups through standard RACF commands (PERMIT, ALTDSD); the access decisions are made by RACF's resource managers consulting the access lists the owners maintain. This is functionally DAC.

RACF supports MAC enforcement through security labels (SECLABEL) that implement Bell-LaPadula-style mandatory access control. A user is assigned a SECLABEL representing their clearance and compartment; resources are assigned SECLABELs representing their classification; the SECLCHECK system processing compares them on every access attempt and enforces the dominance and equivalence rules. SECLABEL enforcement is system-wide and cannot be bypassed by discretionary grants — exactly the MAC property. Federal and defense workloads on RACF typically use SECLABEL enforcement; commercial workloads typically do not.

ACF2 (Access Control Facility 2) defaults to a more restrictive posture — the "default-deny" semantics where any access not explicitly permitted by central rules is denied. This is structurally closer to a MAC model than RACF's default, though ACF2 supports discretionary delegation through its rule-set hierarchy as well. The ACF2 administrator has more centralized control over access patterns than the RACF administrator typically does, which fits some operational cultures better.

Top Secret falls between the two with a flexible policy model that can be configured for either DAC-style discretionary access or MAC-style centralized enforcement. The choice is typically driven by the workload's regulatory requirements rather than by the security manager's defaults.

The architectural point for an enterprise integrating mainframe security with modern IAM is that the MAC/DAC choice is already made on the mainframe side, and the modern integration needs to respect it. If the mainframe is using SECLABEL enforcement, the modern provisioning layer needs to coordinate user clearance assignments through the same SECLABEL framework. If the mainframe is using DAC-style enforcement, the modern provisioning can integrate at the access-list level. Mixing the two without explicit coordination produces incident-review questions about whether a given access was authorized by the mainframe policy or by the modern IAM workflow.

The four-layer composition that makes zero-trust architectures work over existing DAC and MAC fabric. Layer 1 enforces native, layer 2 governs centrally, layer 3 evaluates at runtime, layer 4 detects and responds. The architectural test is whether all four compose without producing decisions where it's unclear which layer authorized or denied.

The 2026 zero-trust composition

Zero-trust architectures don't replace MAC and DAC — they impose a runtime-evaluation requirement on top of whichever enforcement model the underlying systems use. The composition is what produces the 2026 architecture that satisfies zero-trust mandates while still working with the existing mainframe and DAC-fabric reality.

Layer 1: Resource enforcement. The underlying systems (file systems, databases, mainframe security managers, SaaS applications) enforce access decisions using whatever model they natively support. Unix file systems use DAC. RACF uses DAC by default, MAC with SECLABEL when configured. SaaS applications usually have application-defined access control that's some mix of RBAC and ABAC. This is the layer that actually decides whether a given read or write succeeds.

Layer 2: Identity governance. The IGA platform defines roles, attributes, and policy rules that determine what the resource-enforcement layer should be configured to allow. The governance layer drives the provisioning of access decisions into the resource layer. In 2026 deployments, this layer is typically mandatory in the MAC sense — the governance authority decides what access is authorized, and provisioning enforces it across the resource layer. The DAC failure modes (delegation drift, confused deputies, information-flow leakage) are mitigated by removing or constraining the discretionary delegation paths at this layer.

Layer 3: Runtime evaluation. The zero-trust policy engine evaluates access decisions at runtime, consuming the resource-layer decision plus contextual signals (device posture, behavioral risk, transaction value, time of day, recent authentication freshness) and produces an allow-deny decision that may override the resource layer's static permission. This is functionally MAC-style enforcement implemented at runtime rather than at provisioning time — the user has the permission according to layer 1, but the runtime policy may still deny the specific access based on context.

Layer 4: Detection and response. The ITDR layer monitors what's actually happening in the resource layer and runtime layer, detects anomalous patterns, and triggers response actions that may include emergency policy changes propagated back through layers 1 and 2.

The four-layer composition is what makes zero-trust architectures work over the existing DAC and MAC enforcement fabric without rip-and-replace. The DAC environments stay DAC at the resource layer; the MAC-style invariants are enforced through the governance and runtime layers; the runtime evaluation handles the context-sensitive decisions that pure DAC or pure MAC can't. The architectural test is whether the four layers compose without producing decisions where it's unclear which layer authorized or denied a given access.

What Avatier ships toward this pattern

Avatier Identity Anywhere Lifecycle Management implements RBAC and ABAC policy frameworks that can be configured for either discretionary or mandatory enforcement depending on the workload. The role-definition layer is centralized — Avatier governance owns the role-permission mapping — and role-assignment can be either delegable (DAC-style) or strictly HRIS-driven (MAC-style) based on the enterprise's policy choice. ABAC overlays handle the context-sensitive decisions that pure RBAC can't express.

For mainframe environments, Avatier integrates natively with RACF, ACF2, and Top Secret. The integration respects whichever access-control model the mainframe is configured for — RACF SECLABEL workflows on defense and federal workloads, DAC-style provisioning on commercial workloads, ACF2's default-deny posture where that's the configured mode. The lifecycle integration ensures that mainframe access assignments reflect the HRIS-driven joiner-mover-leaver authoritative state rather than whatever discretionary grants have accumulated over time. Our RACF vs ACF2 and Mainframe Identity Modernization pieces cover the mainframe-side architecture this depends on.

Access certification workflows enforce segregation-of-duties policies that cannot be bypassed by discretionary delegation — a MAC-style guarantee implemented through governance workflow rather than through resource-layer enforcement. SoD violations are detected at certification time and at runtime (when ITDR sees a violation pattern), with response actions that include automated rollback of the unauthorized state. The ITDR piece covers this detection layer in depth.

The Avatier Trust Center publishes our compliance posture (SOC 2 Type II zero exceptions, ISO/IEC 27001:2022, PCI DSS v4.0.1, CSA STAR Level 1, NIST 800-53 Rev. 5 aligned, CISA Secure-by-Design Pledge signatory). The architectural pattern works regardless of vendor — the point of this piece is not that you have to buy Avatier — but the integrated pattern of RBAC + ABAC policy expression, centrally-governed role assignment, mainframe-native integration, certification-enforced SoD, and runtime context evaluation is what separates an access-control architecture that enforces enterprise policy from one that just enforces whatever the historical sequence of owner discretion produced.

The honest closing

MAC and DAC are not legacy categories. They are the conceptual framework that the rest of the access-control vocabulary builds on, and the 2026 enterprise architectures still depend on the distinction even when the implementation looks nothing like a 1985 reference monitor. RBAC and ABAC are policy-expression frameworks that can implement either model; the model is determined by whether role-and-attribute governance is centralized or delegable. Zero-trust architectures impose a runtime evaluation layer that's functionally MAC at the policy level, even when the underlying resource layer is DAC. Mainframe environments make the choice explicit through RACF SECLABEL, ACF2 default-deny, or Top Secret hybrid configuration. The enterprises that compose the layers cleanly — DAC at the resource fabric, MAC-style governance at the policy layer, ABAC overlay for context, runtime evaluation for zero-trust — produce architectures that enforce the policy intent rather than the historical state. The enterprises that conflate the layers or treat the distinction as legacy end up with access states that nobody can explain when the audit shows up.