Category: Access Control Models

Access Control Matrix

Also known as: ACM, Access Matrix

Simply put

An access control matrix is a conceptual table used to describe who is allowed to do what within a system. Each row stands for a user or process (a subject), each column stands for a resource (an object), and each cell lists the actions that subject is permitted to perform on that object. It is primarily a model for visualizing and reasoning about permissions rather than a mechanism deployed directly at runtime.

Formal definition

The access control matrix is an abstract, formal security model that characterizes the protection state of a system as a two-dimensional matrix. Rows correspond to subjects (principals such as users or processes), columns correspond to objects (protected resources), and each matrix entry enumerates the set of access rights the given subject holds over the given object. As an authorization model, it defines permitted operations and is distinct from authentication, which establishes the subject's identity beforehand. In practice the full matrix is typically sparse and rarely stored directly; implementations commonly decompose it into per-object access control lists (columns) or per-subject capability lists (rows). It serves as a theoretical foundation underlying discretionary access control (DAC) and provides a reference framework for comparison against models such as RBAC and ABAC; specific representation and enforcement details depend on the system and are out of scope for the matrix as a model.

Why it matters

The access control matrix is foundational because it gives IAM practitioners a rigorous, unambiguous way to describe the complete protection state of a system: exactly which subjects hold which rights over which objects. As an authorization model, it makes explicit the mapping of permitted operations, which is invaluable when reasoning about whether a design grants excessive access or leaves gaps. Because it is a model rather than a runtime mechanism, its value lies in analysis, comparison, and communication rather than direct deployment.

The matrix also clarifies why most real systems never store the full grid. In practice the matrix is typically sparse, and implementations commonly decompose it into per-object access control lists (the columns) or per-subject capability lists (the rows). Understanding this decomposition helps architects recognize that ACLs and capability systems are two projections of the same underlying model, which in turn informs decisions about where and how permissions are best represented and enforced.

As a theoretical foundation underlying discretionary access control (DAC), the matrix serves as a reference framework for comparing against models such as RBAC and ABAC. It does not by itself establish who a subject is; authentication precedes it and is a separate concern. Keeping the matrix in mind as the abstract baseline helps teams evaluate whether a chosen model expresses the intended protection state accurately, without presenting any single model as universally superior.

Who it's relevant to

Security Architects

Architects use the access control matrix as a conceptual baseline for reasoning about a system's protection state and for comparing candidate authorization models such as DAC, RBAC, and ABAC. It helps them decide whether a design should be represented as per-object access control lists or per-subject capability lists, depending on the system's needs.

IAM Engineers

Engineers benefit from recognizing that ACLs and capability lists are two projections of the same underlying matrix. This framing clarifies how permissions map subjects to objects and why the full matrix is typically sparse and not stored directly, informing choices about representation.

Identity Governance Leads

For those overseeing access reviews and certification, the matrix offers a clear conceptual model of who can perform which actions on which resources. It aids in articulating expected permission mappings, though the model itself addresses authorization state rather than lifecycle or runtime enforcement mechanics.

Compliance Officers and Auditors

The matrix provides an explicit, auditable framing of the mapping between subjects, objects, and access rights, useful when assessing whether granted access aligns with intended policy. As a model, it does not itself prescribe representation or enforcement details, which must be examined in the specific system.

Inside ACM

Subjects (Rows)

The principals in the model, typically users, groups, processes, or service accounts. Each row represents one subject whose permissions against every object are enumerated across the matrix.

Objects (Columns)

The protected resources such as files, records, devices, or services. Each column represents one object, and the intersection with a subject row holds the permissions that subject has on that object.

Access Rights (Cells)

The permissions granted to a given subject over a given object, for example read, write, execute, or delete. Each cell captures the authorization decision for that subject-object pair; note the matrix expresses authorization, not authentication or identification.

Capability Lists

A row-wise decomposition of the matrix, listing per subject the set of objects and rights that subject holds. Capability-based systems associate rights with the subject.

Access Control Lists (ACLs)

A column-wise decomposition of the matrix, listing per object which subjects hold which rights. ACLs are the most common practical realization in directories, file systems, and many services.

Conceptual Model Role

The Access Control Matrix is primarily a theoretical model that formalizes the authorization state of a system; in most deployments it is not stored as a literal dense matrix but implemented via ACLs, capabilities, or higher-level models such as RBAC or ABAC.

Common questions

Answers to the questions practitioners most commonly ask about ACM.

Is the access control matrix an access control model like RBAC or ABAC?

