Should organisations keep RBAC and activity-based access control together?

Why RBAC and activity-based access control fit better as layers than substitutes

RBAC and activity-based access control solve different parts of the same access problem. RBAC gives you stable entitlement structure, understandable ownership, and easier review. Activity-based control adds context at request time, so the decision can reflect what is happening now, not only what a user was granted last quarter.

That distinction matters because a role is usually too coarse to answer every access question safely. A person, service, or workflow may legitimately hold a role, yet still need tighter checks when the action is unusual, sensitive, high risk, or outside expected behaviour.

What each model contributes to a practical access design

RBAC is strongest when you need repeatable baseline access, clean role catalogues, and auditable ownership. It is especially useful for entitlement governance because it makes access review manageable and helps prevent ad hoc permission sprawl. For a deeper role design lens, see the Role Mining and Role Design Guide.

Activity-based access control is strongest when the decision must reflect context such as time, location, device state, request pattern, transaction value, or anomalous behaviour. That is why layered models work well in environments that need both access governance and dynamic enforcement, especially when the same identity can behave differently across systems and risk levels.

A useful way to think about the combined model is: RBAC answers “should this identity generally have a path to the resource?”, while activity-based control answers “should this specific action proceed right now?”. In practice, that lets teams keep roles stable without making them over-permissive.

How to avoid the common failure mode of using only one control layer

The main failure with RBAC alone is role inflation. Teams keep adding permissions to roles until they become broad enough to satisfy edge cases, which erodes least privilege. The main failure with activity-only control is governance drift. Without a baseline entitlement model, access becomes harder to review, harder to explain, and easier to over-grant in the name of flexibility.

A stronger operating model is to keep the baseline entitlement small and defensible, then let activity checks narrow or step up access when context demands it. That preserves auditability without pretending that static roles can encode every real-world decision.

For organisations managing machine or non-human access as well as human access, this layering is even more important because role assignment alone rarely captures lifecycle, ownership, or abuse signals well enough. The same principle is reflected in the IAM and IGA Basics guide, which places RBAC, ABAC, provisioning, and access review into one governance model.

Risk and Threat Considerations

Keeping RBAC and activity-based access control together reduces two different classes of exposure: broad standing privilege and blind trust in context-free entitlements. If organisations rely on roles only, attackers who compromise a legitimate account inherit whatever that role can do, even when the specific request should have been blocked by context.

Failure mechanism: Coarse roles grant persistent access, while the lack of request-time evaluation allows sensitive actions to execute even when the current session, device, timing, or behaviour is abnormal. That widens blast radius after credential compromise and increases the chance of privilege abuse.

Impact: The organisation gets weaker containment, weaker anomaly resistance, and weaker audit defensibility. The risk grows fastest where high-value actions, delegated access, or shared operational accounts are involved, because static permissions alone rarely capture the true decision boundary.

Practitioner Guidance

What to prioritise: Keep RBAC as the entitlement backbone, then define which actions must be evaluated dynamically before they execute. Start with the highest-risk operations, such as admin changes, data export, payment, or cross-environment access, rather than trying to make every request fully contextual on day one.

What to verify: Confirm that every role has a named owner, a documented business purpose, and a reviewable permission scope. Then verify that the activity-based layer can actually see the signal it needs, because a contextual policy that cannot inspect the session, device, or request attributes will fail open in practice.

Decision rule: If the action is low risk and well understood, RBAC may be enough for the first decision. If the action is sensitive, unusual, or high impact, require a contextual check or step-up path before allowing it.

Practitioner takeaway: Do not treat RBAC and activity-based control as competing models. Use RBAC to keep access governable, and use activity-based decisions to keep access responsive to real risk.

Authorisation Models Guide is useful when you need a broader comparison of RBAC, ABAC, ReBAC, and policy-based access control, including when to combine them rather than choose one.

Privileged Access Management Guide helps when the question is less about everyday access and more about how to bound elevated access with JIT, session controls, and zero standing privilege.

Related resources from NHI Mgmt Group

• How can organisations keep directory-based access under control?
• How should security teams use activity-based access control without replacing RBAC entirely?
• What do organisations get wrong when they move from RBAC to policy-based access control?
• When should organisations prefer policy-based access control over RBAC or ABAC?