Why do RBAC programmes often fail even after the role design looks complete?

They usually fail because the design is treated as the finish line. If discovery is incomplete, roles miss part of the application estate. If automation is absent, humans keep making access decisions ticket by ticket. Over time, exceptions, grandfathered access, and manual workarounds turn the spreadsheet into a stale document rather than a control system.

Why This Matters for Security Teams

RBAC fails when teams treat role design as a static modelling exercise instead of an operating control. The spreadsheet can look complete while the underlying estate keeps changing: new apps are added, privileges drift, and exceptions accumulate faster than the role catalogue is updated. NIST SP 800-53 Rev 5 Security and Privacy Controls frames access control as an ongoing discipline, not a one-time design deliverable.

For NHI and machine-driven environments, this gap is even more dangerous because identities can be created, copied, and reused at speed. A role that appears clean on paper may still map poorly to service accounts, CI/CD pipelines, or API integrations that were never fully discovered. NHIMG research on The State of Secrets in AppSec shows that organisations often assume their controls are stronger than they are, even while fragmentation and manual work continue underneath. The same pattern appears in access governance: confidence rises before coverage does.

In practice, many security teams discover role decay only after a privileged access review, an audit exception, or a breach has already exposed the gap.

How It Works in Practice

Successful RBAC programmes are usually built as a lifecycle, not a design artifact. The first step is complete discovery of users, applications, service accounts, secret-backed automation, and the actual permissions each one uses. Without that inventory, role engineering becomes guesswork. The second step is usage analysis, which identifies recurring access patterns that can be grouped into roles without over-broad entitlement. The third step is enforcement through provisioning workflows, recertification, and deprovisioning so that role membership stays aligned with reality.

In mature environments, RBAC is often paired with NIST SP 800-53 Rev 5 Security and Privacy Controls to formalise least privilege, account review, and access removal. For non-human identities, the control plane must also account for workload identity, because secrets, tokens, and certificates do not behave like human accounts. That is why NHIMG analysis in the State of Secrets in AppSec is useful here: it highlights how fragmented secret handling and manual practices undermine central control, which is exactly what happens when role assignments and credential governance are managed separately.

• Discover all identities first, including service accounts and automation paths.
• Build roles from observed access patterns, not organisational charts.
• Attach provisioning and deprovisioning to workflow, not ticket memory.
• Review exceptions as temporary risk acceptances, not permanent roles.
• Measure role drift, orphaned access, and unused entitlements continuously.

These controls tend to break down when application teams create permissions faster than governance can inventory them, because the role model stops reflecting how access is actually consumed.

Common Variations and Edge Cases

Tighter RBAC usually reduces access sprawl, but it also increases modelling effort and operational friction, so organisations have to balance governance quality against delivery speed. Best practice is evolving around hybrid models because pure RBAC rarely fits cloud, SaaS, and automation-heavy estates cleanly.

One common edge case is when roles are technically correct but too coarse for sensitive workflows, forcing teams to rely on exceptions. Another is when identities are ephemeral, such as CI jobs or AI-driven services, where static role membership is a poor fit and just-in-time access or workload-based authorisation is a better pattern. Guidance increasingly suggests that role design should be paired with policy checks at runtime, especially where access depends on context, environment, or task scope. There is no universal standard for this yet, but current guidance clearly points away from treating RBAC as the only control.

NHIMG’s coverage of the DeepSeek breach is a reminder that once identities and secrets are exposed, the blast radius is shaped by how much standing access already exists. Role design cannot compensate for weak discovery, weak revocation, or uncontrolled exceptions.

Related resources from NHI Mgmt Group

• Why do IGA programmes fail even when the policy framework looks complete?
• Why do confidentiality policies fail even when the wording looks complete?
• Why do IdP backups fail even when the exported data looks complete?
• Why do IAM programmes still fail even after tool implementation?