Why activity-based access control matters beyond static roles

At a glance

What this is: This explainer contrasts RBAC with activity-based access control and argues that static roles are too rigid for modern identity risk.

Why it matters: It matters because IAM, NHI, and human access programmes all need controls that react to behaviour, not just provisioning records, when credentials are abused or contexts change.

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.

👉 Read Unosecur's explanation of activity-based access control and RBAC limits

Context

Role-based access control is a provisioning model, not a live risk model. It assigns access from a predefined job or function, which works when duties stay stable, but it becomes brittle when users move between tasks, locations, devices, and risk conditions faster than the role catalogue can keep up.

That is why behaviour-aware access decisions matter for identity security across human users and machine identities. The same programme pressure shows up in NHI governance when access is granted once and then left to age, and in human IAM when a valid login is used from an abnormal context.

The vendor's framing is strongest where it shows the gap between paper entitlements and actual activity. For practitioners, the question is not whether roles are useful, but where static roles stop being sufficient for enforcement, review, and response.

Key questions

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. RBAC should answer who can generally access a system, while behavioural checks decide whether a specific action is safe right now. That layered approach reduces misuse risk without making administration unmanageable.

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. The same role may be used from different devices, locations, vendors, or workloads. When access is valid on paper but abnormal in practice, role-only controls miss the misuse until after damage starts.

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. That creates a false sense of governance because the review captures structure, not operational reality.

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.

Technical breakdown

Why static RBAC breaks under real-time identity risk

RBAC binds permissions to a role, then assumes the role is a stable proxy for intent. That assumption is efficient for audit and administration, but it cannot see whether access is being used in a benign or hostile way. In cloud-first estates, the same role can be exercised from a corporate laptop, a contractor device, a compromised token, or an unusual geolocation. RBAC answers who should have access on paper, not whether the current session still deserves it. That is where identity threat detection and response, contextual signals, and continuous authorisation become relevant.

Practical implication: Treat RBAC as the baseline entitlement model, not the final enforcement layer, and add context-aware controls where misuse risk is high.

How activity-based access control changes the decision point

Activity-based access control evaluates behaviour, timing, location, and usage pattern at the moment of access. Instead of asking only whether a role exists, it asks whether the request fits the user's normal pattern and current risk posture. That makes it closer to risk-adaptive access than traditional permissioning. In practice, it can step up authentication, throttle sensitive actions, or block anomalous downloads without removing the underlying role. The value is not in replacing identity data, but in turning identity signals into a decision engine that can react faster than manual review.

Practical implication: Use activity signals to gate the highest-risk actions, especially where valid credentials are the most likely attack path.

How activity-driven controls support JIT access and least privilege

Just-in-time access and least privilege both depend on scope and duration being limited to what is needed now. Activity-based controls make those limits enforceable during the session, not only at provisioning time. If a user or workload begins to behave outside expected bounds, the system can reduce permissions, alert, or challenge the session before misuse expands. That matters in NHI estates too, because over-privileged service accounts and long-lived secrets create a broad opportunity window. The deeper point is that privilege should be treated as a live condition, not a static grant.

Practical implication: Pair activity-based enforcement with JIT and privilege review so elevated access can shrink as soon as usage deviates.

Threat narrative

Attacker objective: Exploit valid identity state to perform harmful actions without triggering controls that rely only on role assignment.

1. entry via stolen or misused credentials that still satisfy the role model, even though the session context is abnormal.
2. escalation through legitimate access being exercised in ways the static role does not distinguish from approved use.
3. impact when attackers move laterally or exfiltrate data before a human review cycle can catch the misuse.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Activity-based access control is really a continuous authorisation problem. The important shift is not semantic, it is operational: decisions move from provisioning time to session time. That makes the control plane more responsive to stolen credentials, insider misuse, and abnormal device or location patterns. For identity teams, this aligns with ZT-NIST-207 and NIST-CSF expectations around ongoing verification, not one-time approval.

Identity threat detection and response becomes more effective when it can interpret behaviour in context. A valid login is no longer a trustworthy endpoint if the activity diverges sharply from the user's norm. That is true for human users and for machine identities that reuse the same tokens across workflows. The programme implication is to connect entitlement governance with behavioural telemetry so the review model reflects actual use.

Real-time access control closes the gap between privilege on paper and privilege in use. The article's strongest point is that static models fail when work is distributed, dynamic, and token-driven. That is also where NHI governance struggles most, because a service account or API key can look fully authorised while already being abused. Practitioners should read this as a call to align lifecycle controls, session controls, and misuse detection.

Behaviour-based access is the right direction, but only if it remains tied to governance, not just automation. The danger is to treat dynamic control as a feature rather than a policy model. Without clear ownership, evidence, and review thresholds, activity signals can create false confidence. Teams should ensure the control supports certification, response, and exception handling across human and non-human identities.

From our research:

• 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.
• That lifecycle gap is why Lifecycle Processes for Managing NHIs remains the next resource to use when teams need to move from policy to revocation discipline.

What this signals

Activity-aware access is becoming a control expectation, not an optimisation. As identity estates stretch across humans, service accounts, and vendor access, teams need enforcement that can react to live context instead of waiting for quarterly reviews. The operational question is where to apply that control first: privileged admin paths, third-party access, or sensitive data actions.

Behaviour-driven policy will expose how much of your current governance is documentation-heavy and enforcement-light. If an access model cannot react when usage drifts, the programme is relying on static trust in a dynamic environment. That is a useful test for IAM and IGA leads because it reveals where review processes exist only on paper.

With 97% of NHIs carrying excessive privileges, the governance gap is not just more visibility but more responsive enforcement. In practice, that means joining entitlement inventory to session behaviour and lifecycle events so over-privilege is caught before it becomes lateral movement. The best next step is to align continuous access decisions with the Ultimate Guide to NHIs , Key Challenges and Risks.

For practitioners

• 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. Use those findings to decide where continuous authorisation or activity-based checks are needed.
• 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. Keep the base role, but make the action dependent on current session risk.
• 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. Reduce scope or trigger review when activity drifts from the authorised purpose.
• Review NHI entitlements as live usage patterns For service accounts, API keys, and automation tokens, compare granted scope with actual activity and remove unused privilege paths. Use the same discipline for machine identities that you apply to human access reviews.

Key takeaways

• RBAC remains useful for administration, but it cannot by itself judge whether access is safe in the moment it is used.
• The article's core insight is that identity security now depends on continuous, behaviour-aware enforcement across sessions, not just roles on paper.
• Practitioners should connect entitlement governance, JIT access, and behavioural telemetry so privileged activity can be challenged before misuse scales.

Key terms

• Role-Based Access Control: A permission model that grants access based on a predefined role rather than on the live context of each request. It is efficient for administration and audit, but it assumes the role remains a good proxy for intent and risk even when behaviour changes.
• Activity-Based Access Control: An access model that evaluates behaviour, timing, location, and other live signals before allowing a sensitive action. It adds a dynamic decision layer on top of identity data so access can be challenged, reduced, or blocked when usage looks abnormal.
• Continuous Authorisation: A control pattern where access is re-evaluated during the session instead of only at login or provisioning time. For human and non-human identities alike, it turns the access decision into an ongoing risk check rather than a one-time approval.
• Identity Threat Detection and Response: A monitoring and response discipline that looks for identity misuse, anomalous access, and privilege abuse, then reacts quickly. It is strongest when behavioural signals, entitlements, and response actions are linked, so detection can change what the identity is allowed to do.

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

👉 Unosecur's full post covers the role-vs-behaviour comparison, JIT integration, and FAQ examples

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.