- PIM governs Entra roles. It does not manage on-premises AD, network device credentials or shared service accounts, which is where most privileged access actually lives in a hybrid estate.
- The Entra Connect (Azure AD Connect) sync account carries tier-0 equivalent privilege and is rarely covered by any privileged access programme.
- Application permissions granted to service principals bypass Conditional Access and MFA entirely, which makes them a higher-value target than most human admin accounts.
- Assessors want role activation logs, a working access review cadence and a tested break-glass procedure, not a policy document describing least privilege in the abstract.
What Microsoft Entra ID actually exposes
Azure AD, renamed Microsoft Entra ID in 2023, is the identity control plane for Microsoft 365, Azure subscriptions and most SaaS applications an organisation federates through it. GCC enterprises, in particular the UAE banks and government entities that have consolidated fastest onto Microsoft 365, tend to route almost every workforce identity through a single Entra ID tenant, which is exactly why that tenant draws attacks: a single compromised Global Administrator account can read every mailbox, reset every password, add a trusted federation domain and grant itself access to any connected application. There is no equivalent blast radius in a traditional on-premises directory, where a compromise usually stays inside the domain it started in.
Most Entra ID compromises still start with something ordinary: a password spray against accounts without MFA, a consent phishing page that tricks a user into authorising a malicious OAuth application with a broad Graph scope, or a legacy authentication protocol (IMAP, POP, older ActiveSync clients) that ignores the Conditional Access policies applied to the modern sign-in flow. None of these need a zero-day. They need one account with wide rights and no time limit on how long those rights stay usable.
Where Privileged Identity Management stops and PAM starts
Microsoft Entra ID P2 licenses Privileged Identity Management (PIM): eligible role assignments, time-bound activation, approval workflows and access reviews for built-in and custom directory roles. For an organisation whose privileged access genuinely lives entirely inside Entra ID and Azure RBAC, PIM on its own is a defensible answer, and cheaper than buying a separate platform to solve a problem Microsoft already licenses.
The gap shows up at the boundary. PIM governs roles inside the tenant. It has no view of local administrator accounts on domain-joined servers, the on-premises Active Directory domain that most hybrid tenants still run behind Entra Connect, shared service account passwords used by applications and scheduled jobs, network device and database administrative credentials, or session activity: what an admin actually did once a role was activated, not just that they activated it.
This is the case for a dedicated PAM platform such as ARCON PAM or BeyondTrust: one vault and policy engine across the hybrid estate, with session recording for the accounts PIM cannot reach because they never lived inside Entra ID to begin with.
Just-in-time activation versus standing access
Just-in-time access means a role or credential is granted only for the duration of a task, then automatically withdrawn. In PIM this is role activation with a maximum duration and an optional approval step. In a third-party PAM platform it is typically a credential checked out of a vault and returned on session close or timeout. Either mechanism turns a standing risk, an always-on Global Administrator, into a bounded one: a role active for at most a few hours, tied to an approved request and a ticket reference. The question worth asking of any environment is not whether MFA is enabled, but how long a given privileged credential stays usable after the task it was needed for is finished.
The identity paths attackers actually use
Service principals and application permissions
App registrations and their service principals are the most under-governed privileged identity in most Entra ID tenants. A service principal holding an application permission, rather than a delegated one, acts on its own authority and is not subject to the signed-in user's Conditional Access policy or MFA requirement. An application granted a broad application-level Graph permission, sitting on a client secret stored in a configuration file or a build pipeline, is functionally a standing admin account with no session, no MFA challenge, and often no owner left who remembers it exists. Certificate-based authentication instead of long-lived secrets, and a periodic inventory of granted application permissions, belong in the same governance programme as human privileged access rather than a separate process developers own and nobody reviews.
The synchronisation account blind spot
Entra Connect uses a sync account that holds directory synchronisation privilege and, in many tenants, effective write access to sensitive attributes across every synced object. Compromise of the server running Entra Connect, or theft of that account's credential, gives an attacker a path to manipulate password hash synchronisation or object attributes without ever touching a role that shows up in a PIM report. Treat the Entra Connect server as tier-0 infrastructure: dedicated hardening, no general admin logon, and its credential stored in the same vault as domain admin credentials rather than left on a service account configured once at installation and forgotten.
Building the operating model
A workable programme keeps three things separate that get conflated in most rollouts: who can request privileged access, who approves it, and who can see what was done with it once granted.
- Map every path to tier-0 equivalent privilege first: Global Administrator, Privileged Role Administrator, Application Administrator (which can add credentials to any app, including one holding Global Administrator-equivalent permissions), and the Entra Connect sync account. These get the strictest controls regardless of how the role happens to be named.
- Require phishing-resistant authentication, such as FIDO2 security keys or certificate-based sign-in, for any account eligible for a tier-0 role. One-time codes and SMS do not stop the push-fatigue and real-time phishing techniques used against MFA today.
- Keep two break-glass accounts excluded from Conditional Access, with long random passwords stored offline, and alert on every sign-in to them. Test them on a fixed schedule; an untested break-glass account is a theoretical control, not a working one.
- Run access reviews on a fixed cadence rather than ad hoc. Entra ID Access Reviews, or the equivalent inside a third-party PAM platform, should force a named approver to reconfirm each privileged assignment rather than silently renew it.
Segregating identity admins from workload admins
A recurring design fault is letting the same group of administrators manage both the identity plane (Entra ID roles, Conditional Access, federation) and the workloads that plane protects (Azure subscriptions, Microsoft 365 data, connected SaaS). Keeping these separate means a compromised workload admin cannot touch Conditional Access policy, and a compromised identity admin cannot walk straight into production data without a second, differently privileged credential. This is organisational discipline more than product configuration, and it is the control assessors probe hardest, because it is the one most enterprises skip to save headcount.
Failure patterns worth naming
The same handful of gaps recur across hybrid Entra ID environments in the UAE and the wider GCC region: PIM licensed but never actually turned on, so every "eligible" assignment behaves like a permanent one; legacy authentication left enabled for a handful of line-of-business applications nobody wants to break; break-glass accounts created once and never tested; and privileged session activity that never reaches a SIEM at all, leaving an investigation with role activation timestamps but no record of what happened inside the session. Fixing the licensing and the policy is usually the easier half. Fixing the habit of granting standing access because a time-bound request is inconvenient is the half that actually reduces risk.
What UAE and GCC assessors ask to see
Regulators and frameworks relevant to UAE and wider GCC banking and government buyers, including CBUAE guidance and ISO 27001 control sets, rarely prescribe a specific PAM product. What they consistently ask an organisation to produce is evidence: a current list of privileged role holders reconciled against the joiner-mover-leaver process, activation logs showing time-bound rather than standing access, a tested and documented break-glass procedure, and proof that privileged session activity is logged somewhere it cannot be altered by the account being monitored. Sign-in and audit logs from Entra ID, correlated with PAM session data in a SIEM, are what turn a policy document into twelve months of evidence an auditor can actually sample.
Deciding whether PIM is enough
If every privileged account in the organisation lives inside Entra ID and Azure RBAC, with no on-premises directory, no shared service accounts and no legacy network infrastructure, Entra ID P2 with PIM properly enabled and enforced is a defensible answer on its own. The moment any of those conditions is false, which describes most hybrid enterprises in the region, PIM becomes one control inside a broader PAM programme rather than a replacement for one. Map every tier-0 equivalent path first, including the ones that never show up in a role assignment report, before choosing a tool to enforce access to them. For scoping that wider programme, see the PAM FAQ.
