Skip to main content
Identity Authority
Category: Access Control Models

Capability-Based Access Control

Also known as: CBAC, Capability-based security, Capabilities-based access control
Simply put

Capability-Based Access Control is an approach to controlling access in which a subject holds a token, often called a capability, that both names a resource and specifies what actions the holder may perform on it. Instead of the system checking a central list to decide whether someone is allowed in, possession of the capability itself grants the permission. This model is used in various contexts, including operating system design and, in some proposals, resource-constrained environments such as IoT devices.

Formal definition

Capability-Based Access Control (CBAC) is an access control model in which authorization decisions are governed by unforgeable references known as capabilities. Conceptually, a capability can be represented as a pair (x, r), where x identifies an object and r denotes the set of rights the holder may exercise over it; this corresponds to storing an access control matrix by rows associated with subjects, in contrast to access control lists, which store the matrix by columns associated with objects. Because authority is bound to possession of the capability rather than to a subject's identity checked against a separate policy store, the model differs from identity- and list-oriented approaches such as RBAC, which associates permissions with roles assigned to identified subjects. Note that in security theory, capability-based security is broader than any single token implementation, and the specifics of capability issuance, delegation, and revocation vary by design and deployment context (for example, operating system kernels, IoT authorization schemes, or vendor feature-access systems such as Gravwell's CBAC). This entry addresses the access control model and does not, by itself, specify an authentication mechanism for establishing who a subject is.

Why it matters

Capability-Based Access Control matters because it inverts the assumption behind most enterprise access systems. In identity- and list-oriented models such as RBAC, the system authenticates a subject and then consults a separate policy store to decide what that identified subject may do. Under CBAC, authority travels with the subject in the form of an unforgeable capability that both names a resource and enumerates the rights the holder may exercise. This design can reduce reliance on centralized policy lookups at enforcement time, which is one reason it has drawn interest in operating system design and in resource-constrained settings.

The model's practical significance is clearest where centralized, identity-based authorization is expensive or awkward. Research on IoT authorization has described capabilities-based access control as a promising paradigm for handling the particularities of IoT systems, though the same work notes that existing systems are not without limitations. Because a capability grants access by possession, delegation can be expressed simply by handing over or minting a capability, but revocation is correspondingly harder: once a capability is distributed, invalidating it depends entirely on the specifics of the design, and there is no single mechanism that applies across all implementations.

It is important not to overstate what CBAC provides. Capability-based security in security theory is broader than any particular token implementation, and the properties an organization actually gets depend on how capabilities are issued, delegated, and revoked in a given system. Vendor feature-access systems that carry the CBAC label, such as Gravwell's, use the term for fine-grained access configuration and may differ substantially from operating-system-kernel capability models or academic IoT schemes. Readers evaluating a product or design should therefore examine its concrete issuance and revocation behavior rather than assuming a shared meaning across the label.

Who it's relevant to

Security architects
Architects weighing access control models should understand CBAC as a distinct alternative to identity- and list-oriented approaches such as RBAC. The row-versus-column framing of the access control matrix, capabilities storing rows by subject and ACLs storing columns by object, is a useful lens for reasoning about where authority lives in a design and how delegation and revocation will behave. Because CBAC addresses authorization and not authentication, architects must still specify how subjects are authenticated and how capabilities are protected.
IoT and embedded systems engineers
Capabilities-based access control has been described in the research literature as a promising paradigm for handling the particularities of IoT systems, which makes it relevant to engineers working in resource-constrained environments. The same work cautions that existing systems have limitations, so engineers should treat CBAC as a design space to be evaluated against their revocation and distribution needs rather than a turnkey solution.
Operating system and platform designers
Capability-based security has a long history in operating system design, where user programs may directly share capabilities according to capability principles. Designers working at the kernel or platform level should treat capabilities as a foundational authorization primitive whose properties depend on unforgeability and on how issuance, delegation, and revocation are implemented.
Administrators of products using the CBAC label
Some vendors use CBAC to name fine-grained feature-access systems; Gravwell, for example, uses Capability Based Access Control to configure users and groups with granular access to product capabilities. Administrators should read the specific product documentation rather than assuming the term carries the same meaning as academic or operating-system capability models, since the concrete issuance and revocation behavior varies by implementation.

Inside CBAC

Capability (token)
An unforgeable reference that both designates a specific resource and conveys the access rights the holder may exercise on it. Possession of the capability is what confers authority, so the capability itself combines identification of the object with the permitted operations.
Unforgeability
The property that a capability cannot be fabricated or altered by an unauthorized party. In most implementations this is achieved either through cryptographic protection (for example a signed or otherwise integrity-protected token) or through a trusted kernel or reference monitor that holds capabilities on behalf of subjects and prevents direct forgery.
Delegation by transfer
The ability for a holder to pass a capability, or a derived narrower capability, to another subject. Depending on the implementation, delegation may be constrained (for example attenuation to fewer rights) or subject to revocation controls.
Attenuation
The reduction of rights when a capability is copied or delegated, allowing a subject to hand off a subset of its own authority rather than the full set. This supports least-privilege sharing between subjects.
Subject-held authority
Authority is associated with the subject that holds the capability rather than being looked up centrally against the subject's identity at each access. This contrasts with models that evaluate a subject's identity or attributes against a policy at enforcement time.
Revocation mechanism
The means by which a previously granted capability is invalidated. Because authority travels with the token, revocation is generally more involved than in identity-centric models and typically relies on approaches such as indirection through revocable references, short lifetimes, or invalidation lists, depending on the implementation.

Common questions

