Why activity-based access control matters beyond static roles

At a glance

What this is: This explainer argues that role-based access control is too static for modern identity risk and that activity-based access control uses behaviour and context to make access decisions in real time.

Why it matters: IAM teams need to understand where static roles stop being reliable so they can align access enforcement with actual behaviour across human, NHI, and increasingly dynamic operating models.

👉 Read Unosecur's analysis of activity-based access control and static roles

Context

Role-based access control works well when job duties are stable, but it weakens when access patterns change faster than role definitions. In cloud-first and remote environments, the governance gap is that a valid role can still be the wrong decision for a specific request.

Activity-based access control is best understood as context-aware enforcement: access is evaluated against behaviour, timing, location, and risk signals rather than a job title alone. That matters for identity security because over-permissioned accounts and reused credentials can look legitimate until the activity itself is examined.

Key questions

Q: What breaks when teams manage cloud identities with static roles instead of ephemeral access?

A: Static roles break down when access patterns are temporary, variable, or tied to automated operations. Teams end up overprovisioning access, leaving privileges in place after use, and creating audit gaps when permissions are not revised quickly enough. That model also increases administrative overhead, because each cloud platform and service often requires separate manual adjustments that do not scale well.

Q: Why does adding context to access decisions reduce identity governance risk?

A: Context reduces risk because access decisions are often made with incomplete visibility into roles, resources, and request intent. When reviewers see risk signals and relevant identity data, they can spot excessive access, reject weak requests, and approve legitimate ones faster. That lowers sprawl, reduces manual ticket wrangling, and improves the quality of governance decisions.

Q: How can teams tell whether context-based access control is actually working?

A: Look for consistent denial of access from unmanaged devices, off-policy locations, and unsupported session times, while approved sessions continue to work without manual exception handling. If risky requests still succeed or every exception needs manual review, the control is not operating as a real decision layer.

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 roles fail in dynamic access environments

RBAC assigns permissions to a named role and assumes that role is a stable proxy for intent. That model is easy to audit, but it cannot see whether a specific request matches current behaviour, context, or risk. In cloud, remote, and third-party access scenarios, the same identity may perform different tasks across different conditions, so the role alone becomes an incomplete authorisation signal. The technical gap is not visibility into who has access, but the inability to decide whether a given action should be allowed right now.

Practical implication: review where your current authorisation model still treats role membership as sufficient evidence for access.

How activity-based access control evaluates behaviour in real time

Activity-based access control uses signals such as request timing, location, device context, and behavioural deviation to decide whether access is appropriate. Instead of granting rights once and trusting them indefinitely, the control continuously compares the request to expected patterns. That makes it a risk-adaptive layer rather than a replacement for identity proofing or authentication. The control is most useful when the organisation wants to condition access on what is happening at the moment of request, especially where stolen credentials or unusual insider activity could otherwise blend into normal login success.

Practical implication: feed behavioural and contextual signals into authorisation decisions instead of treating them only as monitoring data.

How activity-based controls strengthen JIT access and least privilege

JIT access and least privilege still depend on the quality of the decision at issuance time and during the session. Activity-based control adds a live check on whether the requested access still fits the observed behaviour, so temporary privilege can be constrained by context rather than by ticket status alone. That matters because many programmes grant access correctly at the start and then lose control once the session is active. The technical value is continuous relevance: access remains bounded by current risk, not only by the initial approval event.

Practical implication: pair temporary access with behavioural checks so elevated rights can be reduced when usage diverges from expectation.

Breaches seen in the wild

• Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static roles are a governance convenience, not a reliable authorisation model for dynamic environments. RBAC assumes the role accurately represents intent at the moment access is used, but cloud operations, remote work, and third-party access break that assumption. The result is a control model that can remain administratively tidy while still authorising the wrong action. Practitioners should treat role design as a baseline and not as proof that access decisions remain valid over time.

Activity-based access control closes the gap between entitlement and behaviour. The important shift is not from roles to no roles, but from static assignment to context-aware decisioning. Behaviour, timing, and location become part of the authorisation signal, which is especially relevant when stolen credentials or unusual insider activity can otherwise look legitimate. That makes identity governance more responsive to actual use rather than policy paper.

Real-time enforcement is now part of identity governance, not an optional enhancement. If access can change meaning from one request to the next, then governance has to move closer to the moment of use. This is where activity-based control aligns with JIT, least privilege, and identity threat detection: it turns access review from a periodic exercise into a live control surface. Practitioners should re-evaluate any programme that still treats role membership as the main authorisation fact.

Behaviour-aware authorisation introduces a more precise governance vocabulary for modern identity programmes. The useful concept here is an activity-context gap: the distance between what a role says and what the request is actually doing. That gap is where misuse, overreach, and false trust accumulate. The practitioner conclusion is simple: if your access model cannot distinguish normal use from risky use, it is describing structure, not governing behaviour.

Activity-context gap: This is the mismatch between a user's assigned role and the actual conditions of a request. It matters because modern access risk is often created by valid identities acting in abnormal ways, and static role assignment gives security teams too little signal to judge that difference. The implication is that access governance must account for live context, not just entitlement records.

What this signals

Activity-context gap: access governance is strongest when the system can compare assigned rights with live request conditions. That is the difference between administering entitlements and governing use, and it is where many modern identity programmes still have to mature.

For practitioners, the implication is that authorisation logic needs to move closer to runtime. When behaviour changes faster than role definitions, the programme has to treat context as part of the decision, not as a separate monitoring layer.

For practitioners

• Review where RBAC is doing authorisation work it should not be doing Map high-risk entitlements, remote access paths, and third-party access flows to see where role membership is the only approval signal. Prioritise environments where the same identity performs different tasks under changing conditions.
• Add contextual signals to access decisions Use request timing, location, device context, and behavioural deviation to inform whether an action should be allowed. Keep the signal set narrow and operational, so it changes decisions instead of just improving telemetry.
• Tighten JIT access with behavioural validation Treat just-in-time privilege as conditional on current behaviour, not only on the original request or ticket. Revoke or reduce access when activity no longer matches the approved purpose.
• Use access reviews to redesign roles Look for repeated exceptions, routine role overreach, and permissions that are only justified by administrative convenience. Use that evidence to break apart oversized roles and right-size entitlements around actual activity.

Key takeaways

• Static roles remain useful for structure, but they are too blunt to govern access safely in environments where context changes quickly.
• Activity-based access control adds the behavioural signal that helps separate legitimate access from risky use, including stolen credential abuse and unusual insider activity.
• The practical shift for IAM teams is to pair roles with live contextual checks so access decisions reflect what is happening, not just what is written down.

Key terms

• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.
• 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.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Examples of how activity-based rules are applied to specific access requests and risk signals
• Practical guidance on combining JIT access with behavioural enforcement in day-to-day operations
• FAQ-level discussion of role deconstruction, skill-centric access, and compliance during transition
• Specific examples of how automated governance can support audit trails and access-rights cleanup

👉 Unosecur's full blog explains how activity-based access control fits alongside JIT, least privilege, and identity threat detection.

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.