Mitigating PAM Risks in Azure for UAE Finance

Where privileged access actually lives in Azure

"Privileged access" in Azure is not one thing. It is split across two systems that look related and are not.

Entra ID roles versus Azure RBAC roles

Entra ID (formerly Azure AD) roles govern the identity plane: Global Administrator, Privileged Role Administrator, Security Administrator, User Administrator. These control who can create accounts, reset passwords, register applications and manage conditional access itself. Azure RBAC roles govern the resource plane: Owner, Contributor, User Access Administrator, applied at management group, subscription, resource group or single-resource scope. A Global Administrator does not automatically get Owner on every subscription, and a subscription Owner does not automatically get Entra ID admin rights. Treating them as one ladder is the first mistake: teams over-grant one system to compensate for gaps in the other.

An inventory of "who has privileged access" that only lists Entra ID roles, or only lists RBAC Owner assignments, is incomplete. Both need auditing together, using Azure Resource Graph plus the Entra ID and Azure Monitor activity logs, not the portal role-assignment blade viewed one scope at a time.

The standing-access problem

The risk in PAM is rarely a stolen password. It is a valid, standing assignment that sits active for months after the person who needed it changed teams or left the organisation. A permanent Owner or Global Administrator assignment is a permanent blast radius: every phished session and every compromised device belonging to that identity now carries full privileges, all the time.

Making Privileged Identity Management work in practice

Microsoft Entra Privileged Identity Management (PIM) addresses this by separating "eligible" from "active." An eligible assignment grants no standing rights; the user must activate the role, which can require justification, an approver, MFA at activation, and a maximum activation window measured in hours rather than days. Done properly, this converts every privileged action into a discrete, logged, time-bound event rather than a permanent state.

Where PIM implementations actually fail is not the tooling, it is the configuration around it:

• Approval routed to the same person requesting activation, which defeats the control.
• Activation windows set to the maximum allowed and never revisited, effectively recreating standing access.
• Access reviews configured but never actioned, so stale eligible assignments accumulate for years.
• PIM applied to Entra ID roles but never extended to Azure RBAC roles at the subscription level, leaving the resource plane on permanent assignments.

Access reviews need an owner who removes access on a "no response" outcome, not one who defaults to keeping it. That single setting decides whether the control does anything.

Identity verification before activation, not after

MFA at sign-in is not the control that matters most for privileged accounts; MFA at role activation is. Conditional access policies scoped to privileged roles should require phishing-resistant authentication, FIDO2 security keys or certificate-based authentication rather than SMS or push notifications that push-bombing attacks routinely defeat. Pair this with device compliance requirements (managed, compliant device only) and, where the risk profile justifies it, named-location restrictions that block privileged activation from outside approved networks.

The gap most audits find is inconsistency: MFA enforced for the interactive portal sign-in but not re-checked when a role is raised mid-session, or enforced for human accounts but skipped entirely for service principals and workload identities that hold equivalent rights.

Separating admin identity from daily identity

A single identity used for email, Teams and privileged administration multiplies risk: every phishing email in that inbox is now one click from a privileged session. The standard pattern is a separate administrative identity, used only from a locked-down access point, never for browsing or mail. Every tenant also needs break-glass accounts excluded from conditional access and normal PIM activation, credentials stored offline and monitored for any sign-in, because a sign-in on a break-glass account outside a declared emergency is itself an incident.

Monitoring that actually catches misuse

Logging is not detection. Entra ID sign-in, audit and PIM activation logs need to land somewhere that alerts on what matters: activation outside business hours, activation followed immediately by a change on a sensitive resource group, activation from a new device or country, or a spike in failed attempts. Piping these into Microsoft Sentinel with correlation rules, rather than raw retention, is what turns the trail into something a SOC can act on in minutes rather than discover weeks later during a review.

Defender for Cloud's identity recommendations are a reasonable hygiene baseline, but they flag configuration gaps, not active misuse. Both layers are needed: posture management to catch drift, and detection content on the logs to catch abuse of access that is technically compliant.

Where UAE bank and insurer deployments actually fail

Across regional deployments, the recurring gaps are less about missing tools and more about how the tools get configured:

• No tiering model separating identities that manage the tenant from identities that manage a single workload, so a compromise of one flows into the other.
• Third-party and vendor accounts with standing Contributor or Owner access, added for a project and never revoked once it closed.
• PIM enabled tenant-wide on day one with no pilot group, which then gets rolled back under operational pressure and never re-enabled properly.
• Access reviews that exist on paper for an audit but were never actually completed by the assigned reviewer.

None of this is exotic. It is the difference between a control that exists in a licence and a control an assessor can watch operate end to end: an activation request, an approval, a time-bound session, and a log entry closing it out. A UAE financial institution should expect assessors to ask for exactly this walkthrough during a technology risk review, not a slide describing the architecture.

Native PIM or a dedicated PAM platform

Entra PIM, used properly, covers most cloud-native Azure estates on its own: role eligibility, activation approval, time-bound sessions and access reviews are included in Entra ID P2 licensing. Organisations still need a dedicated PAM platform for hybrid estates: on-premises Active Directory, network devices, database service accounts and legacy applications that PIM was never built to cover, where session recording or credential rotation for shared local accounts is a requirement rather than a nice-to-have. Tools such as ARCON PAM and BeyondTrust fill that gap: vaulting for non-Entra-joined systems, session recording on legacy infrastructure, and one audit surface spanning cloud and on-premises. For most hybrid UAE finance environments the answer is PIM for the Azure control plane plus a PAM platform for everything Entra cannot reach, feeding the same Sentinel workspace so the SOC is not watching two consoles.

Before your next audit

Three checks catch most of the gaps described above before an assessor finds them:

1. Pull every Entra ID role assignment and every Azure RBAC Owner or Contributor assignment across subscriptions, and confirm each maps to a business justification still valid today.
2. Confirm PIM approval for a high-privilege role is not routed to the requester, and that the last access review actually removed a stale assignment.
3. Trigger a test activation and trace it through to a Sentinel alert end to end, rather than assuming the log exists because the connector is configured.

If any of the three fails, that is the gap to close first, before adding another control on top of a foundation that is not being monitored.