Answers to the questions practitioners most commonly ask about CBAC.

Is a capability just another name for an access control list (ACL) entry?
No. The two represent access rights from opposite directions. An ACL is associated with a protected resource and enumerates which subjects may act on it, so the resource is the anchor point for authorization decisions. A capability is held by the subject and is an unforgeable reference that both designates a resource and conveys the rights to it. In most descriptions, this means authority travels with the holder of the capability rather than being looked up against a resource-side list. The practical consequences differ: capability systems tend to make delegation straightforward (you pass the capability) but can make revocation and central review harder, whereas ACLs centralize the resource's policy but complicate delegation. Neither is universally superior; the choice depends on the deployment's delegation, revocation, and auditing requirements.
Does holding a capability mean the system has authenticated the user who presents it?
No. Capability-based access control is an authorization model, not an authentication mechanism. Possession of a valid capability typically demonstrates that the holder has been granted certain rights to a designated resource, but it does not by itself establish or verify the holder's identity. Identification and authentication are separate, prior steps. In some designs capabilities are deliberately identity-agnostic, meaning any principal who holds the capability may exercise it regardless of who they are, which is a defining property rather than a flaw. Where identity binding matters, it must be arranged separately, for example by controlling how capabilities are issued and to whom, or by combining the capability with an authenticated channel. Whether a given system does this depends on its configuration.
How is delegation typically handled in a capability-based system?
In most capability designs, delegation is performed by transferring or deriving a capability rather than by editing a central policy. A holder who possesses a capability can, depending on the system's rules, pass it to another party or mint an attenuated version that carries a reduced set of rights. This makes delegation a native operation rather than an administrative one. The trade-off is that once a capability has propagated, tracking where authority now resides can be difficult unless the system provides supporting mechanisms. Whether attenuation, further re-delegation, or delegation limits are permitted varies by implementation and should be treated as a design decision rather than an assumed feature.
What options exist for revoking a capability once it has been distributed?
Revocation is often cited as the harder problem in capability systems because authority is distributed to holders rather than centralized at the resource. Commonly discussed approaches include indirection, where capabilities point at an intermediary object that can be invalidated to cut off all references at once; expiration, where capabilities are time-limited so authority lapses without explicit action; and generational or versioned references, where advancing a resource's version invalidates outstanding capabilities. Each approach has costs, such as added lookup overhead or coarse-grained revocation that affects more holders than intended. The suitability of any option depends on the specific implementation and its performance and granularity requirements.
How do capability-based approaches relate to token concepts in web and API systems?
Some token-based designs express capability-like properties, in that a bearer token grants its holder the rights it represents without a separate identity check at the point of use, which parallels the capability principle that authority travels with the holder. Whether a particular token is a true capability depends on its semantics and how the system validates and constrains it. Care is needed not to conflate distinct concepts: a token being self-contained and signed establishes integrity and origin, not confidentiality, and does not by itself make the token a capability. Any mapping between capability theory and a specific token format should be evaluated against that system's actual issuance, scoping, and validation behavior rather than assumed.
How does capability-based access control coexist with governance and review requirements?
Because authority in a capability model is distributed to holders and can be delegated by them, producing a complete, resource-centric view of who currently holds which rights can be more challenging than in models where policy is centralized. Governance concerns such as periodic access reviews, certification, and segregation-of-duties checks generally assume the ability to enumerate effective access, so deployments using capabilities typically need supporting mechanisms to record issuance, delegation, and revocation for audit purposes. How well this is supported depends heavily on the implementation, and teams should confirm what visibility and reporting the system provides before relying on it for compliance-driven review processes.

Common misconceptions

Capability-based access control is just a synonym for access control lists (ACLs) viewed from a different angle.
While both express permitted subject-object-operation relationships, they differ in where authority is anchored. An ACL is attached to the resource and is consulted against the requesting subject's identity at access time, whereas a capability is held by the subject and its possession itself conveys authority. This difference affects delegation, revocation, and how the enforcement point makes decisions.
Because a capability is unforgeable, holding one is equivalent to being authenticated.
Capabilities concern authorization, not authentication. A capability conveys what its holder may do on a designated resource; it does not by itself establish or verify who the holder is. Identification and authentication of a principal remain separate steps that a deployment may or may not require before capabilities are issued.
Capability-based access control makes revocation trivial because you just delete the capability.
Revocation is frequently one of the harder aspects of capability systems precisely because authority travels with the token and may have been delegated or copied. In most deployments revocation depends on additional mechanisms such as indirection, short-lived tokens, or invalidation lists rather than a single central policy update.

Best practices

Design capabilities to carry the least authority needed and support attenuation, so that delegated or shared capabilities grant only a subset of rights rather than full authority.
Choose and document an explicit unforgeability mechanism (cryptographic integrity protection or a trusted mediating component), and remember that integrity protection alone does not provide confidentiality unless the token is also encrypted.
Plan the revocation strategy up front, since authority travels with the token; consider approaches such as short lifetimes, indirection through revocable references, or invalidation lists depending on your deployment constraints.
Keep authentication and authorization as distinct steps: decide separately how principals are identified and authenticated before capabilities are issued, and do not treat possession of a capability as proof of identity.
Be explicit about how capabilities are transferred and audited so that delegation events can be traced, and evaluate whether your governance and access-review processes can account for authority that has been passed between subjects.
Evaluate capability-based control against alternative models (such as ACL- or identity-centric approaches) for your specific use case rather than assuming it is universally preferable, and document the trade-offs in delegation, revocation, and auditability.
Promotional banner for the Pentest Readiness checklist download