Role-based access control (RBAC) is the dominant access management model in enterprise IT. 94.7% of organizations have used RBAC at some point, and 86.6% still consider it their top access control model as of 2026.1 Yet most published material treats RBAC as a theoretical framework. We focused on what actually happened when real organizations deployed it the specific problems they faced, the configurations they chose, and the outcomes they measured.
We also cover where RBAC is hitting its limits, particularly with agentic AI, multi-cloud environments, and tightening compliance obligations under updated HIPAA rules and the EU’s NIS2 Directive.
Real-life RBAC Examples
1. Dresdner Bank
A major European bank with 368 distinct job functions and over 1,300 organizational roles reached a point where its access management had become a liability rather than a control.
Challenge: Manual Access Privilege Management
The bank restructured its security model around three RBAC-specific capabilities it previously lacked:
Demographic and departmental grouping: Before RBAC, the only classification axes were role, hierarchy, and organizational unit. RBAC allowed the bank to assign permissions based on a broader attribute set without creating a new role for each combination.
Role inheritance: This was the most consequential change. The bank had no inheritance structure, so related job titles carried no implicit permission relationship. A finance manager could not access monthly accounting notes without asking the accounting specialist to retrieve them. After implementing hierarchical role inheritance, the finance manager’s title automatically inherited the accounting specialist’s relevant permissions. The manual handoff disappeared entirely.
Centralized policy structure: Replacing application-level permission files with a unified RBAC policy layer gave administrators a single point of review for audits.
Why this matters for other organizations: The bank’s experience is not unusual. Permission sprawl at the application level is common in organizations that grew their software stack faster than their access governance model.
Example: Before RBAC implementation, the finance manager had to ask the accounting specialist to edit the monthly accounting notes. Now the finance manager accesses monthly accounting notes directly since the job title inherits the accounting specialist role.2
2. Interfaith Medical Center
U.S.-based multi-site community educational healthcare organization with 50,659 employees and 1,459 branches worldwide.
Challenge: Maintaining HIPAA Compliance
HIPAA requires setting role-based internal controls for employees to protect electronic healthcare patient data against inappropriate use.
Interfaith Medical Center administrators had to manually set the database configuration so only authorized employees (medical coders, healthcare managers) had access to patient data.
Solution and outcome: IT administrators used bulk management capabilities to create, remove, and edit numerous Active Directory accounts to set specific user permissions in single operation.
Centralized access management: Administrators ensured all network access is through login unique to employee and not shared.
Automated RBAC management: After bulk role-based access control implementation, company claims they can confidently manage 1,000+ user objects, 750+ mailboxes, and 850+ workstations with two DBAs and five help desk specialists. 3
Many hospitals now combine RBAC with time-bound access. Surgeon gets elevated access only during scheduled operation window, then permissions automatically revert.
For HIPAA violations assessed on or after January 28, 2026, inflation-adjusted penalty maximums are now $73,011 per violation for most tiers, with a calendar-year cap of $2,190,294 for willful neglect not corrected up from previously cited figures.4 Organizations citing older HIPAA fine tables in internal policies should update them.
3. Western Union
American international financial services firm with 5,000+ employees headquartered in Denver, Colorado.
Challenges Operating centralized identity warehouse: The company’s current systems didn’t allow them to glean source data from numerous apps in the identity warehouse, resulting in an unclear picture of user access controls. When managers requested access remediation, they had to go through the ticketing system; however, the system didn’t effectively update the user profile.
Time-consuming administration of access controls: Time spent administering access controls and reacting to regulatory changes was long. Each new hire required access to 7-10 applications and related permissions. Access was manually supplied, took ~20 minutes per person to submit access request and receive first-level approval.
Company expected to see who has access to which programs, services, and files, and how to assess whether that access complies with security policy.
Solution and Outcome: Western Union transitioned to identity and access management (IAM) platform with RBAC capabilities for ~750 applications.
Enhanced network visibility with an identity warehouse: Western Union began collecting all necessary role-based identity data from HR systems into a single identity warehouse, enabling full insight into users’ access privileges across a centralized environment with 600+ applications.
Robust user database management: Company claims role-based identity management solution streamlined provisioning procedure for departments that routinely hire new employees. Their provisioning of 50 users now takes 2.5 minutes, down from 14 minutes.5
Banks and fintech companies now treat RBAC as part of a zero-trust model with continuous auditing.
4. Kubernetes in Healthcare
Enabling RBAC in Kubernetes and actually enforcing it are two different things. A March 2026 account from a healthcare practitioner documenting a real HIPAA audit illustrates this clearly.6
What happened: The cluster passed documentation review. RBAC was technically enabled. But the audit found:
- Three misconfigured namespaces
- A service account with cluster-admin access that no one on the team remembered creating
- Patient data moving unencrypted between two internal services
Nothing was breached. But all three findings were audit failures, and any one of them could have produced a reportable incident.
The structural issue: HIPAA’s Security Rule requires specific technical safeguards, access controls, audit trails, unique user identification, encryption in transit, and at rest. Kubernetes RBAC covers the access control requirement, but does nothing about encryption or audit trail completeness on its own. Teams that check “RBAC enabled” on a compliance list without mapping each technical safeguard to a specific cluster configuration are not compliant; they are documented.
HIPAA-compliant Kubernetes clusters map RBAC to the minimum-necessary standard: human users linked to identity provider groups via OIDC/SSO with MFA, ClusterRoles reserved for unavoidable control-plane tasks, namespace-scoped RoleBindings as the default, and service accounts for workloads only.7
5. Cloud Platforms: How AWS, Azure, and Google Cloud Structure RBAC in Practice
The three major cloud providers each implement a variant of RBAC, but the architecture differences matter in practice.
AWS IAM
AWS IAM assigns permissions through policies attached to identities (users, groups, roles) or resources. Roles are the recommended mechanism for cross-service and cross-account access. Fine-grained control is available through policy conditions time of day, IP range, and MFA status, which moves AWS IAM toward attribute-based behavior while keeping RBAC as the organizational structure.
How it works in practice: A developer role in a production account might have read-only access to S3 and CloudWatch, with write access restricted to a separate deployment role assumed only during CI/CD pipeline execution. Separating the developer’s standing role from elevated deployment permissions is the application of least privilege within RBAC constraints.
Microsoft Entra ID + Azure RBAC
Azure RBAC is built around a four-level scope hierarchy. At the top sits the management group, which spans multiple subscriptions and is typically used by large enterprises to enforce policy across business units. Below that is the subscription, the primary billing and access boundary for most organizations. Inside a subscription sit resource groups logical containers for related resources like a web app, its database, and its storage account. At the bottom of the hierarchy are individual resources themselves.
Microsoft’s Defender for Cloud introduced Cloud Scopes and Unified RBAC, a single, cloud-agnostic layer that segments resources and controls visibility across AWS, Azure, and GCP simultaneously.8 This replaces the previous pattern where organizations managing multi-cloud environments had to maintain separate, non-interoperable role definitions per provider. For security teams running hybrid environments, this is a material operational change.
Google Cloud IAM
Google Cloud IAM is organized around a four-level resource hierarchy. The organization sits at the top and maps to a company’s Google Workspace or Cloud Identity account. It’s the root node that all resources ultimately belong to. Below that are folders, which group related projects and are typically used to mirror internal structure: business units, teams, or environments like production and staging. Projects sit inside folders and act as the primary boundary for resource management, billing, and access control. Individual resources, Compute Engine instances, Cloud Storage buckets, and BigQuery datasets sit at the bottom.
Service account principal sets allow referencing all service accounts in a project, folder, or organization in allow, deny, and access policies, useful for organizations managing large service account populations. Self-granting missing permissions from error messages (GA February 27, 2026) reduces the friction of permission debugging.9
At Google Cloud Next ’26, Google also announced a streamlined predefined roles catalog with simplified administrator, editor, and viewer roles, an IAM role picker, and the ability to require re-authentication for sensitive actions.10
6. VLI
Rail-based logistics provider in Brazil. Manages railroad system, 100 locomotives, over 6,000 train vehicles, with 8,000 employees and 1,000 contractors.
Challenge: Complex Supply Chain Access Controls: The company had difficulties assigning access to records of goods movement and transactions.
VLI’s CISO: “We have ~9,000 employees who need to use various systems to move trains, and we need a governed system for better timing; employees cannot wait to have access to unload the truck.”
Truck drivers and train operators had to continually sign on to systems to obtain information and transactions as part of their cargo routine, which slowed the process and reduced productivity. Despite the presence of vast IT and development teams, there was no mechanism to detect or track privileged individuals who accessed VLI servers.11
Solution and Outcome: VLI migrated to centralized user access control platform.
Fast user access management: VLI reached capacity to give the right users access to relevant resources at the right time. Reduced user access request response times from 5 days to seconds.
Secured servers: Secured servers by removing the requirement for shared authorized login information.
Reduced risk of malware and ransomware attacks: Limited number of non-administrator users with administrative access on endpoints and set up lists of reliable and untrusted apps and instructions, minimizing risk of cyber attacks.
7. Nine Entertainment
Australia’s largest domestically owned media company.
Challenge: Access Control Permissions: Maintaining custom-built solutions became a huge load on technical staff since they failed to manage thousands of access control permissions.
Solution and Outcome: Nine Entertainment created a unified directory with real-time AD sync and MFA to build standardized RBAC procedures.12
Unified access management: The company effectively uses 200+ connections to provide access to 50+ applications and multiple WordPress sites based on custom-built permissions.
Improved authentication controls: With software implementation, Nine Entertainment users no longer need to enter MFA codes; authentication occurs smoothly.
Example: With identity management and RBAC features, Nine Entertainment could detect users logging in from any location, such as the home office. If the user needs to enroll with identity-based authentication, they’re guided via a self-service, wizard-based enrollment procedure.
8. SaaS and Multi-Tenant Applications: The Role Explosion Problem
Customer support platforms, project management tools, and SaaS CRMs represent a distinct RBAC challenge.
This is manageable at four roles. The problem emerges when teams start accommodating exceptions.
This is a role explosion. It’s a structural failure mode of RBAC, not an edge case. It happens specifically when organizations try to encode policy variations, conditions, exceptions, and context into role names rather than into a policy engine designed to handle them.
How organizations address it:
The practical solution is a hybrid model. RBAC handles the baseline job-function roles that are stable and well-defined. ABAC (Attribute-Based Access Control) or PBAC (Policy-Based Access Control) handles the conditions: time of access, device health, data classification level, and geographic location.
9. RBAC and Agentic AI: The 2026 Structural Problem
Traditional RBAC was designed for human users with stable identities and predictable access patterns. AI agents are neither.
At RSAC 2026, Oasis Security CEO Danny Brickman described the core issue: “An agent is as good as the access that is being granted to it. An agent without access basically means nothing. An agent with full access to your enterprise data has the full potential value given to the organization.”13
The problem is not simply that AI agents need roles. It’s that they operate differently from human users in ways that break RBAC’s core assumptions:
- Machine identities already vastly outnumber human ones in most enterprise environments
- Agents change state dynamically. The same agent handling routine tasks one moment may need escalated access the next
- An agent that inherits a user’s full permissions (common in early deployments) creates inherited over-privilege at scale
- The audit log shows the agent’s identity, not the originating user’s identity, breaking accountability
IANS Research identified Model Context Protocol (MCP) solutions as the specific integration pattern where current authentication and authorization structures are creating real exposure.14
The industry response is moving toward intent-based and just-in-time access models: temporary, narrowly scoped permissions provisioned when needed and automatically revoked, rather than standing roles that an agent holds continuously.15
What Is RBAC?
Role-based access control (RBAC) is model for managing user access to safeguard resources like information, applications, and systems from unauthorized access.
Figure 1: Role assignments of role-based access control
Problems Without RBAC
Applying the “least privilege” principle is difficult: Administrators can’t comprehend user roles and permissions. Might not identify the lowest degree of access an employee requires to accomplish tasks.
Onboarding takes longer: New-hire user permissions are submitted on a case-by-case basis via specific forms.
Job changes are complex: controlling access for people who switch jobs requires individualized adjustment requests.
Unauthorized access risk: Might involve misuse, causing mirrored access (Bert’s access appearing like Eva’s).
RBAC Demonstration: Assigning Roles and Permissions
Consider a dental office that subscribes to SaaS product to administer and promote healthcare services to potential customers with the following modules:
Billing module: Collects payments from insurance companies and patients for medical services covered by dental billing codes.
Sales module: Enables dental settings to categorize potential leads according to the likelihood of purchasing a product/service.
Setting Up Permissions
Dental office administrators use software’s user interface to assign permission access to various business functions.
Using drag-and-drop options, administrators create different permissions: “view,” “edit,” “create,” and “delete.”
Billing module permissions (billing manager only):
- view: billing_codes
- view: customer_ID
- create: invoice
Sales module permissions (sales manager):
- view: sales_database
- create: sales_database
- edit: sales_database
- delete: sales_database
After setting permissions, administrator creates “sales manager” role and assigns these permissions to that role, limiting other employees’ access to sales database.
Figure 2: Assessing RBAC policies for the “sales_manager” with user interface (UI) elements
Figure 3: Example of how the data.json file may look for the “billing_manager” and the “sales_manager” roles:
5 Benefits of RBAC
1. Limited Excessive Access
With the transition to cloud infrastructure, SaaS apps, and single sign-on (SSO), individuals and groups frequently inherit roles with excessive access. RBAC reduces this risk by defining groups and subgroups so that users have access only to what they need.
Example: Users submit images to a competition for the best travel photos. Only competition judges should see those photos. Policy allows any input in the “travel_photo_judges” position to examine the photo “travel_photo1997.jpg.”
This is accomplished via RBAC evaluation, which passes group information to the evaluation engine and determines if the input indicated in the permission request is a member of the group.
2. Unique Access Control Policies
RBAC systems provide more granular access control policies tailored to a company’s needs than mainframe systems do.
Example: RBAC systems administrators employ roles for administrative purposes by restricting network access based on an individual’s role, such as “guest user with limited permissions.”
3. Application Level Support
RBAC helps companies have a granular access approach by supporting permissions at the application level.
Example: RBAC can assign set of permissions in writing program that allows users to read, edit, and delete content.
4. Flexible Role Allocation
RBAC models build relationships between roles, permissions, and users. Two roles might be mutually exclusive, enabling single user to have two roles. Roles can inherit permissions provided to other roles.
Example: When permission is set, it can be allocated to numerous roles. Matt may hold both administrative and financial specialist roles, while Eva may only have a financial specialist role.
5. Demonstrating Compliance
Implementing RBAC helps financial institutions and healthcare providers demonstrate compliance with technical and operational standards, including HIPAA, PCI, and PHI.
Why Use RBAC?
Unauthorized network access accounted for 40% of third-party cyber intrusions in 2023. Considering that unauthorized access is one of the main drivers of data breaches, establishing RBAC is critical, especially for companies with several employees.
1. Improved Security
Minimized risk of unauthorized access: By assigning permissions based on roles rather than individuals, easier to ensure users only have access to information and resources necessary for their roles.
Apply the least privilege principle: Users are granted the minimum level of access required to perform their jobs, reducing the risk of internal data breaches and exposure to sensitive information.
2. Simplified Management
Ease of administration: Administrators can easily assign and manage user permissions by role rather than managing them on an individual basis.
Scalability: As organizations grow, new users are quickly assigned to predefined roles, streamlining the onboarding process and ensuring consistent access control policies.
3. Reduced Risk of Errors
Centralized control: Centralized management of roles reduces risk of human error in assigning permissions and ensures access policies are consistently enforced.
Clear accountability: Easier with RBAC to determine responsibility and accountability for access to sensitive resources.
4. Adhere to Compliance
Regulatory compliance: RBAC helps organizations comply with various regulatory requirements by ensuring access to sensitive data is controlled and documented.
Audit trails: Role-based nature of access control makes it easier to track and audit who has access to what resources, facilitating better monitoring and reporting.
Future of RBAC
Across industries, RBAC has shifted from:
Static job titles: Dynamic, task-based roles
Permanent permissions: Temporary, contextual access
Human-only control: Human and AI identity governance
RBAC is no longer just about “who can log in.” It’s about who can act, when, and under what conditions, with every action traceable.
Further reading
- Top 10 Microsegmentation Tools
- Intrusion Prevention: How does it work? & 3 Methods
- Network Security Policy Management Solutions (NSPM)
Reference Links
Cem's work has been cited by leading global publications including Business Insider, Forbes, Washington Post, global firms like Deloitte, HPE and NGOs like World Economic Forum and supranational organizations like European Commission. You can see more reputable companies and resources that referenced AIMultiple.
Throughout his career, Cem served as a tech consultant, tech buyer and tech entrepreneur. He advised enterprises on their technology decisions at McKinsey & Company and Altman Solon for more than a decade. He also published a McKinsey report on digitalization.
He led technology strategy and procurement of a telco while reporting to the CEO. He has also led commercial growth of deep tech company Hypatos that reached a 7 digit annual recurring revenue and a 9 digit valuation from 0 within 2 years. Cem's work in Hypatos was covered by leading technology publications like TechCrunch and Business Insider.
Cem regularly speaks at international technology conferences. He graduated from Bogazici University as a computer engineer and holds an MBA from Columbia Business School.
Be the first to comment
Your email address will not be published. All fields are required.