Category: Access Control Models

Mandatory Access Control

Also known as:

Simply put

Mandatory Access Control (MAC) is a type of access control in which a central authority sets the rules about who can access what, and those rules are enforced uniformly across the whole system. Individual users typically cannot change or override these permissions themselves. It is commonly associated with high-security environments such as government and military systems.

Formal definition

Mandatory Access Control (MAC) is an access control model in which a central authority defines an access policy that is uniformly enforced across all subjects and objects within a system, rather than leaving access decisions to the discretion of resource owners. In typical MAC implementations, access is regulated by comparing security attributes such as user clearance levels against object security classifications, with enforcement mediated by the system rather than by individual users. This distinguishes MAC from Discretionary Access Control (DAC), where object owners can grant or modify access at their discretion; the specific attributes, classification schemes, and enforcement mechanisms vary by deployment and platform.

Why it matters

MAC addresses a fundamental limitation of discretionary models: when resource owners can grant access at their own discretion, access sprawl and inconsistent policy enforcement become difficult to prevent or audit. By centralizing policy authority and enforcing it uniformly across all subjects and objects, MAC gives organizations a way to guarantee that access decisions reflect an organization-wide policy rather than the individual judgment of thousands of resource owners. This is why MAC is commonly associated with high-security environments such as government and military systems, where the consequences of unauthorized disclosure are severe and where classification schemes are already an established part of operations.

The trade-off is rigidity and administrative overhead. Because individual users typically cannot alter permissions, MAC deployments require careful upfront design of clearance levels, classification schemes, and enforcement mechanisms, and they tend to be less flexible than models where owners self-manage sharing. For this reason MAC is not universally preferable to other access control models; it is well suited to environments where uniform, non-overridable enforcement is a hard requirement, and less suited to collaborative settings where ad hoc sharing is the norm. Many real-world systems combine mandatory constraints with other models rather than adopting MAC wholesale, and the specific attributes and enforcement details vary considerably by platform.

Who it's relevant to

Security architects

Architects evaluating access control models need to understand where MAC's centralized, non-overridable enforcement is appropriate and where its rigidity becomes a liability. MAC is one option among several models, including RBAC, ABAC, and DAC, and selecting it typically depends on whether uniform, authority-driven enforcement is a hard requirement for the environment being designed.

Government and defense IAM teams

MAC is commonly associated with high-security environments such as government and military systems, where clearance levels and object classifications are already part of established practice. Teams operating in these settings are among the most likely to deploy MAC or MAC-influenced controls, since the model maps directly onto formal classification schemes.

System administrators

Administrators operating MAC-based systems should recognize that individual users typically cannot change or override permissions, which shifts the administrative burden onto correctly defining clearance levels, classifications, and enforcement rules at the central authority. The specific mechanisms available depend on the platform in use.

Compliance and audit officers

Because MAC enforces a centrally defined policy uniformly across all subjects and objects, it can simplify demonstrating that access decisions follow an organization-wide policy rather than ad hoc owner discretion. Auditors should still verify how classifications are assigned and how enforcement is implemented, since these details vary by deployment.

Inside MAC

Security Labels

Metadata attached to both subjects (principals) and objects (resources) that encodes sensitivity or classification. In MAC, access decisions are driven by comparing these labels rather than by owner-defined permissions.

Classification Levels

A hierarchy of sensitivity assigned to objects, commonly modeled as ordered levels (for example, unclassified through top secret in defense-oriented deployments). The specific level set depends on the policy and deployment context.

Clearance

The sensitivity level granted to a subject, which the system compares against an object's classification to determine whether access is permitted. Clearance is assigned by a central authority, not by the subject or resource owner.

Categories or Compartments

Non-hierarchical labels (often combined with hierarchical levels) that partition access along need-to-know lines. A subject typically must hold the required categories in addition to a sufficient level.

Central Policy Authority

The system-enforced authority that defines and assigns labels and clearances. Under MAC, individual users cannot alter access rules for objects they create, which distinguishes it from DAC where the owner controls permissions.

Enforcement Mechanism

The runtime component (typically embedded in the operating system or trusted reference monitor) that evaluates label comparisons on each access attempt and permits or denies the operation accordingly.

Common questions

Answers to the questions practitioners most commonly ask about MAC.

Is Mandatory Access Control just a stricter form of Role-Based Access Control?

