Mitigating Azure PAM Risks in GCC

What "Azure PAM" actually means

Microsoft has shipped two products under variations of this name and the overlap causes real confusion in scoping conversations. Microsoft Identity Manager PAM is an on-prem bastion forest model, largely legacy now. What almost every GCC bank means when it says "Azure PAM" today is Entra ID Privileged Identity Management, usually just called PIM. It is a licensing feature under Entra ID P2 (bundled in Microsoft 365 E5 and equivalent bundles), not a separate product you deploy.

PIM does one job well: it turns a standing role assignment into an eligible one. An eligible assignment grants nothing by itself. The user has to activate it, which can require multi factor authentication, a written justification, a time limit, and approval from a designated approver. When the window closes, the role drops away on its own. That is the entire mechanism, and it is worth being precise about it because a lot of the failures in the field come from people assuming PIM does more than this.

How PIM activation actually works

Entra ID roles versus Azure resource roles

PIM covers two separate scopes and they are configured independently, which is the first thing that trips teams up. Entra ID role PIM governs directory roles: Global Administrator, Privileged Role Administrator, Exchange Administrator, and so on. Azure resource PIM governs RBAC roles on subscriptions, resource groups, and individual resources: Owner, Contributor, User Access Administrator. A bank can have pristine PIM coverage on its Entra ID roles and zero coverage on the Azure subscription holding its core banking workloads, because someone configured one and never got to the other.

Eligible assignments, activation, and expiry

An eligible assignment defines who can activate a role and under what conditions: maximum activation duration, whether MFA is re-required at activation even if the user already has an active session, whether justification text is mandatory, and whether an approver has to sign off before the role goes live. Shorter windows are safer but push more activation requests through the approval queue, so the practical decision is usually a tiered one: short windows (an hour or two) for day-to-day administrative roles, longer windows for scheduled maintenance work with a named approver and a change ticket attached.

PIM for Groups

PIM can also govern membership in and ownership of a group, which is the cleaner pattern when a role needs to be granted to several people or bundled with access to a third-party application through group-based assignment. It avoids having ten separate eligible role assignments that all drift out of sync when one person leaves the team.

Where GCC deployments actually break

Standing assignments left outside PIM

The most common finding in a review is not a PIM misconfiguration. It is a role assignment that was never brought into PIM at all: a service desk lead who was made a permanent Global Administrator two years ago and stayed there because nobody re-scoped it when PIM was rolled out. PIM only protects what has been onboarded to it. An access review across all role assignable groups and directory roles, not just the ones already in PIM, is the only way to find these.

The hybrid identity gap

Most GCC banks still run on-prem Active Directory alongside Entra ID, connected by Entra Connect (formerly Azure AD Connect) sync. PIM protects the cloud side. It has no visibility into on-prem Domain Admins, and a compromised on-prem privileged account can be used to tamper with directory synchronisation, or pivot to cloud resources through any account that has both an on-prem and cloud presence. Treating PIM as the privileged access answer while leaving on-prem tiering (separating Tier 0 domain controllers and identity infrastructure from everyday admin workstations) unaddressed is one of the more consequential gaps assessors run into, because it is invisible from the Entra ID admin centre.

No session recording, no credential vaulting

This is the gap that causes the most friction with compliance teams who assume "PAM" means what it means in a traditional on-prem product. PIM logs that a role was activated, by whom, when, for how long, and against what justification, but that activation log is not a session recording: it does not capture what the administrator typed or clicked once the role was live, and it does not manage or rotate shared local admin or service account passwords. A complete Azure PAM implementation has to pair that activation logging with a separate session recording and password vaulting capability to actually ensure privileged sessions are recorded and audited, which is what NESA and CBUAE reviewers expect to see on request. That pairing, plus brokering access to non-Azure targets such as network devices, on-prem servers, or third-party SaaS admin consoles, is a dedicated PAM platform's job.

Logs nobody looks at

PIM activation and approval events land in the Entra ID audit log and, from there, can be forwarded to Microsoft Sentinel or a third-party SIEM through diagnostic settings. In practice a fair number of deployments never wire that forwarding up, so the data exists but nobody is alerting on repeated failed activation attempts, activations without an approval trail, or a role staying active for the full permitted window every single time it is used, which is usually a sign the window is set too generously rather than that the role is genuinely needed that long.

What assessors ask for

A reviewer looking at privileged access for a UAE or GCC financial institution typically wants to see, in order: a current inventory of who holds which privileged role and whether the assignment is eligible or standing; evidence that activation requires justification and, for the higher-impact roles, approval; a sample of actual activation and approval records, not just the policy that describes them; a record of periodic access reviews with removed or expired assignments visible; and confirmation that break-glass emergency access accounts exist, are excluded from Conditional Access and MFA enforcement by design, and are monitored more closely than any other account precisely because of that exclusion. None of this requires quoting a specific regulator by name to get right. Assessors under NESA, CBUAE, or ISO 27001 all converge on the same underlying question: can you show, with records rather than a diagram, who could become an administrator, when they did, and who signed off.

A configuration baseline that holds up

Put every directory role above Helpdesk Administrator into PIM as eligible-only, with standing assignment reserved for the two or three break-glass accounts that are explicitly excluded and separately monitored. Set activation windows by risk: an hour or two for routine administrative roles, longer only for pre-approved maintenance with a linked change record. Require approval for Global Administrator, Privileged Role Administrator, and any role that can modify Conditional Access or MFA policy, since those roles can be used to remove the controls that would otherwise catch misuse. Forward PIM audit logs to the SIEM the security team actually watches, and build one alert for activation without a corresponding approval and one for a role held active for its full window on a recurring basis. Run access reviews quarterly at minimum, and treat "reviewer approved with no changes, every quarter, for a year" as its own finding worth investigating, since it usually means the review is being rubber-stamped rather than performed.

Where PIM stops and a dedicated PAM platform starts

If the requirement is limited to controlling who can become an administrator in Entra ID or on an Azure subscription, for how long, and with what approval, PIM covers it, and because it rides on the Entra ID P2 licence rather than a separate product, turning it on is usually a licensing conversation, not a new procurement. If the requirement extends to vaulting and rotating shared local admin or service account credentials, recording privileged sessions on servers and network devices, or brokering access into on-prem and legacy systems that never touch Entra ID, that is the job of a dedicated privileged access management platform, and PIM is not a substitute for one no matter how it is licensed. Most mature GCC deployments run both: PIM for cloud role governance layered on top of Entra ID as the identity plane, and a vaulting and session-recording product such as BeyondTrust or Arcon for the on-prem and cross-platform privileged accounts that PIM was never built to reach. Deciding which one solves which problem before a procurement conversation starts saves months of the two teams talking past each other.