Entra PIM Activation Approval MFA Justification Misconfiguration

Entra PIM Activation Approval MFA Justification Misconfiguration Explained

Turning on Microsoft Entra Privileged Identity Management (PIM) is the easy part. Entra PIM activation approval MFA justification misconfiguration is what happens next: PIM is deployed, roles are eligible instead of permanent, but the activation step itself is left wide open — no approval required, no MFA on activation, no justification logged, and an 8-hour or longer activation window. The result looks like just-in-time access on a dashboard, but behaves like standing admin access in practice: anyone eligible for a role gets it the moment they click "Activate," with no second factor, no accountability trail, and a window long enough to outlast most detection cycles.

This is a distinct failure mode from "PIM isn't enabled at all." A tenant can pass that first check and still be exposed, because PIM's security value comes almost entirely from how activation is configured, not from the fact that eligible assignments exist. Each of the four activation controls — approval, MFA, justification, and duration — is optional per role in Microsoft Entra, and none of them are required by default.

How PIM Activation Controls Work

Microsoft Entra exposes PIM role settings — internally called policies — through the Microsoft Entra admin center (ID Governance > Privileged Identity Management > Microsoft Entra roles > Roles > [role] > Role settings) or through the unifiedRoleManagementPolicy Microsoft Graph resource. Each policy is made of independent rules, and four of them define what happens at activation time (Configure Microsoft Entra role settings in PIM, Update rules in PIM by using Microsoft Graph):

All four are configured per role and none are mutually exclusive — a well-hardened role typically has approval and MFA and justification and a short duration, not just one of them.

Why "PIM Enabled" Is Not the Same as "Activation Is Protected"

A related, more basic check is whether PIM is configured for privileged roles at all — that is a separate, more severe gap, and we cover it in Azure Privileged Access: Too Many Global Admins. This article assumes that check already passes: PIM is on, roles are eligible, and the tenant looks compliant on a first pass. The gap here is one layer deeper — it is what happens inside PIM once someone activates.

The four defaults matter because none of them lean secure out of the box:

• Approval defaults to off. Any eligible user can self-activate immediately, with no second person involved.
• MFA on activation has a documented blind spot. Microsoft's own guidance notes that "users might not be prompted for multifactor authentication if they authenticated with strong credentials or provided multifactor authentication earlier in the session" — so a session that already satisfied MFA at sign-in can activate a privileged role with no additional challenge at all. This is the same reauthentication gap covered in Azure Identity Security: Why MFA Alone Is Not Enough.
• Justification defaults to off, so activations carry no recorded business reason — which weakens both real-time review and after-the-fact audit.
• Activation maximum duration defaults to 8 hours and can be set as high as 24 — long enough for a hijacked session or token to be useful for an entire workday.

🚨 Danger: because the MFA-on-activation setting does not force re-authentication when MFA was already satisfied in the session, an attacker who has stolen a valid session token can activate a privileged role without ever touching a second factor. Microsoft's documented mitigation for this specific gap is Conditional Access authentication context combined with sign-in frequency set to "Every time" — not the basic MFA-on-activation checkbox.

Detection

What to check per role

Pull the current activation policy for every Microsoft Entra directory role and compare it against the four controls above. Manually, this means opening Role settings for each role in the admin center. At scale, query it through Graph:

GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole'&$expand=rules

Or with Microsoft Graph PowerShell:

# Requires RoleManagement.Read.Directory or RoleManagement.ReadWrite.Directory
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$policies = Get-MgPolicyRoleManagementPolicyAssignment -Filter "scopeId eq '/' and scopeType eq 'DirectoryRole'"
foreach ($p in $policies) {
    Get-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $p.PolicyId |
        Where-Object { $_.Id -in @('Approval_EndUser_Assignment','Enablement_EndUser_Assignment','Expiration_EndUser_Assignment') }
}

For each role, flag it if: isApprovalRequired is false, enabledRules for the enablement rule does not include MultiFactorAuthentication, enabledRules does not include Justification, or maximumDuration on the expiration rule exceeds your policy threshold (commonly 1-4 hours for Tier-0 roles). Prioritize Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, and any custom role with directory-wide write permissions — these are the roles where the gap has the highest blast radius.

What to watch in the audit log

Microsoft Entra keeps PIM policy and activation history in the Resource audit blade (ID Governance > Privileged Identity Management > Microsoft Entra roles > Resource audit), retained for 30 days by default (View audit log report for Microsoft Entra roles in PIM) — if that default window is a problem for your investigation timelines, see Entra ID Logging: Retention, Diagnostic Settings, SIEM Export Gaps for how to route it to longer-term storage. Two activity types matter most:

Remediation

1. Enumerate every role's current policy using the Graph query or PowerShell above so you have a before/after baseline, not just a per-role guess.
2. Require approval to activate for Tier-0 roles, with at least two named approvers configured explicitly. Do not leave the approver list empty: Microsoft's own guidance warns that a tenant can be locked out if every Privileged Role Administrator/Global Administrator has only eligible (not active) assignments, approval is required, and no approvers are configured — build in properly monitored emergency access accounts as active, permanent assignments before you turn this on.
3. Require MFA on activation, and where the role justifies it, layer on Conditional Access authentication context with sign-in frequency set to "Every time" — this is the setting that actually forces re-authentication at activation, instead of silently accepting an MFA claim from earlier in the session.
4. Require justification on activation (and consider requiring ticket information too) so every activation carries a recorded, reviewable business reason.
5. Reduce activation maximum duration. The 8-hour default and 24-hour ceiling both exist for convenience, not security — most operational tasks fit inside 1-4 hours. Set it with the expiration rule's maximumDuration in ISO 8601 format (PT2H for two hours, PT4H for four).
6. Apply the same policy to every equivalent role, not just the one you tested. Role settings are independent, so a script that patches Global Administrator only leaves Privileged Role Administrator, Security Administrator, and custom directory roles unchanged.
7. Re-run the Graph enumeration query after the change and confirm isApprovalRequired: true, enabledRules includes MultiFactorAuthentication and Justification, and maximumDuration reflects your new ceiling — then repeat this check on a schedule, since a later Update role setting in PIM event can silently roll any of it back.

How EtcSec Detects This

EtcSec's Azure audit checks PIM activation policy on every scan, independently of whether PIM itself is enabled.

PA_PIM_NO_APPROVAL_REQUIRED flags eligible role assignments where activation does not require approval.

PA_PIM_NO_MFA_ON_ACTIVATION flags roles where the activation policy does not require multifactor authentication.

PA_PIM_NO_JUSTIFICATION flags roles where activation does not require a business justification.

PA_PIM_LONG_ACTIVATION flags roles configured with an activation maximum duration long enough to materially extend exposure after a compromised activation.

Related Controls

PIM activation hardening is one layer of privileged access control. Review it together with Azure Privileged Access: Too Many Global Admins for whether PIM is deployed and standing admin counts are under control, Entra ID Break Glass Emergency Access Accounts before you require approval on Tier-0 roles, Azure Identity Security: Why MFA Alone Is Not Enough for the reauthentication gap MFA-on-activation alone doesn't close, and How to Audit Microsoft Entra ID Security for the full identity review checklist this fits into.

Primary References

• Configure Microsoft Entra role settings in PIM — Microsoft Learn
• Approve or deny requests for Microsoft Entra roles in PIM — Microsoft Learn
• Update rules in PIM by using Microsoft Graph — Microsoft Learn
• View audit log report for Microsoft Entra roles in PIM — Microsoft Learn
• Manage emergency access accounts in Microsoft Entra ID — Microsoft Learn