Entra ID P2 arrives in most Australian organisations as a side effect. Somebody moves to Microsoft 365 E5, or buys the Entra Suite, and the tenant quietly acquires Identity Protection, Privileged Identity Management and privileged role access reviews. Six months later none of it is configured, because nothing in the tenant prompts you to configure it and everything keeps working.
This is the configuration list, in the order the steps should happen. It assumes the licence is already held and the question is what to do with it — not whether to buy it. Ninety days is a realistic window for a mid-market tenant that is doing this alongside normal work.
1. Build the sign-in risk policy in Conditional Access, in report-only
Sign-in risk is Identity Protection's assessment that a specific authentication attempt is not the legitimate user: an anonymous IP address, atypical travel, unfamiliar sign-in properties, an anomalous token. The policy targets the sign-in rather than the account.
Microsoft's current guidance is to build risk policies inside Conditional Access rather than in the older standalone Identity Protection policy blades, because that is where you can combine risk with everything else — device state, location, application, authentication strength. Create it in report-only mode, leave it there for a fortnight, and read what it would have done before it does anything.
2. Add the user risk policy with a secure password change
User risk is the assessment that the identity itself is compromised — most commonly because credentials for it have appeared in a leak. The correct response is not simply to block: it is to require a secure password change, which remediates the risk and dismisses it automatically once complete.
That only works if self-service password reset is deployed and users are registered for it. Where it is not, a user risk policy produces a queue of locked-out staff and a service desk that learns to hate the control within a week.
3. Configure the self-remediation path before you enforce anything
Both risk policies depend on the user being able to prove who they are and fix the problem without a phone call. That means multi-factor authentication registration and self-service password reset registration have to be complete for the population in scope before enforcement.
- 1Deploy the registration campaign or the registration policy so users are enrolled in strong authentication methods, and confirm coverage rather than assuming it.
- 2Confirm self-service password reset is enabled, and for hybrid tenants confirm password writeback so the change reaches on-premises Active Directory.
- 3Check registration coverage for the groups that are always the exception: executives, field staff without a corporate mobile, shared accounts, and anyone still on a method you are trying to retire.
- 4Only then move the risk policies out of report-only.
4. Set the risk levels deliberately, starting at high
Risk levels are Microsoft's confidence that the detection is real, not a measure of how bad the outcome would be. High-confidence detections are few and are worth acting on immediately. Medium is where the volume lives and where the false positives live with it.
Start with high risk only, for both policies. Run it for a month, see the volume the organisation actually produces, then decide whether to extend to medium. An Australian organisation with staff who travel, or with a lot of mobile access from consumer networks, generates more medium-risk detections than one where everyone works from two offices — which is exactly why the setting should be chosen from your own data rather than from a recommended default.
5. Route the risk signal to somewhere a human reads
Identity Protection produces a risky users report, a risky sign-ins report and a risk detections report, plus alerting for users flagged at risk and a weekly digest. None of that is useful if it is landing in the mailbox of whoever set the feature up.
- Send the users-at-risk alert to a monitored queue rather than an individual, at the risk level you have decided to act on.
- Turn the weekly digest on and give it an owner. It is the artefact that shows trend rather than incident, and it takes five minutes to read.
- Agree who dismisses risk, and on what basis. Risk that is dismissed casually trains the tenant to be wrong; risk that is never dismissed leaves a permanently red dashboard nobody trusts.
- Feed the detections to Microsoft Sentinel if it is in play, so identity risk sits next to endpoint and email signal instead of in a separate console.
6. Rehearse with simulated detections before you enforce
Microsoft documents how to simulate risk detections — an anonymous IP address sign-in through Tor, an unfamiliar sign-in properties detection, a leaked credentials scenario — so you can watch the policy fire in a controlled way.
Do this on a test account before enforcement, and do it again after any material change to the policy set. It is the difference between believing the control works and having seen it work. It also gives the service desk a rehearsal of the user experience they will be supporting.
7. Turn on Privileged Identity Management for Entra roles
This is the highest-value thing P2 unlocks and the one that takes the longest, so start it in parallel with the risk work rather than after it. The short version: inventory the standing privilege, protect the emergency access accounts first, configure role settings before assigning anybody, then convert permanent assignments to eligible and remove the permanent one.
The removal is the deployment. A tenant where everyone is eligible and everyone still holds the role permanently has bought the licence and changed nothing. Our step-by-step PIM guide covers the full sequence and the traps that break it.
8. Extend PIM to Azure resource roles and to groups
Entra roles are the obvious half. In organisations running production workloads in Azure, standing Owner or Contributor on a subscription is frequently the more consequential exposure, and PIM governs those roles the same way.
PIM for Groups covers what is left: where a permission is granted through group membership rather than through a role, making the membership itself eligible puts it behind the same activation gate. That is how you get just-in-time access around application administration and privileged access groups that PIM cannot manage directly.
9. Run an access review of the privileged roles
Once PIM holds the eligible assignments, create an access review of the privileged Entra roles and the Azure resource roles from within it. Reviews of privileged roles created in PIM are the capability to start with; broader access review scenarios across groups and applications fall under Microsoft Entra ID Governance licensing, so check the licensing table before scoping those into the same project.
- Set a cadence the organisation can sustain. A quarterly review that happens beats an annual review that gets deferred twice.
- Name a reviewer who is accountable for the answer — usually the role owner or the manager, not the IT team that made the assignment.
- Decide the default for no response before you start. Removing access on no response is the honest setting; leaving it in place turns the review into paperwork.
- Keep the output. The completed review is the evidence an auditor, an insurer or an APRA-regulated client will ask for, and it is worthless if it only exists in the portal for 30 days.
10. Baseline the Identity Secure Score and set the cadence
Record the identity score and the counts that matter — permanent privileged assignments remaining, users registered for strong authentication, risky users outstanding — on the day the ninety days ends. Those numbers are what makes the next review a comparison rather than an opinion.
Then fix the rhythm: risk queue reviewed weekly, privileged role review quarterly, policy set and exclusions reviewed twice a year. P2 is not a project with a completion date. It is a set of controls with an operating cost, and the organisations that get value from it are the ones that budgeted for the operating cost rather than the licence.
What P2 does not include, so you do not plan on it
Three assumptions cause scope problems in the second month of these projects, and all three are licensing boundaries rather than technical ones.
- Advanced identity governance — entitlement management access packages and lifecycle workflows — is licensed under Microsoft Entra ID Governance or the Microsoft Entra Suite, with only some capabilities operating on a P2 subscription. If the plan for contractor onboarding depends on access packages, confirm the licence position against Microsoft's governance licensing table before committing dates.
- Risk detection for workload identities — the service principals and applications that authenticate without a human — is licensed separately again. Assuming it comes with P2 is a common way to end up with a governance gap on exactly the identity class that has no MFA to fall back on.
- On-premises Active Directory. Everything above governs Entra and Azure. A hybrid organisation still needs a tiered administration model on the domain side, and Defender for Identity is the product that watches it.
What this is evidence for in Australia
Two of the eight mitigation strategies in ASD's Essential Eight land directly here: multi-factor authentication, and restricting administrative privileges. Maturity in the second is assessed on whether privileged access is limited, validated and revalidated — which is a description of steps 7 through 9.
The other driver is what happens after an incident. Under the Notifiable Data Breaches scheme an entity must assess a suspected eligible data breach expeditiously, and identity telemetry is often what establishes whether a compromised account did anything. A tenant with risk detections retained, activation logs from PIM and a completed access review can answer that question in days. A tenant without them notifies broadly, because it cannot prove the narrower answer.