Setting up Privileged Identity Management, step by step — with the 7 traps that break a PIM rollout

Privileged Identity Management is the control that turns permanent administrative rights into rights somebody has to ask for, with a reason, for a limited period, and with a record. It is the practical answer to the Essential Eight expectation that administrative privileges are restricted and validated rather than assumed, and it is the control an APRA CPS 234 information security review will look for evidence of.

It is also the control most likely to be turned on badly. A PIM rollout that has not been sequenced produces one of two outcomes: an administrator locked out of a tenant at the worst moment, or a set of eligible assignments layered on top of the permanent ones that were never removed, which is theatre. Below is the sequence that avoids both, followed by the seven traps that account for nearly every PIM deployment we have been asked to repair.

Step 1 — Confirm the licences, including the ones people forget

PIM requires Microsoft Entra ID P2, which is included in Microsoft 365 E5 and available as an add-on, and is also carried by Microsoft Entra ID Governance and the Entra Suite. The part that catches organisations out is scope: the requirement is not one licence for the administrator who configures the feature. Users who are eligible for a role, users who activate one, users nominated as approvers, and users who perform access reviews all fall inside the licensed population.

Count that population honestly before the project starts. A 400-person Australian organisation might have 14 people in scope once approvers and reviewers are counted, and that is a very different conversation with the business than the four names on the IT team.

Step 2 — Establish who can administer PIM itself

The first person to use PIM in a tenant is automatically assigned the Security Administrator and Privileged Role Administrator roles, and from that point managing role assignments for other administrators requires Privileged Role Administrator or Global Administrator. This is worth doing deliberately rather than by accident, because whoever clicks first inherits it.

Assign Privileged Role Administrator to at least two named people. One is a single point of failure on the control whose entire purpose is removing single points of failure.

Step 3 — Inventory the standing privilege you actually have

Before changing anything, produce the list. PIM's discovery and insights view surfaces the privileged roles in the tenant and how many permanent assignments each carries, which is usually the moment the number becomes a conversation with the executive rather than a task on a board.

1. 1List every account holding a privileged Entra role today, permanent or otherwise, with the human it belongs to.
2. 2Separate the accounts that are not humans: service accounts, integration accounts, the account the old MSP left behind, the account named after a product.
3. 3Note where a person holds Global Administrator because it was easier than working out the specific role they needed. Microsoft's own guidance is to keep the number of Global Administrators small and use least-privileged roles; almost every inherited Australian tenant has more than it needs.
4. 4Record the date each assignment was made and by whom, where the audit log still reaches. Assignments nobody can account for are the ones to remove first.
5. 5Write the list down outside the portal. It is the before picture, and in six months it is the evidence that the control did something.

Step 4 — Protect the emergency access accounts before anything else moves

Emergency access accounts — break-glass accounts — exist for the scenario where normal administrative access is impossible: an outage, a federation failure, the last Global Administrator leaving. They are the exception to everything else in this guide, and they have to be sorted before you begin removing standing privilege.

• Use them only for genuine emergency or break-glass scenarios where normal administrative accounts cannot be used.
• Do not connect these accounts with any employee-supplied device, such as a phone. That is what makes them survive the departure of a person or the loss of a device.
• Watch the Conditional Access interaction carefully. If an emergency access account is subject to a policy requiring multi-factor authentication, a compliant device or another control, the account can be unusable during exactly the outage it exists for. Report-only policies do not block access and do not need to exclude emergency accounts.
• Monitor sign-ins on these accounts and trigger notifications to other administrators, using Azure Monitor, Microsoft Sentinel or equivalent, so that a use is verified as either a test or a real emergency.
• Consider a privileged access workstation for the sessions where these accounts are used.

Step 5 — Decide which roles go just-in-time, and in what order

Not every role should move at once, and not every role should move at all. Sequence by consequence.

1. 1Global Administrator first. It is the highest-consequence role and the one with the most unjustified standing assignments in a typical tenant.
2. 2Then the roles that can escalate to it or read everything: Privileged Role Administrator, Privileged Authentication Administrator, Security Administrator, Application Administrator, Cloud Application Administrator, User Administrator.
3. 3Then the workload administrators: Exchange, SharePoint, Teams, Intune. These are the roles people use daily, so the activation experience has to be smooth before you touch them.
4. 4Then the read-only and reporting roles, if at all. Putting a Global Reader behind an approval workflow adds friction without reducing meaningful risk.
5. 5Leave the roles held by non-human accounts out of this sequence entirely. They need a different answer, covered in trap 6.

Step 6 — Configure the role settings before assigning anybody

Role settings are per role, and they are what makes an eligible assignment mean something. Set them first, so the pilot group experiences the finished design rather than a moving target.

• Activation maximum duration. Long enough for the work, short enough that it is not standing privilege with extra steps. Match it to how the role is actually used rather than to a round number.
• Require multi-factor authentication on activation. This is the setting that makes a stolen session useless for privilege escalation.
• Require justification, and require ticket information where the organisation runs a service desk with change records. Justification text is what an auditor reads.
• Require approval, and name the approvers, for the highest-consequence roles. Read trap 4 before applying this to a role someone might need at 3am.
• Assignment duration. Decide whether eligibility itself expires, and for which roles. A contractor who is permanently eligible for Exchange Administrator is still an open door, just a quieter one.
• Notification recipients. Route activation and assignment notifications to a monitored destination rather than to the person who performed the action, who already knows.

