TL;DR: Static roles no longer capture how access is actually used in cloud, remote, and insider-risk environments, and Unosecur argues that behavior-driven controls can close that gap by tying decisions to live activity rather than job titles. That shift matters because identity security now depends on context-aware enforcement, not paper-based entitlements.
NHIMG editorial — based on content published by Unosecur: Why it's time to go beyond static roles
By the numbers:
- More than 80% of hacking-related breaches involve stolen or misused credentials.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams use activity-based access control without replacing RBAC entirely?
A: Use RBAC for baseline entitlement assignment and activity-based controls for session-time enforcement.
Q: Why do static roles create risk in cloud and hybrid environments?
A: Static roles assume access intent stays stable, but cloud and hybrid environments change context constantly.
Q: What breaks when access reviews only measure entitlement lists?
A: Entitlement-only reviews miss whether access is being used safely, whether a privilege is still active in practice, and whether a workload or user has drifted into higher-risk behaviour.
Practitioner guidance
- Map where RBAC is the wrong control boundary Identify systems where role membership does not predict actual risk, especially cloud consoles, admin portals, and vendor-access paths.
- Add behaviour signals to sensitive access decisions Require device, location, timing, and anomaly context before approving high-risk actions such as exports, privilege changes, or bulk downloads.
- Tie JIT access to observed session behaviour Do not let temporary privileges continue automatically once the user or workload starts acting outside the approved pattern.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Specific examples of when activity-based access should block, challenge, or throttle a session
- The vendor's own comparison points between RBAC, ABAC, JIT, ITDR, and ISPM
- Practical examples of how the model behaves in cloud, remote-work, and insider-risk scenarios
- The article's FAQ section on role deconstruction, NIST Zero Trust, and compliance transitions
👉 Read Unosecur's explanation of activity-based access control and RBAC limits →
Activity-based access control and the governance gap teams miss?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Static role assignment is now a partial control, not an identity security strategy. RBAC still has value for administration and audit, but it cannot answer whether an access request is safe in the moment it is used. In cloud and hybrid environments, the security problem is increasingly about live behaviour, not just entitlement design. Practitioners should treat RBAC as a starting point and not as proof of safe access.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who is accountable when behaviour-based access controls block or challenge a session?
A: Accountability should sit with the identity owner, the control owner, and the system owner together. Identity governance must define who can override a challenge, who reviews exceptions, and who owns evidence when a real-time decision prevents or permits access.
👉 Read our full editorial: Why activity-based access control matters beyond static roles