Role-Based Access Control (RBAC)
Abbreviation: RBAC
Pronunciation: ROHL bayst AK-sehs kun-TROHL (R-B-A-C)
Also known as: Role-Based Access Control, RBAC
Definition
Role-based access control assigns permissions to defined roles and grants users or services access by assigning them appropriate roles.
Overview
Understand the idea
Roles group capabilities such as viewing payments, issuing refunds, approving payouts, managing credentials, or administering users. RBAC simplifies permission management compared with assigning every permission separately to every identity.
Poorly designed roles become broad, overlapping, or permanent, creating privilege accumulation. A role name alone may not express resource scope, transaction limits, separation of duties, or contextual conditions. Shared accounts also destroy individual accountability.
Organizations should design roles around real job functions and least privilege, separate request and approval authority, and add resource or value limits where needed. Assignments require approval, expiry, periodic review, audit logs, and rapid removal when responsibilities change. Emergency access should be temporary and separately monitored.
What actually happens
Role-based access control assigns permissions according to roles such as cashier, support agent, accountant or treasury approver. In a payment business, different staff may need to view invoices, manage refunds and authorize withdrawals without all receiving the same unrestricted powers. RBAC reduces accidental changes and makes access easier to review, but its security depends on how roles and permissions are designed.
Administrators define specific actions and resources, group those actions into roles and associate users or services with roles. Every protected server-side action checks effective permissions rather than trusting hidden interface buttons. High-risk workflows should use separation of duties: the person creating a payout might not be allowed to approve their own instruction. Role changes, temporary elevated privileges and service-account keys should be logged and periodically reviewed.
Decisions and failure cases
Poorly designed 'admin' roles can defeat the whole model. Permission checks must cover API endpoints, exports and background tasks, not only dashboard navigation. RBAC does not replace cryptographic multisig or hardware key security for wallets holding significant funds.
Related concepts
Attribute-Based Access Control (ABAC), Wallet Access Control, Access Control Vulnerability.
Further reading
Example
A store's customer-support role may view payment status and submit refund requests but cannot change a destination wallet or release a large refund. A finance approver reviews refund evidence and authorizes execution. If the support account is compromised, the attacker cannot directly drain the treasury using that role alone.
Comparison
RBAC authorizes software actions based on assigned roles. API authentication identifies the caller; multisig controls on-chain signing. A secure payment stack may need all three.
Key Takeaway
Role-based access control assigns permissions to defined roles and grants users or services access by assigning them appropriate roles.
Sources
- NIST Documentation: Cyberframework — NIST (2026-07-30)