PAM for Azure is not one product. Microsoft Entra ID Privileged Identity Management (PIM) gives just-in-time elevation for Azure and Entra roles, and a dedicated PAM platform vaults and rotates the credentials PIM never touches: VM local administrator accounts, service accounts, and on-premises domain admin in a hybrid estate. GCC financial institutions running hybrid Azure need both, not one instead of the other.
- Entra ID PIM covers just-in-time elevation for Azure RBAC and Entra roles. It does not vault or rotate credentials.
- VM local admin accounts, service accounts and SQL accounts need a separate vaulting layer or Windows LAPS.
- Hybrid estates with on-premises Active Directory need PAM that covers domain admin and the Entra ID Connect sync account, a common gap in audits.
- Assessors want evidence: access reviews, session logs, rotation intervals and monitored break-glass accounts, not a licence receipt.
What PIM actually does, and where it stops
Microsoft Entra ID Privileged Identity Management makes a role assignment eligible rather than active. A user with an eligible Owner or Contributor role has no standing permissions until they activate it, which triggers an approval step, a time limit, and an audit entry. That is genuinely useful: it removes the standing-Owner sprawl that shows up in almost every Azure tenant that grew organically, where a project team was made Owner on a subscription during a migration and nobody ever revoked it.
PIM's scope stops at Azure Resource Manager roles and Entra directory roles. It has nothing to say about the local Administrator account on a Windows VM, the service account running a scheduled SQL job, the API key embedded in a Logic App connection, or the domain admin account your on-premises AD still depends on if you run Entra ID Connect. Treating PIM as full PAM is the single most common gap I see when reviewing Azure environments for GCC banks and insurers: the directory layer looks disciplined, and the compute and data layer underneath it is unmanaged.
Where a dedicated PAM platform earns its place
A vaulting platform such as Arcon PAM or BeyondTrust adds three things PIM cannot: credential rotation for local and service accounts, session recording for RDP and SSH into privileged targets, and discovery that finds accounts nobody registered. Discovery matters more than it sounds. Every hybrid Azure estate I have looked at has service accounts created for a one-off migration or integration project that were never decommissioned, still holding Contributor or Domain Admin rights, with a password that has not rotated since creation.
For a bank running Azure alongside an on-premises datacentre, the accounts that actually need vaulting are usually: the Entra ID Connect sync account (which by design has directory-write permissions and is a well-known attack path if compromised), break-glass emergency-access accounts, SQL Server service accounts, and local admin credentials on domain-joined VMs. None of these sit inside PIM's scope, and none of them should be managed through a spreadsheet with a rotation reminder in a shared calendar, which is what most mid-size deployments are actually running on before an assessment forces the conversation.
The licensing decision that shapes everything else
PIM for Azure resources is included with Entra ID P2, which most enterprise agreements already carry as part of Microsoft 365 E5 or a standalone P2 SKU. That makes PIM close to free for institutions that already hold that licence, and it is why it should always be the first layer, not an afterthought bolted on after a third-party platform is chosen.
A dedicated PAM platform is priced per privileged account or per session, and the number that matters in the proposal is not the licence count in the sales deck but the actual count of accounts with standing privileged access once discovery has run. Institutions consistently budget for the number of admins they think they have, not the number discovery actually turns up once service accounts, shared accounts and forgotten test accounts are counted. Budgeting before discovery is how PAM projects blow their first-year cost estimate.
Just-in-time versus always-vaulted
The other real tradeoff is architectural, not financial. PIM's just-in-time model suits human administrators doing planned work: it adds friction (an approval, a timer) that is proportionate to the risk. Vaulted, checked-out credentials suit service accounts and break-glass accounts, where there is no human to approve an elevation request in real time and the account either has a rotated, brokered credential or it has a static one that anyone with vault access can read forever. Trying to force human just-in-time workflows onto service accounts, or trying to vault every human admin action, both produce friction in the wrong place and get worked around within a quarter.
Failure modes that show up in real deployments
The recurring problems are not exotic. Standing Owner or Global Administrator role assignments that were never converted to PIM-eligible, because converting an existing assignment requires someone to accept a short window of reduced access while it happens, and nobody schedules that window. Service principals with certificate-based authentication that expired and were replaced with a client secret "temporarily," which then sits unrotated in a CI pipeline for as long as nobody asks why it is there. Break-glass accounts that exist, have strong passwords, and are checked by nobody: no alert fires when they authenticate, because setting up that alert was left off the original PIM rollout plan. And conditional access policies that require MFA for interactive sign-in but exempt service accounts and legacy authentication, which is exactly the exemption an attacker who has phished a service account credential is counting on.
What assessors actually check
For CBUAE-regulated banks and DIFC or ADGM-licensed entities, an assessor reviewing privileged access management is not looking for a PAM licence certificate. They ask for the access review history (who approved which elevation, and when the last periodic review ran), the list of accounts excluded from PIM and the justification for each exclusion, session logs for a sample of privileged sessions into production, and evidence that break-glass accounts are monitored rather than merely provisioned. If the answer to "show me the last three access reviews" is a blank stare, the control is not operating regardless of what the architecture diagram says.
Segregation of duties is the other recurring finding: the same identity that can approve a PIM elevation request should not also be the identity being elevated, and the same team that manages the PAM platform should not be the only team with vault administrator rights with no second approver for emergency access.
Where least privilege, micro-segmentation and CSPM fit around PAM
PAM enforces least privilege at the identity layer: PIM's eligible-not-standing model and a vaulting platform's checked-out credentials both exist to give an identity the minimum access it needs for the minimum time. That principle stops at the identity boundary. Micro-segmentation, using Azure network security groups, Azure Firewall or workload-level policies, decides what a compromised or over-privileged identity can actually reach once a credential is elevated. Without it, PAM limits who can act but not how far an attacker with a working session can move once inside the network.
Cloud security posture management tools such as Microsoft Defender for Cloud cover the configuration drift that a one-time PAM discovery exercise cannot: PIM-eligible assignments quietly converted back to standing access, permissions scoped at the subscription level instead of a resource group, and identities holding rights nobody remembers granting. CSPM findings are what keep a PAM programme's baseline accurate between the periodic access reviews assessors ask for, rather than letting least privilege and segmentation decay silently until the next audit finds them.
Building the control set without over-engineering it
Sequence it. Get PIM covering every Azure RBAC and Entra directory role first, since it is close to free and removes the largest single risk (standing Owner access) fastest. Run discovery for unmanaged privileged accounts across both Azure and on-premises AD before scoping a vaulting platform, so the account count in the business case is the real one. Vault the accounts a human cannot approve in real time: service accounts, the Entra ID Connect sync account, and break-glass credentials. Turn on session recording for the smallest set of high-risk targets first, typically domain controllers and the systems in card-data or core-banking scope, rather than every server, because recording everything produces a volume of session data nobody reviews. Feed PIM activation events and PAM session alerts into whatever SIEM already ingests your Azure logs, since a privileged elevation with no corresponding alert defeats the point of logging it at all.
None of this needs to happen at once, and a phased rollout that actually gets reviewed each quarter beats a full deployment that goes live and is never touched again. A broader privileged access management programme covers the same ground for non-Azure targets, and it should share the access-review and rotation cadence rather than run as a separate process with a separate spreadsheet.
