Privileged Identity Management: eligibility, approval and the audit trail

Standing privilege is the problem. An account that is permanently a Global Administrator is permanently worth stealing, and its privilege is available to anyone who obtains a token for it at any hour of any day.

Privileged Identity Management addresses this by making the role assignment eligible rather than active. The person holds the potential to be an administrator and must deliberately activate it, for a bounded period, with a justification and optionally an approval. Outside that window they are an ordinary user.

That is a genuinely different security posture, and the implementation difficulty is entirely organisational.

Requirements

Microsoft Entra ID P2 or an equivalent licence, for every user who will be eligible for a role through PIM. This is the first hard gate, and it is worth confirming your licensing position before designing anything.

A role inventory. Who currently holds which privileged role, whether they need it, and whether the assignment is to a person, a service account or a workload identity. This is the step that stalls deployments, because the answer is usually “more people than expected, for reasons nobody remembers”.

An agreed activation experience. How long an activation lasts, whether approval is required, what justification is expected, and who approves. These are policy decisions that need an owner before you configure anything.

Emergency access accounts that do not depend on PIM. Their role assignment should be permanent and active, for the reasons set out in emergency access accounts. PIM activation is a workflow, and a workflow is a dependency you do not want in a break-glass path.

Design: the decisions worth making carefully

Which roles go through PIM

Start with the roles that matter most and are used least. Global Administrator is the obvious first candidate: high impact, and in a healthy organisation genuinely needed only occasionally.

Roles used constantly are poor early candidates. If somebody activates the same role eight times a day, you have added friction without adding much security, and you have trained them to treat activation as a formality. Either the role is genuinely needed continuously — in which case question why, and consider a less privileged role — or the work should be batched.

Work outward from the control plane. Directory roles first, then Azure resource roles, then group ownership through PIM for Groups where it applies.

Activation duration

Long enough to do the work, short enough to matter. A duration that routinely forces a second activation mid-task produces frustration and workarounds; a duration measured in a full working day is close to standing access with extra clicks.

The right answer depends on the role and I would set it per role rather than tenant-wide.

Approval: use it selectively

Requiring approval for activation is a strong control and a real operational dependency. If the approver is unavailable, the work does not happen.

I would require approval for the most privileged roles, and not for the rest. Where approval is required, name a group of approvers rather than an individual, and make sure the group is large enough and distributed enough to answer out of hours. An approval requirement with one approver in one time zone is an outage waiting for a Saturday.

The approver should not be the requester. PIM allows self-approval configurations in some arrangements, and they defeat the point.

Multifactor and justification on activation

Require multifactor authentication on activation, and require a justification. Both are cheap. The justification matters less as a control than as an audit artefact — it is what makes the log readable six months later when somebody asks what happened.

Deployment

1. Run the role inventory and remove assignments that are not justified. This is worth doing on its own merits before PIM is involved at all; a large proportion of privileged assignments in most tenants are simply stale.
2. Configure emergency access accounts with permanent active assignment, and exclude them from the programme.
3. Convert one role for one pilot group, from active to eligible. Global Administrator for the identity team is a reasonable start because they can diagnose their own problems.
4. Watch a full cycle — a month, ideally including a month-end. Look at activation frequency, duration used versus duration granted, and any case where somebody could not do their job.
5. Adjust the settings from that evidence rather than from the design document.
6. Widen role by role, not all at once. Each role has a different usage pattern and deserves its own settings.
7. Enable access reviews for the eligible assignments once the population is stable.

Converting an assignment from active to eligible is the moment a person loses standing privilege. Communicate it, and be available on the day.

Validation

The evidence that PIM is working is not that it is enabled. It is:

• Standing assignments have fallen. Count permanent active assignments to privileged roles before and after. If the number has not dropped, PIM is decoration.
• Activations are happening, and are bounded. People are actually using the workflow rather than having found a way around it.
• Approvals are being answered inside the target time, where required.
• The audit log answers questions. Pick a past activation at random and see whether you can establish who, when, why, approved by whom, and what they did. If the justification field reads “work”, your justification requirement is not doing anything.
• Nobody has acquired a second, unmanaged path to the same privilege. This is the failure mode that quietly undoes the whole programme.

That last point deserves attention. If activating a role is inconvenient, people find alternatives: a service account with standing privilege, a second administrative account outside PIM, or an application with excessive permissions. Watch for all three, and treat their appearance as feedback that the activation experience is too painful rather than as a discipline problem.

Operations

Access reviews are how eligibility stays current. Schedule them per role, with a reviewer who actually knows whether the person still needs it — usually their manager or the role owner, not the identity team. Reviews that default to approve are worse than no reviews, because they manufacture evidence of governance.

Alert on activation of the highest roles. Global Administrator activation should be visible to somebody, not only present in a log.

Review the settings periodically. Activation durations and approval requirements set at deployment often turn out to be wrong, and nobody revisits them.

Keep service accounts and workload identities out of the human workflow. An unattended process cannot complete an activation. These need a different answer — a managed identity with a narrowly scoped role, or a workload identity with its own governance — rather than a permanent exemption that quietly recreates standing privilege.

Rollback

Converting an eligible assignment back to permanent active restores the previous state immediately, and it is the correct emergency action if PIM itself is preventing necessary work. Knowing that this is available, and who can do it, is part of the deployment plan.

The broader rollback — abandoning PIM — leaves you where you started, with standing privilege. That is worth stating because the usual reason for abandonment is not a technical failure but an activation experience that nobody designed.

Honest limits

PIM bounds when privilege is held. It does not bound what the privilege can do once activated, and it does not protect a session that is hijacked after activation. An attacker who compromises an eligible user’s device and waits for them to activate gets the same access they would have had.

It also does not replace the account separation in administrative tiering, nor the phishing-resistant authentication that should protect the activation itself. PIM is one layer in a privileged access design, and it is a weak one on its own.

Finally, PIM covers Entra ID roles, Azure resource roles and groups. It does not cover on-premises Active Directory privilege, which needs its own approach.

Verification and limits

Eligible versus active assignment, activation requirements, approval workflow, access reviews and the P2 licensing requirement were checked against current Microsoft documentation on 20 September 2026. The deployment sequence and the settings advice are my own practice.

No tenant configuration was performed for this article. Converting assignments from active to eligible removes standing privilege at the moment it is applied — pilot with a group that can recover its own access, verify emergency access accounts first, and confirm your licence coverage before beginning.

References

• What is Microsoft Entra Privileged Identity Management?
• Configure Microsoft Entra role settings in PIM
• Create an access review of Azure resource and Microsoft Entra roles in PIM
• Best practices for Microsoft Entra roles