Discuss the difficulty in using true role-based access control for every system throughout an…

Discuss the difficulty in using true role-based access control for every system throughout an organization. Support your answer with material from the academic literature.
True role-based access control (RBAC) — where every system, application, and resource across an organization is governed solely by a coherent set of well-designed roles — is conceptually attractive but difficult to achieve in practice. The academic literature identifies multiple, interacting sources of difficulty that make enterprise-wide, “pure” RBAC impractical or extremely costly for many organizations.
Key difficulties
Role engineering and role explosion.
Deriving a stable, minimal, and business-aligned set of roles (role engineering) is hard: business processes and job functions are diverse and evolve, which leads to either overly coarse roles (violating least privilege) or an explosion of narrowly scoped roles (increasing administrative burden). The foundational RBAC literature emphasizes the importance of careful role design and the complexity of mapping organization semantics into roles (Sandhu et al., 1996; Ferraiolo & Kuhn, 1992).
Heterogeneous and legacy systems.
Many enterprise environments contain legacy applications, bespoke systems, and third-party services that lack native RBAC support or expose incompatible access-control models (ACLs, capability-based, proprietary). Integrating all such systems under a single RBAC regime often requires custom connectors, middleware, or re-architecting applications, which is costly and error-prone (Sandhu et al., 1996).
Administrative scalability and maintenance costs.
Managing roles, role hierarchies, role assignments, and changes across many systems requires substantial administrative processes and tooling. Without strong automation and governance, day-to-day maintenance becomes a bottleneck and a source of configuration drift.
Separation-of-duty and policy conflicts.
Enforcing separation-of-duty, constraints, and cross-system policies is nontrivial: different systems may support different constraint mechanisms or none at all, making global policy enforcement difficult. Academic work on RBAC extensions and administrative models highlights these complexities when responsibilities span systems (Sandhu et al., 1996).
Dynamic, context-dependent requirements.
Some access decisions depend on attributes (time, location, device posture, risk score) or dynamic contexts that are awkward to model purely with static roles. This has motivated research and practice toward attribute-based and hybrid models (NIST and subsequent literature).
Role mining and discovery challenges.
When organizations try to derive roles from existing permission assignments (role mining), they encounter noisy, inconsistent permission sets and organizational changes that make extracted roles brittle. The role mining literature documents the practical and computational challenges in producing usable role sets from legacy data.
Organizational and political factors.
Roles must reflect business responsibilities, and decisions about role definitions often involve multiple stakeholders. Political resistance, differing interpretations of job functions, and decentralised governance make consensus on a single organization-wide role model difficult.
Cross-domain and federated environments.
In federated or multi-organizational settings (partners, cloud services), roles and trust boundaries differ. Mapping roles across domains or reconciling differing role semantics complicates an enterprise-wide RBAC deployment.
Implications and alternatives supported by the literature
Because of these difficulties, researchers and practitioners recommend pragmatic approaches rather than insisting on a single, universal RBAC implementation for every system. Common themes in the literature include:
Use RBAC where it fits well (e.g., centrally managed enterprise applications) but accept hybrid models elsewhere.
Adopt administrative RBAC extensions and governance processes to manage complexity and separation-of-duty requirements (see Sandhu et al., 1996).
Consider attribute-based access control (ABAC) or hybrid RBAC+ABAC approaches for context-sensitive decisions; NIST guidance and subsequent research highlight ABAC as a complementary or alternative model for dynamic, fine-grained control (NIST SP 800-162).
Invest in role engineering, role mining, and automation tools to reduce manual overhead; however, be realistic about the residual effort required and the likelihood of frequent role changes.
Use federated identity and standardized protocols (SAML, OAuth, OIDC) combined with careful mapping policies to bridge cross-domain differences while retaining local control where necessary.
Summary
In short, the academic literature supports the view that enterprise-wide, “pure” RBAC is difficult because of role-engineering complexity, legacy heterogeneity, scaling and administrative costs, policy conflicts, dynamic contexts, and organizational factors (Sandhu et al., 1996; Ferraiolo & Kuhn, 1992). The practical recommendation is to use RBAC where it yields clear benefits, complement it with attribute-based and federated mechanisms where appropriate, and invest in governance, tooling, and incremental migration to manage the complexity.
Selected references
Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-Based Access Control Models. IEEE Computer, 29(2), 38–47.
Ferraiolo, D. F., & Kuhn, D. R. (1992). Role-Based Access Controls. Proceedings of the 15th NIST-NCSC National Computer Security Conference.
NIST Special Publication 800-162 (2014). Guide to Attribute Based Access Control (ABAC) Definition and Considerations. National Institute of Standards and Technology.
Role mining and role engineering literature (see surveys and applied papers on deriving roles from permissions; these works document practical and computational challenges in producing stable, minimal role sets).