01Role-Based Access Control
RBAC answers who should receive access because of a recognised role—such as HR administrator, finance manager, service desk operator, application administrator or contractor coordinator. It is understandable and scalable, but broad roles can accumulate privilege and rarely express every contextual boundary.
02Attribute-Based Access Control
ABAC evaluates characteristics such as department, organisation, location, assurance level, employment status, classification, device state, business unit, project, time and current delegation status. It can express precise conditions, but only when attribute quality, policy ownership and explainability are governed.
03Delegated authority
Delegation answers a different question: who authorised this person to act, for what purpose, against which resource, and until when? It adds accountable authority to role and attribute context.
04Where each model alone falls short
Consider a "Finance" role granting broad transaction access: RBAC alone cannot express that one holder is approved to spend up to $5,000 while another is approved up to $50,000, or that a regional finance officer should only see transactions for their own region—the role is the same, but the appropriate authority is not. ABAC alone can encode the spend threshold and region as attributes, but on its own it cannot explain who decided this particular person should hold that threshold, or for how long the arrangement is meant to last. Combining role, attributes and delegated authority produces a decision that is precise and defensible: the role sets the baseline function, attributes constrain it to the right region and context, and delegation records the accountable approval, scope and expiry behind the specific authority being exercised.
05Use them together
A role can establish a baseline, attributes can constrain the context, and delegation can authorise a bounded exception or business action. The resulting decision should remain explainable to the person, owner and auditor.