Identity and Access Management in Cloud: Moving Beyond Basic RBAC

Modern IAM requires moving beyond basic role-based access control. Role-based access control (RBAC) is where nearly every cloud identity programme starts, and it is genuinely useful — but organisations that stop there tend to accumulate roles faster than they can retire them, end up with standing access that's rarely used but never revoked, and lose the ability to answer a simple audit question: "why does this identity have this permission, right now?"

Key Takeaways

• RBAC answers "what is this identity's job," not "should this specific request be allowed right now." That's the gap ABAC and Zero Trust are designed to close.
• Standing privileged access is a bigger risk than most role reviews catch. Just-in-time access — where roles are "eligible" but must be explicitly activated, time-bound, and often approved — shrinks the window an attacker (or a mistake) can exploit.
• Zero Trust is an architecture, not a product you buy. NIST SP 800-207 defines it as removing implicit trust based on network location or asset ownership, requiring authentication and authorization before every session to a resource, not a specific vendor's checkbox feature (NIST SP 800-207).
• ABAC decisions use attributes NIST formally defines as belonging to the subject, object, and environment — for example, department, data sensitivity, and time of day — evaluated against policy at request time (NIST SP 800-162).
• Native JIT tooling isn't equally mature across clouds. Azure (Entra Privileged Identity Management) and Google Cloud (Privileged Access Manager) both ship native, first-party JIT services; AWS's IAM Identity Center documentation describes temporary elevated access as implemented through validated partner solutions rather than one built-in AWS tool (AWS documentation).
• Role sprawl is an organisational failure mode, not just a technical one. It usually stems from granting new roles to solve immediate problems without ever retiring the old ones, and no clear owner accountable for pruning them.

RBAC, ABAC, and Zero Trust: What Each One Actually Does

Role-Based Access Control (RBAC)

RBAC assigns permissions to roles, and roles to identities. Its strength is simplicity and auditability at small scale: a "Billing Admin" role has a fixed, reviewable set of permissions, and adding a new billing admin is a one-line change. Its weakness shows up at scale: as an organisation adds edge cases ("billing admins in the EU shouldn't see US customer PII," "contractors need billing access but only during business hours"), teams tend to create more granular roles rather than encode the actual condition, and the role catalogue grows faster than anyone prunes it.

Attribute-Based Access Control (ABAC)

ABAC evaluates access decisions against attributes of the subject (user, service), the object (resource being accessed), and the environment (time, location, network, device posture), rather than a fixed role assignment. NIST's guide to ABAC (SP 800-162) formalizes this model as an alternative to enumerating access through static roles, allowing policy to express conditions directly — "EU-based finance staff can read invoices tagged EU during business hours" — instead of creating a new role for every combination of conditions (NIST SP 800-162).

The practical trade-off: ABAC policies are more expressive and reduce role sprawl, but they are harder to audit at a glance than a fixed role list, and they require a policy engine capable of evaluating attributes at request time rather than a simple role-to-permission lookup.

Just-in-Time (JIT) Privileged Access

Standing privileged access — an admin role that's simply always active — is one of the highest-value targets for both attackers and accidental misuse. JIT access replaces this with time-bound activation: an identity is made eligible for a privileged role but must explicitly activate it, typically with justification, sometimes with an approval workflow, and always for a limited duration before it auto-expires.

Microsoft's Entra ID Privileged Identity Management (PIM) is a concrete implementation of this pattern: eligible role assignments require activation, activation can be configured to require MFA and a business justification, and access is granted only up to an administrator-configured maximum duration before it must be reactivated, with every activation and approval logged for audit (Microsoft Learn). Google Cloud's equivalent, Privileged Access Manager (PAM), works similarly: administrators define entitlements specifying who can request access, which roles are granted, and the maximum grant duration, and when a request is approved, PAM temporarily adds time-bound IAM role bindings that it automatically revokes when the grant expires (Google Cloud documentation).

AWS's position is worth stating precisely rather than assuming parity: AWS IAM Identity Center's own documentation describes "temporary elevated access" as a request-approve-track pattern that "supplements other forms of access control," but implements it through validated AWS Security Competency partner solutions — named examples include CyberArk, Okta, and Apono — rather than a single built-in AWS service equivalent to PIM or PAM (AWS documentation). For organisations running mixed-cloud environments, that's a genuine architectural difference worth planning around, not a detail to gloss over.

Zero Trust Architecture

Zero Trust, as formally defined in NIST Special Publication 800-207 (published August 2020), is built on the principle that "no implicit trust [is] granted to assets or user accounts based solely on their physical or network location...or based on asset ownership" (NIST SP 800-207). In practice this means authentication and authorization are performed as discrete functions before every session to an enterprise resource is established — not once at the network perimeter (e.g., a VPN login) and then implicitly trusted for everything that follows.

This is a direct response to the reality that most enterprise access today originates from remote work, personal devices, and cloud services outside any traditional network boundary, and it treats "the request came from inside the corporate network" as no longer a meaningful trust signal on its own.

How These Layers Fit Together

None of these are mutually exclusive — a mature cloud IAM programme typically runs RBAC as the baseline structure, layers ABAC policies for the conditions that would otherwise require dozens of near-duplicate roles, applies JIT activation specifically to privileged/admin roles rather than all access, and adopts Zero Trust principles for how every request is authenticated regardless of source network.

Common Mistakes

