TL;DR: Static RBAC breaks down when identities, projects, and access scopes change faster than policies do, leaving organisations with role bloat, over-provisioned users, and stale permissions, according to Lumos. The editorial case for context-aware, just-in-time access is that governance now has to track behaviour and business change, not titles alone.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Lumos's blog post: Static role-based access control no longer matches how workforce and non-human access actually changes, so dynamic, context-aware controls are needed.
Why it matters: It matters because IAM, IGA, and PAM teams have to govern changing access patterns across people and non-human identities without letting entitlements accumulate unchecked.
Context
Static RBAC assumes the access needed by an identity can be defined cleanly from a job title or role and will stay valid for a meaningful period. That assumption fails when employees move between projects, contractors rotate in and out, applications multiply, and usage patterns shift faster than policy updates.
For identity governance, the issue is not simply more access requests. It is that roles, entitlements, and reviews become detached from actual work, which creates over-provisioning, redundant roles, and approval processes that no longer reflect current need.
Key questions
Q: What breaks when static RBAC is used for a changing workforce?
A: Static RBAC breaks when the identity’s work scope changes faster than the role model can be updated. Permissions linger after project moves, contractor changes, or app growth, so the role stops reflecting current need and starts preserving stale access. That creates role bloat, over-provisioning, and weaker access reviews because reviewers are validating history instead of present business context.
Q: What are the signs that standing permissions are creating governance risk?
A: Common signs include approval bottlenecks, developers and operators creating workarounds, credentials that remain active after the job is complete, and access reviews that confirm entitlements long after they were needed. Those symptoms show the organisation is governing access as a static asset instead of a time-bound control.
Q: How do security teams know whether cloud access reviews are still effective?
A: Cloud access reviews stop being effective when reviewers are approving flattened lists instead of meaningful bindings. A useful review shows the role, scope, and downstream inheritance so the reviewer can judge actual blast radius. If the list is too large for human judgment, the control has already lost precision.
Q: Should organisations keep RBAC and activity-based access control together?
A: Yes. RBAC still provides structure and auditability, while activity-based access control adds the missing context for real-time decisions. The practical model is layered: use roles to define the baseline entitlement, then use behaviour and context to decide whether a specific request should proceed, step up, or be restricted.
Technical breakdown
Why static RBAC breaks under changing identity scope
Role-based access control works best when work is stable, the application estate is small, and permissions map neatly to organisational titles. In the article’s model, those conditions no longer hold. Scope now changes through project shifts, regional moves, contractor turnover, and app proliferation, so a role defined at join time quickly becomes a poor proxy for current need. Once that happens, the role ceases to be a governance control and becomes a persistence mechanism for stale access.
Practical implication: treat role definitions as living governance objects that must be revised as business scope changes, not left to age in place.
How context-aware and just-in-time access change the control model
Context-aware access uses real-time signals such as role, location, project, risk level, usage, and activity history to decide whether access should be granted. Just-in-time access narrows entitlement duration by issuing time-bound access only when a task requires it. Together, these patterns shift the decision point from static assignment to current need. That matters because least privilege is easier to enforce when access is issued for a task window rather than inherited permanently through a broad role.
Practical implication: move sensitive access from standing entitlements to task-scoped issuance, especially where business context changes frequently.
Why access reviews fail when entitlement lists stop reflecting reality
Access reviews depend on reviewers being able to recognise what access is still justified. When users accumulate redundant, overlapping, or obsolete access, the review becomes a list-cleaning exercise rather than a governance decision. The article points to a deeper problem: review quality collapses when the identity record no longer reflects what the person or contractor actually does. At that point, certification becomes rubber-stamping, not control validation.
Practical implication: reduce entitlement drift before recertification cycles, or reviews will keep validating stale access instead of current business need.
Threat narrative
Attacker objective: The attacker objective is to exploit persistent over-provisioned access that remains available long after business need has changed.
- Entry begins with role assignment based on title or organisational position rather than current task context, so access is granted broadly at onboarding or during a move event.
- Credential or entitlement accumulation follows because access rarely falls away when responsibilities change, allowing over-provisioned permissions to persist.
- Escalation occurs through redundant roles and stale permissions that widen the effective attack surface and make approval quality weaker over time.
- Impact is a larger insider-threat and security exposure profile, with access reviews losing their ability to distinguish justified access from legacy entitlements.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static RBAC is a lifecycle control pretending to be a current-state control. The article shows that the failure is not role-based access itself, but treating a once-correct role as permanently valid. When projects, contractors, and app usage change faster than policy maintenance, RBAC stops describing need and starts preserving historical access. Practitioners should read this as a governance drift problem, not a simple policy refresh issue.
Context-aware access is the real replacement for title-based entitlement assumptions. A role says who someone was when access was granted; context says what they are doing now. That distinction matters across workforce IAM and NHI governance because current work, activity history, and risk signals are more reliable than static organisational labels. The practical conclusion is that access decisions need current-state input, not just birthright logic.
Just-in-time access shifts least privilege from policy intent to enforcement reality. Standing access remains the main reason privileges outlive their purpose. Time-bounded access narrows that window and makes high-risk access easier to justify, review, and audit. For identity programmes, the lesson is that least privilege only becomes meaningful when entitlement duration is part of the control design.
Access review quality is now a signal of entitlement hygiene, not just process maturity. When reviewers are staring at redundant roles and stale permissions, the certification exercise cannot reliably prove anything about current need. That is why over-reliance on manual recertification creates false confidence. Practitioners should treat review outcomes as evidence of upstream design quality, not as a compensating control for poor access models.
Static RBAC is becoming an identity blast-radius problem. The more roles accumulate, the more likely a single entitlement mistake spreads across changing projects, apps, and teams. That makes access governance less about clean role taxonomy and more about limiting how far one stale permission can travel. The programme implication is to design for containment, not permanence.
What this signals
Identity governance has moved from assigning access to continuously proving it. That shift matters because static roles do not fail all at once, they decay quietly as projects, regions, and contractors change. Programmes that still rely on role titles as the primary access signal will keep carrying hidden entitlement debt.
Just-in-time access is now a control for reducing persistence, not just improving convenience. When access is issued only for the task window, there is less stale privilege to review later and less standing exposure for an attacker or insider to inherit. For security leaders, that makes access duration a first-class governance variable.
For practitioners
- Re-baseline role design against current business scope Map existing roles to the work, apps, and access patterns they still represent. Retire roles that exist only because of historical organisational structure or old project boundaries.
- Convert sensitive standing access to time-bound issuance Use just-in-time access for privileged or high-impact applications where persistent permissions create the greatest residual risk. Keep duration short and task-scoped.
- Use access signals before every recertification cycle Feed usage history, project assignment, location, and risk context into access review decisions so reviewers see current need rather than an outdated entitlement list.
- Remove redundant entitlements before they reach review Detect overlapping roles and unused permissions early, then collapse or revoke them before they become normalised in certification workflows.
Key takeaways
- Static RBAC becomes unreliable when access changes faster than role maintenance, which leaves organisations with stale permissions and inflated entitlement sets.
- The article’s core evidence is operational rather than numerical: roles, projects, contractors, and apps are all changing quickly enough to make manual access governance lag behind reality.
- Dynamic controls such as context-aware access and just-in-time issuance matter because they shorten exposure windows and make access reviews more meaningful.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on access that persists after need changes, creating over-privileged non-human and human entitlements. |
| NHI-01 — Improper Offboarding | Contractor offboarding and access removal are explicit failure points in the article's governance model. | |
| Recommendation — Reduce standing entitlements and re-evaluate access whenever scope changes. Tie deprovisioning to role and scope changes so access is removed when need ends. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The post argues for access right-sizing and task-bound permissions instead of broad standing access. |
| Recommendation — Apply least privilege to limit standing access and narrow permissions to current need. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article focuses on lifecycle-driven provisioning, deprovisioning, and redundant entitlement cleanup. |
| Recommendation — Manage accounts and entitlements continuously so old access does not survive role changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Dynamic authorisation and rightsizing are the core control theme of the article. |
| Recommendation — Review entitlements against current context and remove access that no longer matches need. | ||
Key terms
- Flat RBAC: Flat RBAC is a role model where permissions are attached mainly at the tenant or organization level, with little or no resource-specific scoping. It works for simple access patterns but becomes brittle when customers need different permissions on different objects within the same tenant.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Context-Aware Access Review: A decision process that evaluates access requests using request intent, existing entitlements, resource sensitivity, and operational evidence. In identity programmes, it reduces blind approvals by forcing reviewers or automation to weigh the real circumstances behind the request, not just the ticket itself.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 1, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org