- Entra ID roles, Azure RBAC, and data-plane permissions (Key Vault, Storage keys, SQL admin) are three separate privilege layers, and most PAM gaps come from treating them as one.
- Microsoft Entra ID Privileged Identity Management covers just-in-time elevation for directory and resource roles, but it needs a P2 licence and does nothing for shared accounts, service principals, or on-premises systems.
- The most commonly missed privileged asset in hybrid Azure estates is the Entra Connect sync server, not a human admin account.
- Auditors care less about which product you bought and more about whether every privileged session is time-bound, approved, and reviewed.
What "Privileged Access" Means in an Azure Tenant
Azure spreads privilege across layers that do not map to each other cleanly, and that mismatch is where most PAM programmes fall apart. Entra ID directory roles (Global Administrator, Privileged Role Administrator, Application Administrator) control the identity plane: users, groups, app registrations, conditional access policies. Azure RBAC roles (Owner, Contributor, User Access Administrator) control the resource plane, scoped to a management group, subscription, resource group, or single resource. Below that sits data-plane privilege that RBAC does not touch on its own: Key Vault access policies, storage account keys, SQL server admin logins, and VM local administrator accounts.
A team can lock down Azure RBAC tightly and still leave the tenant wide open if a storage account key or a Key Vault access policy is not in scope for review. Any PAM conversation for Azure has to name all three layers, plus the non-human identities described below, or it is only solving part of the problem.
Why Standing Access Is the Real Risk
The risk is not that privileged roles exist. It is that they sit active and unmonitored for weeks or months at a time, which is what security teams call standing access. A phishing email that lands a session token or a password for an account with standing Owner rights gives an attacker the same reach a legitimate admin has, with no time limit and often no alert until damage is already done. Time-boxing that access, so it exists only while someone is actively using it and only after a justification and approval, is what turns a stolen credential from a tenant-wide incident into a contained one.
The Blast Radius of a Global Administrator
Global Administrator in Entra ID is the account type worth treating with the most caution, because its reach extends beyond the directory. A Global Admin can enable "Access management for Azure resources" and grant themselves the User Access Administrator role on every subscription under the tenant root management group, reset MFA for any user, add or remove federated domains, and manage Conditional Access policies that gate every other control in the environment. Compromise one Global Admin account with no time-boxing and no session monitoring, and the incident is not a resource-group problem. It is a tenant problem.
Entra ID PIM: What It Actually Does and Where It Stops
Microsoft Entra ID Privileged Identity Management is the native answer to standing access, and it does the core job well. Users get eligible assignments instead of active ones, activate a role for a fixed window with a justification, and can be required to trigger an approval workflow and satisfy multi-factor authentication before the elevation takes effect. Access reviews let an owner periodically confirm that every eligible assignment still belongs to someone who needs it, and every activation is logged for audit.
PIM has real limits worth knowing before it becomes the whole PAM strategy. It requires Entra ID P2 (bundled in Microsoft 365 E5 or sold standalone), which is a licensing decision that has killed more than one rollout before it started. It covers Entra directory roles and Azure resource roles, not third-party SaaS admin consoles, not on-premises Active Directory, and not the local administrator accounts on virtual machines. It has no session recording, no keystroke logging, and no password vaulting for shared or service accounts, because it manages role assignment, not credentials. For a small, Azure-only estate with clean role hygiene, PIM plus Conditional Access and access reviews can be the entire programme. For anything larger, it is the first layer, not the last.
Where a Dedicated PAM Platform Fits
A dedicated PAM platform earns its cost when the environment has needs PIM was never built to cover: password vaulting and automatic rotation for shared local admin and service accounts, session recording and isolation for RDP or SSH into VMs, credential rotation for service accounts that cannot run as managed identities, and one consistent control plane across Azure, on-premises AD, and other clouds instead of a different tool per environment. On the vendor side, BeyondTrust and Arcon PAM are two platforms UAE enterprise and banking buyers evaluate for this layer, and the right choice comes down to deployment model, depth of session control, and how much operational overhead the security team can absorb, not the feature list alone. Neither replaces PIM. Both expect it to already be doing the Entra ID and Azure RBAC layer correctly.
The Overlooked Privileges: Service Principals and Managed Identities
Human accounts get the PAM attention, and non-human identities quietly accumulate the same level of risk. A CI/CD pipeline's service principal with Contributor on a whole subscription, an automation account with a client secret that never rotates, or an application registration with API permissions nobody has reviewed since it was created, all carry privilege that standard PIM reviews rarely touch. Managed identities are the correct fix for workload-to-workload authentication because there is no credential to steal, but adopting them does not remove the need to audit the scope each identity was actually granted. Scope creep on a service principal is invisible until someone goes looking for it.
Hybrid Azure: Where PAM Gets Forgotten
Most UAE enterprises running Azure are not Azure-only. They sync an on-premises Active Directory into Entra ID through Entra Connect (formerly Azure AD Connect), and that sync server is a tier-0 asset in every sense of the term, even though it rarely shows up in a cloud PAM conversation. The account that Entra Connect uses to write changes back to the directory can, if compromised, be used to push arbitrary changes into Entra ID, including granting Global Administrator to an attacker-controlled account. Vaulting the passwords for Azure console admins while leaving the Entra Connect sync account and the server it runs on outside the PAM programme is one of the more common gaps in hybrid deployments, and it is the one assessors with real AD experience tend to ask about first.
What Assessors and Auditors Ask For
Regulatory frameworks relevant to UAE and GCC organisations, including NESA-aligned controls and CBUAE requirements for banks, do not usually specify a product. What they expect is evidence: a named owner for every privileged account, logs showing that elevation was time-bound and justified, records of periodic access reviews rather than a policy document that says reviews happen, multi-factor authentication enforced on every privileged session through Conditional Access, and a documented, monitored process for break-glass accounts. A break-glass account that bypasses Conditional Access for emergency access is necessary. One that nobody watches for actual use is a finding waiting to happen.
Common Deployment Failures
The same handful of mistakes show up across most PIM and PAM rollouts. Standing Owner or Contributor roles get left in place "as a fallback" alongside a new PIM configuration, which defeats the point of eligible assignments entirely. Break-glass accounts get excluded from Conditional Access and then never monitored, so their existence becomes the exact standing-access risk the rest of the programme was built to remove. PIM activation gets configured as pure self-service with no approval step, which satisfies the letter of "time-boxed access" while losing most of its audit value. Legacy Co-Administrator and Service Administrator roles, leftovers from older Enterprise Agreement or CSP subscriptions, sit forgotten and unreviewed because nobody expects Azure's classic subscription model to still be active. And organisations vault their cloud console credentials carefully while leaving VM-level local administrator accounts and RDP sessions completely outside the programme.
Scoping PAM for Azure: A Decision Rule
Start with Entra ID PIM, Conditional Access, and scheduled access reviews if the estate is Azure-only, admin headcount is small, and there is no shared or service-account sprawl to manage. Move to a dedicated PAM platform when any of the following is true: the environment is hybrid with an on-premises AD tier-0 to protect, third-party admin consoles sit outside Entra ID's reach, shared or service accounts cannot be converted to managed identities, or a regulator or client contract requires session recording that PIM does not provide. Buying the platform first and configuring PIM as an afterthought is the more expensive way to arrive at the same place, and it usually leaves the Entra Connect sync account unprotected in the meantime.