- Entra ID roles, Azure RBAC roles and resource-level permissions are three separate privilege layers. Most PAM reviews only check one of them.
- Service principals and managed identities carry standing privilege and largely sit outside Conditional Access and Privileged Identity Management.
- Native Entra Privileged Identity Management handles just-in-time elevation for directory and Azure resource roles. It does not vault passwords, record sessions, or manage legacy and on-premises systems.
- Assessors ask for a privileged account inventory, PIM configuration evidence, break-glass account controls and session logs, not a policy document.
Privilege in Azure Lives in Three Places, Not One
Most conversations about PAM in Azure start and end with Global Administrator. That role matters, but it is only one entry point. Azure RBAC operates on a separate hierarchy: management group, subscription, resource group, resource. A user with Owner at the management group level controls every subscription underneath it, and that assignment is invisible if you only audit Entra ID directory roles. A third layer sits inside individual services: Key Vault access policies, Storage account SAS tokens, SQL server firewall and login grants. Each layer has its own permission model, its own audit log, and in many organisations its own owner. A PAM assessment that stops at "who has Global Admin" misses the RBAC assignments and the resource-level grants that usually carry the actual blast radius.
Where Azure PAM Deployments Actually Fail
The common failure pattern is not a missing tool. It is scope. Organisations buy or enable a PAM capability, point it at directory roles, and stop. The gaps that show up repeatedly in Azure environments:
- Standing Owner or Contributor assignments at subscription scope, granted years ago for a migration project and never revoked.
- Privileged Identity Management enabled for Entra roles but not extended to Azure resource roles, so subscription-level Owner stays a permanent assignment while Global Admin is time-bound.
- Break-glass accounts that exist on paper but are never tested, never monitored for sign-in activity, and share a password with another admin account.
- The Entra Connect (formerly Azure AD Connect) sync account left with its default on-premises Domain Admin rights, creating a direct path from on-prem compromise to full Entra control.
- No inventory of which humans, groups, service principals and managed identities hold privileged roles, because the inventory job was assigned to whichever team ran the PIM rollout and nobody owns the RBAC side.
Service Principals and Managed Identities Are the Blind Spot
Human accounts get the attention. Non-human identities carry the risk. Service principals created for CI/CD pipelines, integration platforms or SaaS connectors are routinely granted Contributor or Owner at subscription scope because it is faster than scoping a custom role, and that grant then sits untouched because nobody reviews app registrations the way they review user accounts. Client secrets on those service principals often have no expiry set, or an expiry that gets silently extended by whoever renews the pipeline. Conditional Access policies built around user sign-in, device compliance and MFA generally do not apply to service principal authentication in the same way, so a policy that looks strict for people can be irrelevant for the identity that actually has Owner on production.
Managed identities remove the credential-theft problem, since there is no secret to steal directly, but they replace it with a blast-radius problem: any compute resource carrying that identity, a VM, a Function App, a Logic App, inherits its permissions completely. A single Function App with a misconfigured trigger and a system-assigned identity holding Contributor on a subscription is a full subscription compromise if that Function is ever exploited. The identity is only as strong as the weakest thing running with it.
Native PIM Covers Less Than People Assume
Microsoft Entra Privileged Identity Management does real work: eligible-versus-active assignment, time-bound activation, approval workflows, justification prompts, and alerting on role activation. Extending PIM to Azure resource roles and to Privileged Access Groups closes a real chunk of the standing-access problem described above, and it should be the first thing enabled, before anyone evaluates a third-party product.
What PIM does not do is vault or rotate local administrator and service account passwords on domain-joined servers, record or replay privileged sessions, manage privilege on non-Microsoft platforms (network devices, databases, SaaS admin consoles, OT systems), or give a single console across a hybrid estate that still has on-premises Active Directory. That is the gap third-party PAM products such as BeyondTrust are built to close: vaulting and rotating passwords for legacy and on-premises accounts, recording privileged sessions, and discovering accounts nobody remembers creating. The decision to bring one in, and which platform to pick over the native Entra ID controls, comes down to how much of the estate is still on-premises or non-Azure, not which product has the longer feature list.
When PIM Alone Is Enough
A cloud-only estate with no legacy on-premises servers, no OT assets and a small number of service accounts can often run on PIM plus disciplined Conditional Access and a documented break-glass procedure. The moment there is a hybrid AD footprint, network device administration, or a compliance requirement for recorded privileged sessions, PIM alone stops being sufficient and the conversation moves to a dedicated PAM platform.
What Assessors Actually Check
A PAM review that goes beyond a policy document asks for:
- A current inventory of every account, group, service principal and managed identity holding a privileged Entra or Azure RBAC role, with the business owner named against each.
- PIM configuration exports showing eligible assignments, activation duration limits and approval requirements, not just a screenshot of the PIM blade.
- Evidence the break-glass accounts are excluded from Conditional Access deliberately, monitored for any sign-in activity, and tested on a defined schedule.
- Service principal credential expiry settings and a record of which pipelines or integrations own each app registration.
- Audit logs showing role activations tied to a change ticket or approval, not just the raw Entra sign-in log.
- A tested procedure for revoking access when a contractor or third-party integration is offboarded, since privileged access granted to a vendor is the access most often forgotten.
Regulatory Context, Held Honestly
Regulators and frameworks relevant to GCC entities, NESA-aligned controls in the UAE, CBUAE requirements for banks, ISO 27001, do not publish an Azure-specific PAM checklist. What they expect, consistently, is evidence of least privilege, access review on a defined cycle, and monitoring of privileged activity. An assessor working against any of these frameworks will accept a well-run PIM and RBAC review as evidence. What fails an assessment is not the absence of a specific product; it is the absence of evidence that anyone reviews privileged access at all.
Where to Start
Run the RBAC and Entra role inventory before buying anything. Extend PIM to Azure resource roles if it is not there already. Fix the Entra Connect sync account privilege before evaluating a third-party PAM platform, since that single account undoes most of what a PAM tool elsewhere in the estate is protecting. Only bring in a dedicated PAM platform once the native controls are configured correctly and the remaining gap, legacy systems, session recording, OT, hybrid identity, is the reason a bigger tool is needed rather than a substitute for configuring the one already included in the licence.