• Treating role sprawl as inevitable rather than a maintenance failure. New roles get created to solve immediate access problems; old roles rarely get retired because nobody owns the pruning process. The result is a role catalogue nobody can fully explain.
• Granting standing admin access "because requesting it every time is annoying." This trades a small amount of daily friction for a permanently larger attack surface — exactly the trade-off JIT access is designed to avoid.
• Calling a VPN or network segmentation project "Zero Trust." NIST 800-207's core point is that trust should not be based on network location at all; a project that just adds another network perimeter has not implemented the model it's named after.
• Assuming AWS has a native PIM/PAM equivalent because Azure and Google Cloud do. AWS's own documentation is explicit that temporary elevated access in IAM Identity Center depends on a validated partner solution — planning a like-for-like migration without accounting for that adds an unplanned procurement and integration step.
• Adopting ABAC without governance over the attributes themselves. If "department" or "data sensitivity" tags on resources are inconsistent or unmaintained, ABAC policies built on top of them will make incorrect decisions silently — the policy logic isn't the weak point, the underlying attribute data is.
• No regular access review cadence. Even with JIT and ABAC in place, eligible role assignments and attribute-based policies still need periodic review; access models are not "set and forget."

Trade-offs and Decision Guidance

The cost of ABAC and Zero Trust is real: they require a policy engine, consistent resource attribute tagging, and often more architectural change than a role reassignment. The cost of not adopting them, for organisations that have outgrown RBAC, is usually invisible until an audit, an incident, or a breach investigation forces the question of why an identity had access it never should have needed.

Cost, Complexity, and Timeline

Adding ABAC policies on top of existing RBAC is moderate complexity — most cloud IAM platforms support attribute- or condition-based policies natively, but the real effort is in accurately tagging resources and identities with the attributes policies will depend on, which is often a larger and more political undertaking than the technical policy configuration itself. Implementing JIT privileged access is moderate effort for a defined set of privileged roles on Azure or Google Cloud, where the tooling is native; on AWS it additionally requires selecting and integrating a partner solution, which adds procurement time to the technical work. A genuine Zero Trust architecture migration, in the NIST 800-207 sense, is a significant, multi-year undertaking for most enterprises — it touches identity, network segmentation, device posture management, and application-level authorization simultaneously, and should be approached as an incremental architectural programme rather than a single project.

Security and Governance Considerations

Every layer above depends on good logging: role assignments, JIT activations and approvals, and ABAC policy evaluations should all be logged with enough detail to answer "who had access to what, when, and why" after the fact — both Microsoft Entra PIM and Google Cloud PAM log every activation and grant for this reason. Ownership matters as much as tooling — someone needs to be explicitly accountable for reviewing and retiring roles, approving privileged activation requests, and keeping resource attribute tags accurate; without an owner, even well-designed IAM systems decay back into role sprawl and stale standing access over time.

How Halden Solutions Approaches This

We treat IAM maturity as incremental, not a single migration: most clients don't need to rip out RBAC, they need to identify where it's straining — usually privileged access and a handful of high-friction contextual exceptions — and address those specifically with JIT activation and targeted ABAC policies before considering a broader Zero Trust programme. For Azure-standardised clients, that typically starts with Entra PIM; for mixed-cloud environments, we scope the AWS gap (partner tooling, not a native service) into the plan explicitly rather than discovering it mid-project. Where a client is pursuing a genuine Zero Trust architecture, we scope it against NIST SP 800-207's actual definition rather than a vendor's marketing use of the term, and prioritise the identity and access layers that give the clearest risk reduction first.

Frequently Asked Questions

Do we need to replace RBAC to adopt Zero Trust? No. RBAC can remain the baseline structure for common access patterns; Zero Trust is about how every request is authenticated and authorized regardless of network origin, and can be layered on top of an existing role model rather than replacing it.

What's the difference between ABAC and RBAC in practice? RBAC grants permissions based on a fixed role assignment. ABAC evaluates permissions dynamically against attributes of the user, resource, and context at request time, which reduces the need to create a new role for every contextual exception, at the cost of needing well-maintained attribute data and a policy engine.

Is just-in-time access only for cloud admin roles? It's most valuable for privileged/administrative roles where standing access represents the largest risk, but the same time-bound activation pattern can apply to any sensitive access that is used infrequently.

Does AWS have a native equivalent to Azure PIM or Google Cloud PAM? Not a single built-in one. AWS IAM Identity Center documents "temporary elevated access" as a pattern implemented through validated AWS Security Competency partner solutions rather than one native AWS service, which is a real planning consideration for organisations standardising a JIT process across clouds.

Is Zero Trust a product we can buy? No single product implements Zero Trust Architecture on its own. NIST SP 800-207 describes it as an architectural approach spanning identity, device, network, and application layers; vendors sell components that support pieces of it, but the architecture itself is an organisational and technical programme.

Conclusion

RBAC remains a sound foundation for cloud IAM, but organisations that rely on it exclusively tend to accumulate role sprawl and standing privileged access they can't fully account for. Layering ABAC for contextual decisions, JIT activation for privileged roles, and Zero Trust principles for how every request is verified closes those specific gaps — each addressing a different, real failure mode rather than being a fashionable replacement for the last one. Which tools implement JIT natively also genuinely differs by cloud, and is worth planning for rather than assuming.

If your organisation is weighing where to invest next in cloud identity — tighter role governance, privileged access reform, or a broader Zero Trust roadmap — Halden Solutions' Cybersecurity & Sovereign Cloud team can help assess where the actual risk sits today.

Sources

• NIST Special Publication 800-207 — "Zero Trust Architecture"
• NIST Special Publication 800-162 — "Guide to Attribute Based Access Control (ABAC) Definition and Considerations"
• Microsoft Learn — "What is Privileged Identity Management?" (Microsoft Entra ID Governance)
• Google Cloud documentation — "Privileged Access Manager overview"
• AWS documentation — "Temporary elevated access for AWS accounts" (IAM Identity Center)