No. MAC and RBAC are distinct access control models. In MAC, access decisions are governed by a central policy set by the system or a security administrator, and individual subjects cannot alter the labels or clearances that determine access. RBAC grants access based on roles assigned to users, and depending on configuration those role assignments may be delegated or modified by administrators or resource owners. The defining characteristic of MAC is that the policy is non-discretionary and enforced by the system regardless of the wishes of individual subjects or owners, which is a different premise from role-driven authorization.

Does MAC handle authentication for the users it controls?

No. MAC is an authorization model concerned with what a subject may do once it has been identified and authenticated. Determining who a principal is (authentication) is a separate step handled by other mechanisms. MAC operates after identification and authentication have occurred, evaluating the subject's security attributes such as clearance against the security labels of the objects being accessed. Conflating the two would misrepresent where MAC sits in an access flow.

Where does MAC typically get deployed rather than more flexible models?

MAC is most associated with environments that require enforced, non-discretionary policy such as military, government, and other high-assurance systems where information classification levels must be strictly maintained. Some operating system security frameworks implement MAC-style enforcement for confining processes. In most general-purpose enterprise deployments, discretionary or role- and attribute-based models are more common because they accommodate delegated administration; MAC is chosen where central, uniform policy enforcement outweighs the need for that flexibility. This is a general observation, and the appropriate model depends on the specific security requirements.

How are security labels and clearances managed in a MAC deployment?

In a typical MAC deployment, objects carry security labels (for example classification levels and categories) and subjects carry clearances, both assigned and maintained centrally rather than by ordinary users. The enforcement engine compares subject clearance against object label according to the governing policy to permit or deny access. The specifics of how labels are structured, stored, and evaluated vary by implementation and vendor, so the exact mechanics should be verified against the particular system in use.

Can MAC and RBAC coexist in the same system?

Depending on the implementation, MAC and other models can be layered. A system may use MAC to enforce a non-discretionary baseline policy that no subject can override, while applying role- or attribute-based rules for finer-grained decisions within the bounds MAC permits. In such arrangements the mandatory policy typically acts as an outer constraint that other models cannot relax. Whether and how such layering is supported is entirely dependent on the platform, so this should be confirmed for a given product or framework.

What operational challenges commonly arise when running MAC?

Because MAC policy is centrally administered and non-discretionary, common operational considerations include the overhead of accurately labeling objects and assigning clearances, the reduced flexibility for users and resource owners to grant ad hoc access, and the need for disciplined processes to change labels or clearances. These characteristics are inherent to the model's design goal of enforced, uniform policy, and the degree to which they present difficulty depends on the deployment context and the tooling available. Governance activities such as reviewing clearance assignments are separate lifecycle concerns from the runtime enforcement MAC performs.

Common misconceptions

MAC and DAC are just two names for the same access control approach.

They differ in who controls access decisions. Under MAC, a central authority defines label-based rules that users cannot override, whereas under DAC the resource owner grants and revokes permissions at their discretion.

MAC is inherently more secure and should replace models like RBAC or ABAC.

No access control model is universally superior. MAC provides strong, non-discretionary enforcement suited to high-assurance and classification-driven environments, but its rigidity may be a poor fit for contexts better served by RBAC, ABAC, or other models. The right choice depends on requirements and deployment context.

MAC handles the full identity lifecycle, including provisioning and access reviews.

MAC is a runtime access enforcement model based on comparing labels at the moment of access. Governance concerns such as provisioning, certification, and segregation of duties are IGA functions and are typically out of scope for the MAC enforcement mechanism itself.

Best practices

Define a clear, documented labeling scheme for both subjects and objects before deployment, and ensure classification levels and any categories or compartments map to actual organizational sensitivity requirements.

Keep label and clearance assignment under a central authority, and prevent end users from altering the access rules for objects, preserving the non-discretionary property that distinguishes MAC from DAC.

Evaluate whether MAC fits the deployment context rather than assuming it is the strongest option; in many environments a combination with or substitution by RBAC or ABAC may better serve operational needs.

Rely on a trusted enforcement mechanism (typically an OS-level reference monitor) to evaluate label comparisons on every access attempt, and validate that it consistently mediates all relevant operations.

Coordinate MAC enforcement with separate IGA processes for provisioning, access reviews, and certification, since MAC governs runtime decisions and does not manage the identity lifecycle.

Periodically review label definitions and clearance assignments as sensitivity requirements evolve, documenting changes so audits can trace how access decisions are derived.