Make them eligible by moving users from standing directory role assignments to PIM-managed eligibility, then requiring activation when access is needed. Set approval, MFA, justification, and time limits so the role is not always active. Validate that the user can still complete their work through activation and that permanent access is removed where policy allows.
What changes when a role is eligible instead of permanent?
An eligible role is not continuously active. The assignment exists in Microsoft Entra PIM, but the privileges only become effective after an activation step that can be constrained by policy. That changes the operational model from “always trusted” to “request, approve, activate, expire,” which is the core control shift behind standing privilege reduction.
That distinction matters because the access decision moves to the moment of need. If the role is permanent, the user can act at any time until the assignment is removed. If it is eligible, the organization can require extra checks before activation and keep the privileged state bounded to a short window.
Eligibility is most useful when the role is powerful enough that continuous exposure is unnecessary. Privileged Identity Management (PIM) Guide is the natural reference point for the difference between eligible and active assignments, because it covers activation, approval settings, alerts, and role activation workflows.
How do you move from standing assignment to PIM-managed eligibility?
The practical change is to remove the standing directory role assignment and create a PIM eligibility assignment for the same user or group. After that, define what must happen at activation time, such as MFA, justification, approval, and a maximum activation duration. The goal is to make privileged use intentional and time-bounded rather than silently available.
In Entra environments, this is often paired with role-scoped review of who really needs persistent access versus who only needs occasional elevation. The cleanest migration path is to start with the highest-impact administrator roles, confirm that the activation workflow is workable, and only then reduce standing access more broadly. Just-in-Time Access and Zero Standing Privilege Guide aligns to that migration pattern because it covers time-bound role activation and the move away from standing privilege.
When the role is tied to administrative or infrastructure control, you should also understand the surrounding access model, not just the PIM workflow itself. Active Directory and Entra ID Hardening Guide helps place PIM in the wider Entra hardening picture, where privileged groups, delegation, and attack paths all affect whether eligibility really reduces exposure.
What should you verify before and after enabling eligibility?
Verify that the user can still do the job through activation, not through hidden leftover permissions. If a person can still administer the target resource without activating the role, the migration is incomplete. Also verify that the activation policy matches the sensitivity of the role, because a weak policy can leave a privileged path functionally permanent even if the label has changed.
It is also important to check that the role scope is correct. A user who only needs a narrow administrative task should not inherit broad directory-wide power through convenience. When the role touches Azure resource access or application control, scope design becomes part of the security outcome, not just an administrative detail. Azure RBAC and Service Principals Guide is useful here because it covers role assignments, scope, and least-privilege patterns that often sit alongside Entra PIM decisions.
Validate logging and alerting as part of the rollout. The activation event should be visible enough that unusual elevation can be reviewed, and the absence of activation should mean no privileged action is possible. If the role remains materially usable without an activation trail, then the control is not doing its job.
Risk and Threat Considerations
Permanent role assignments increase blast radius because an account compromise instantly becomes privileged compromise. Eligibility reduces that exposure, but only if standing access is actually removed and activation is tightly controlled. If approval, MFA, and time limits are weak or bypassable, the user experience may look governed while the security boundary remains broad.
Failure mechanism: A privileged account or token can be abused at any time when a standing role is left in place, or when PIM eligibility still allows rapid, low-friction activation with little oversight.
Impact: Attackers gain a larger window to perform directory changes, tenant-wide administration, or privilege escalation, and defenders may lose the chance to distinguish normal use from elevation that should have been exceptional.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | PIM eligibility changes how privileged accounts are provisioned and activated. |
| IA-5 — Authenticator Management | PIM activation commonly depends on MFA and short-lived credential use for privileged access. | |
| AC-6 — Least Privilege | Eligibility implements least privilege by removing always-on administrative access. | |
| Recommendation — Limit standing privileged assignments and require controlled activation for elevated access. Enforce strong authenticators and rotate or expire privileged credentials promptly. Grant only the minimum privileged access needed and make elevation temporary. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This topic is about replacing standing privilege with managed, time-bound access. |
| Recommendation — Remove persistent admin access and enforce just-in-time elevation. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The same privilege-bounding logic applies when non-human or service identities hold standing access. |
| Recommendation — Review privileged non-human identities and remove always-on access where possible. | ||
Practitioner Guidance
What to prioritise: Start with the roles that create the highest tenant-wide or cross-system impact if abused, then convert only the truly persistent business needs to eligibility. Do not begin with low-impact roles just to prove the tooling works.
What to verify: After conversion, test the full activation path end to end, including approval routing, MFA, justification, expiration, and revocation after the window closes. If the role can still be used outside that path, treat the migration as incomplete.
Common mistake: Teams often keep a standing fallback assignment “just in case,” which defeats the point of PIM. If an exception is needed, make it explicit, time bound, and reviewed, rather than leaving permanent access in place by default.
Practitioner takeaway: The real control objective is not eligibility itself, but proving that privileged work is only possible through a deliberate activation path and that no hidden standing access remains.
Related resources from NHI Mgmt Group
- How do you detect role assignments made outside PIM in Microsoft Entra ID?
- How do you discover excessive privileged role assignments in Microsoft Entra PIM?
- How do you detect privileged role activations that don't require MFA in Microsoft Entra PIM?
- How do you create a custom role in Microsoft Entra ID?