No. The access control matrix is a conceptual abstraction that represents the complete set of permissions as a mapping of subjects (rows) to objects (columns), with each cell holding the allowed operations. It is a way to describe and reason about access rights, not an operational model with its own policy-authoring approach. Models such as RBAC, ABAC, PBAC, or ReBAC can each be understood in terms of the effective matrix they produce, but they differ in how permissions are expressed and computed. Treat the matrix as an underlying formalism rather than as a deployment model you would select in place of RBAC or ABAC.

Does an access control matrix decide who a subject is, or only what they can do?

It concerns only what a subject may do, which is an authorization concern. The matrix presupposes that identification and authentication have already established which subject is acting; it does not verify identity. In an access flow, identification names the principal, authentication verifies that claim, and only then is the matrix consulted to determine authorization. Conflating the matrix with authentication is a common error, because the matrix says nothing about how a subject proved who they are.

How is an access control matrix typically stored, given that it is usually sparse?

In most real systems the full matrix is never materialized because it would be large and mostly empty. It is typically decomposed by column into access control lists, where each object stores the subjects and operations permitted on it, or by row into capability lists, where each subject holds the set of objects and operations it may access. Depending on the deployment, RBAC role assignments or ABAC policies serve as a more compact way of computing the same cells on demand rather than persisting them explicitly.

How does the matrix relate to runtime enforcement components such as a PDP and PEP?

The matrix represents the logical authorization state that a policy decision point (PDP) evaluates when it answers whether a given subject may perform a given operation on a given object. The policy enforcement point (PEP) intercepts the request and enforces that decision, while a policy information point (PIP) may supply attributes needed to determine the applicable cell in attribute-driven implementations. The matrix itself is the decision surface; the PDP, PEP, and PIP are the runtime machinery that consults and applies it. The matrix does not, by itself, enforce anything.

How do you keep the effective matrix accurate as entitlements change over time?

Keeping the matrix accurate is largely an identity governance and administration (IGA) concern rather than a runtime one. Provisioning and deprovisioning add and remove the subjects and rights that define cells, while periodic access reviews and certification campaigns validate that existing cells are still appropriate. Segregation-of-duties controls constrain which combinations of cells any single subject may hold. These lifecycle activities are distinct from the real-time evaluation of the matrix at access time, and both are needed for the matrix to reflect intended access.

How do you audit against an access control matrix in practice?

Auditing typically involves reconstructing the effective matrix, meaning the actual subject-to-object permissions currently in force, and comparing it to intended policy. When permissions are stored as ACLs or capability lists, or computed from RBAC assignments or ABAC policies, an auditor may need to resolve those representations into the effective cells to identify excess access, orphaned rights, or toxic combinations. The exact tooling and completeness of this reconstruction depend on the vendor and deployment, and derived or dynamically computed permissions can make a fully materialized view difficult to obtain.

Common misconceptions

The Access Control Matrix is a data structure that real systems store and query directly.

It is chiefly a conceptual or theoretical model. Because a full matrix would be large and sparse for any realistic system, deployments typically implement it indirectly through ACLs (by object), capability lists (by subject), or by deriving permissions from models like RBAC or ABAC rather than materializing every cell.

The matrix handles the entire access flow, including verifying who the subject is.

The matrix addresses only authorization, that is, what rights a subject has over an object. Identification and authentication are separate prior steps; the matrix assumes the subject has already been authenticated and represents only the resulting permission state.

ACLs and capability lists are different access control models from the matrix.

ACLs and capabilities are two complementary decompositions of the same underlying matrix, one organized by object (columns) and one by subject (rows). They express the same authorization information from different perspectives rather than being distinct models.

Best practices

Treat the Access Control Matrix as a conceptual reference for reasoning about authorization state, and choose an implementation representation (ACLs, capabilities, or a higher-level model) that fits your resource and subject scale rather than materializing a dense matrix.

Keep the matrix scoped to authorization decisions, and ensure identification and authentication are handled by separate, appropriately assured mechanisms before permissions are evaluated.

For systems with many subjects sharing similar rights, consider layering a model such as RBAC or ABAC over the raw matrix to reduce the number of individually managed cells and simplify administration.

Choose ACL (per-object) versus capability (per-subject) representations based on your review and query patterns, since object-centric access reviews favor ACLs while subject-centric provisioning may favor capabilities.

Periodically reconcile the effective permission state against intended policy through access reviews and certification, since sparse or drifting cells can indicate excessive or orphaned entitlements.

Document assumptions and limitations explicitly, noting that the matrix captures a point-in-time authorization snapshot and does not by itself enforce runtime decisions or lifecycle changes.