What do teams get wrong about privileged access management in Azure?

Why This Matters for Security Teams

In Azure, Privileged Identity Management is often treated as if it were the whole PAM programme, but it only covers activation of eligible roles. That leaves the harder problem untouched: who or what still has standing privilege elsewhere, how permissions drift over time, and whether non-human identities have been over-assigned access in the first place. NHI Management Group’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both point to the same operational gap: excessive privilege is usually distributed across service principals, managed identities, and legacy role assignments, not just human admins.

That matters because Azure control planes are broad, and a single mis-scoped role can expose subscriptions, secrets, or application infrastructure far beyond the original intent. Industry guidance from the NIST Cybersecurity Framework 2.0 pushes organisations toward continuous governance rather than one-time approval, which is the right lens here. In practice, teams discover the gap only after a review, an incident, or a failed audit exposes that PIM was protecting activation timing while standing privilege remained intact elsewhere.

How It Works in Practice

The practical mistake is thinking “PAM in Azure” means only requiring approval before a user activates a privileged role. PIM is useful, but it is a control layer inside a broader identity governance model. A complete approach needs role right-sizing, regular entitlement review, workload identity inventory, secret hygiene, and revocation paths for unused access. NHI Management Group’s Ultimate Guide to NHIs shows why: NHIs outnumber human identities by 25x to 50x in modern enterprises, so any human-centric PAM design will miss most of the attack surface.

Teams usually need to combine several controls:

• Use PIM for eligible human admin roles, approval workflows, and time-bound activation.
• Review Azure role assignments for subscription, resource group, and resource scope separately.
• Treat managed identities, service principals, and app registrations as privileged workloads, not “special cases.”
• Remove unused assignments and inherited permissions from groups that act as hidden privilege containers.
• Prefer short-lived access and tightly scoped secrets over long-lived credentials in code or pipelines.

That model aligns with the intent of the OWASP Non-Human Identity Top 10, which treats identity sprawl and over-privilege as primary NHI risks, not secondary hygiene issues. It also fits the operational reality of Azure, where a managed identity with broad contributor rights can be more dangerous than a human admin who must at least pass through activation gates. These controls tend to break down in large multi-subscription environments because inherited RBAC, custom roles, and application-owned identities create privilege paths that PIM never evaluates end to end.

Common Variations and Edge Cases

Tighter privilege controls often increase administrative overhead, requiring organisations to balance lower blast radius against slower provisioning and more frequent access reviews. That tradeoff becomes visible in Azure landing zones, DevOps pipelines, and platform teams that rely on automation to move quickly.

One common edge case is “everything is PIM-enabled” but service principals still have permanent access to Key Vault, Storage, or resource groups. Another is using Azure group membership as a proxy for least privilege, which can hide excessive access behind nested assignments. Current guidance suggests that entitlement sprawl should be reviewed separately from activation controls, but there is no universal standard for how often every workload identity should be recertified. The safest pattern is to pair PIM with continuous entitlement analysis, secret rotation, and clear ownership for every non-human identity.

For organisations building a broader NHI programme, the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for mapping provisioning, review, rotation, and offboarding as one lifecycle rather than separate tasks. Azure-specific risk often surfaces when cross-cloud or CI/CD permissions are ignored, because PIM does not govern access outside Microsoft Entra ID and does not automatically remove stale application rights. In practice, many teams only realise they have a PAM problem when a workload identity, not a human user, is the path to privilege escalation.

Related resources from NHI Mgmt Group

• What do IAM teams get wrong about privileged access management?
• What do teams get wrong about privileged access management?
• What do teams get wrong about AI security and access management?
• What do teams get wrong about just-in-time privileged access?