Step 7 — Convert permanent assignments to eligible, and remove the permanent one

This is the step that delivers the control, and the step most often left half-done. For each person in the inventory: create the eligible assignment, have them activate it once successfully, and then remove the permanent assignment. All three, in that order, per person.

Do it in waves rather than in a single change window, and keep the inventory from step 3 open as a checklist with a column for the removal. The removal column is the deployment. Everything else is preparation.

Step 8 — Pilot with the people who can diagnose it

Run the IT team through it first, for a fortnight, before extending to anyone whose day is not spent in these consoles. Two things surface in that fortnight and both are cheaper to fix while the population is four people.

• The activation-to-effect delay. Some portals and some tooling do not reflect a newly activated role immediately, and people need to know that rather than raising a ticket about it.
• The workflows that quietly assumed standing privilege — a scheduled script, a PowerShell module someone runs weekly, an integration that authenticates as a named administrator. These break silently, and they break at the point the permanent assignment is removed rather than when the eligible one is created.

Step 9 — Extend to Azure resource roles and PIM for Groups

Entra roles are the first half. Azure resource roles — Owner and Contributor on subscriptions and resource groups — are frequently the more dangerous half in organisations running production workloads in Azure, and PIM governs them the same way.

PIM for Groups covers the remainder. Where a permission is not an Entra role or an Azure role but is granted through group membership, making the membership itself eligible rather than permanent puts it behind the same gate. That is the mechanism for putting just-in-time access around application-specific administration, licence-bearing groups and privileged access groups that PIM cannot manage directly.

Step 10 — Turn on alerts and access reviews, then write the runbook

PIM raises alerts about the conditions that erode it — roles being assigned outside PIM, an excessive number of highly privileged administrators, privileged accounts that never activate anything. Configure them and route them somewhere a human reads, or the tenant drifts back to where it started within a year.

Then set up access reviews for the privileged roles on a defined cycle, so the eligible list is confirmed by someone accountable rather than accumulating. Quarterly is the cadence most Australian mid-market organisations can actually sustain, and a sustained quarterly review is worth more than an annual one that gets deferred.

Finally, write the activation runbook and put it where somebody under pressure will find it: how to activate, how long it lasts, who approves, what to do when the approver is unreachable, and how to get into the tenant if PIM itself is the thing that is broken. A control nobody can operate at 2am is a control that gets bypassed at 2:05am.

The 7 traps that break a PIM rollout

1. Licensing the administrator, not the population

The licensed population includes the people eligible for roles, the people who activate them, the approvers and the access reviewers. Budget built on the size of the IT team gets revised upward mid-project, usually in front of a finance manager who was told the number last month.

2. Pulling the emergency access accounts into the model

Break-glass accounts exist for the moment the normal path fails. Putting them behind just-in-time activation, an approval workflow, or a Conditional Access policy requiring multi-factor authentication or a compliant device means the recovery mechanism depends on the systems that are down. This is the trap with the worst consequences and it is entirely avoidable by doing step 4 first.

3. Adding eligible assignments and never removing the permanent ones

The most common finding in a PIM review. Everyone is eligible, the reports look excellent, and every one of them also still holds the role permanently, so nobody has ever needed to activate. The control has cost money and changed nothing. Track removals, not eligibility.

4. Requiring approval with nobody awake to approve

Approval on Global Administrator is a good idea, and it becomes an outage the first Sunday the only approver is on a flight. Name at least three approvers, spread across time zones or on-call arrangements, and be explicit in the runbook about the path when none of them respond. If the honest answer is that approval cannot be staffed out of hours, use justification and short duration instead, and say so in the design.

5. Making Global Administrator the only thing anyone is eligible for

If the only eligible assignment on offer is the most powerful role in the tenant, then every routine task activates it, and just-in-time Global Administrator becomes a daily event. That is not least privilege, it is a slower form of standing privilege. Do the work of mapping people to the specific roles they use — Exchange Administrator, User Administrator, Intune Administrator — so activation of the top role becomes rare enough to be noticeable.

6. Forgetting that service accounts cannot click Activate

Scripts, integrations, backup tools and monitoring agents authenticate without a human, and they cannot activate an eligible role. Remove the standing privilege behind one and the automation stops, usually at a time that makes it look like an unrelated failure. Identify these accounts during step 3, move them to app registrations with scoped permissions and workload identity governance, and handle them as a separate stream of work rather than discovering them during the cutover.

7. No alerting and no review, so the tenant drifts back

Privilege re-accumulates. A vendor needs access for a project, an assignment is made directly in Entra rather than through PIM, an eligibility that was meant to last a fortnight has no expiry. Without the PIM alerts routed somewhere and an access review on a real cadence, the tenant looks like it did before the project inside twelve months, and the difference is that everyone now believes the problem is solved.

What this is evidence for, in an Australian context

Restricting administrative privileges is one of the eight mitigation strategies in ASD's Essential Eight, and it is assessed on whether privileged access is limited, validated and revalidated rather than on whether a product is installed. PIM produces exactly the artefacts that assessment asks for: a list of who is eligible, a record of each activation with justification, an approval trail, and a periodic review signed by an accountable person.

For APRA-regulated entities, CPS 234 requires information security controls to be commensurate with the criticality and sensitivity of the assets they protect, and it expects those controls to be tested and internally audited. A just-in-time model with activation logs and quarterly access reviews is a materially easier thing to evidence to an internal audit function than a spreadsheet asserting that the six people with Global Administrator all still need it.