- Entra Privileged Identity Management (PIM) handles time-bound elevation of Azure AD directory roles. It is not a replacement for a PAM vault that manages on-premises AD, network devices, databases, and service accounts.
- The accounts that break audits are rarely human admins. They are service principals, managed identities, and app registrations with owner-level Graph API permissions that nobody reviews.
- Assessors care less about which vendor you bought and more about whether you can produce a current privileged account inventory and prove every session was recorded and reviewed.
- Agent-based session proxying and agentless credential injection trade performance and blast radius differently. Pick based on what you are protecting, not on what the vendor demos best.
PIM is not PAM, and conflating them is the first mistake
Entra ID Privileged Identity Management does one job well: it turns a standing Global Administrator or Azure role assignment into a just-in-time activation with an approval step and a time limit. That is genuinely useful and it is included in Entra ID P2 licensing, which is why so many Azure projects stop there and call it done.
PIM does not touch local administrator accounts on a domain controller, the root credential on a network switch, a database service account with sysadmin rights, or an SSH key sitting in a deployment pipeline. It has no session recording, no keystroke logging, and no password rotation for anything outside the Azure AD directory role model. A GCC bank that has PIM configured for its ten Global Administrators and nothing else has covered a narrow slice of its actual privileged surface, and an assessor who asks for a full privileged account inventory will find that out in the first meeting.
The organisations that get this right run both layers deliberately: PIM for directory and subscription-level role activation, and a dedicated PAM platform such as BeyondTrust or Arcon for everything with a standing credential outside that model, on-premises AD, hypervisors, network gear, databases, and break-glass accounts.
The scope problem: what actually needs vaulting
Most PAM projects start with a discovery exercise that finds the accounts everyone already knows about: domain admins, the handful of named IT administrators, and root on the Linux estate. That list is usually a third of the real privileged surface in an Azure-hybrid environment.
Service principals and managed identities are the blind spot
Every app registration with an owner-consented Graph API permission, every automation runbook using a managed identity with Contributor on a subscription, and every CI/CD pipeline holding a client secret is a privileged credential with no interactive login and no MFA prompt to slow it down. These accounts do not show up in a directory admin export because they are not human accounts, and most organisations have never inventoried them. A service principal with broad application or credential management permissions can often be turned into a path to much higher privilege, and because nobody is watching it the way they would watch a human admin account, that escalation tends to go unnoticed until an audit or an incident forces the question.
Vaulting scope should include, in rough order of onboarding priority: domain and enterprise admin accounts, Azure subscription Owner and User Access Administrator role holders, service principals and managed identities with write access to production resources, database and application service accounts, network device and hypervisor root credentials, and break-glass accounts held in reserve for directory outages.
Break-glass accounts need their own procedure, not an exception
Every Azure tenant needs at least two break-glass accounts excluded from Conditional Access and MFA enforcement, for the scenario where the identity provider itself is unreachable. That exclusion is correct and Microsoft documents it directly. The failure mode is treating "excluded from Conditional Access" as "excluded from monitoring." A break-glass account should sit in the vault with a password that rotates after every use, sign-in alerts routed to more than one person, and a documented procedure for when it is acceptable to check it out. Assessors ask for this procedure by name more often than for almost anything else in a PAM review, because an unmonitored break-glass account is the cleanest privilege escalation path in the tenant.
Architecture decisions that decide whether the deployment holds up
Two design choices matter more than which vendor logo is on the box.
Agent-based session proxying routes the administrator's RDP or SSH session through the vault, which records keystrokes and screen output and can terminate a session mid-stream if something looks wrong. It adds a hop, and a badly sized proxy tier turns into a bottleneck during patch windows when everyone needs access at once. Agentless credential injection checks a password out, hands it to the administrator's own client, and rotates it afterward. It is lower friction and easier to roll out across a large hybrid estate, but the vault loses visibility into what happened during the session, and if the endpoint the admin is using is already compromised the injected credential is compromised with it.
Neither approach is correct in isolation. A workable pattern is proxied, recorded sessions for anything touching production databases, domain controllers, or client data, and lighter checkout-and-rotate for lower-risk targets like a dev subscription, where the friction cost is not worth the marginal control.
Vault placement and high availability also decide whether the project survives contact with an outage. A PAM vault that sits in a single availability zone with no offline break-glass path becomes the single point of failure that takes down every administrator's ability to log in during an incident, which is precisely the wrong time to lose access. Vault HA design, and a documented offline fallback for the break-glass accounts, is not optional for anything classified as a tier-one system.
What assessors actually ask for
A NESA, CBUAE, or ISO 27001 review of privileged access rarely asks whether you own a PAM tool. It asks for evidence: a current, complete inventory of privileged accounts including service principals; proof that passwords or keys on those accounts rotate on a defined schedule; session logs or recordings for a sample of privileged access events, retained for a stated period; a segregation-of-duties matrix showing who can approve their own elevation requests (the answer should be nobody); a periodic access recertification record showing someone actually reviewed the list and removed accounts that no longer need standing privilege; and MFA enforced on every privileged access path, not just the ones that happen to sit behind Conditional Access by default.
The gap that shows up most often in these reviews is the recertification record. Vaulting an account once and never revisiting it satisfies almost none of the control intent behind a privileged access requirement. Assessors want to see a quarterly or semi-annual cycle where an owner confirms each privileged account is still needed, with the ones that fail that test actually deprovisioned rather than left dormant in the vault.
Where these projects go wrong in practice
- Onboarding the vault and stopping there, so passwords rotate but nobody ever reduces the number of people who hold standing admin rights in the first place.
- Recording sessions but never reviewing them, which satisfies a checkbox and defeats the actual purpose of the control.
- Leaving legacy service accounts with domain admin rights outside the vault because migrating them risks breaking a dependency nobody has documented.
- Sizing the session proxy tier for normal load and watching it fall over during a coordinated patch cycle, which then trains administrators to route around the vault entirely.
- Treating the PAM rollout as a one-time infrastructure project instead of an ongoing access governance process with an owner, a review cadence, and a budget line for the years after go-live.
Before scoping a PAM deployment
Get the account inventory right before evaluating vendors. If privileged access management is new territory for your organisation, start with the fundamentals of a PAM programme before comparing vault products, because the scoping decisions above are what separate a working deployment from a shelf-ware one. A platform with excellent workflow but blind spots in service principal discovery will pass its proof of concept and then miss the exact accounts an attacker or an auditor cares about. Decide upfront which systems need recorded, proxied sessions and which can run on checkout-and-rotate, because that split drives licensing cost and infrastructure sizing more than any other single decision. And build the access recertification cycle into the operating model from day one. A vault full of correctly onboarded accounts that nobody revisits is not a control, it is a very well organised list of the exact credentials worth stealing.
