First page of Microsoft's 100,000-partner directory, sorted by responsiveness Microsoft Solutions Partner — Security, Modern Work, Infrastructure, App Innovation Microsoft partner since 2006 1,100+ organizations under management
Home/Services/Microsoft Entra PIM and Privileged Access Hardening
ImplementationSecurity and Protection

Microsoft Entra PIM and Privileged Access Hardening

Standing Global Administrator, Exchange Administrator and SharePoint Administrator assignments are a routine finding in the Microsoft 365 tenants we audit — and Microsoft now asks the question for you: its managed Conditional Access policy that requires multifactor authentication for admins in the Microsoft admin portals, and the Baseline security mode policy that requires phishing-resistant authentication for admins, land in tenants on Microsoft's schedule. IT Partner answers it with a fixed-price, two-week engagement in one Microsoft Entra tenant: we inventory every Microsoft Entra role, Microsoft 365 admin role and privileged group assignment (permanent versus eligible, people versus service principals), agree a target role model with you, move standing assignments to eligible ones in Microsoft Entra Privileged Identity Management with role-by-role activation settings — maximum duration, MFA or a Conditional Access authentication context on activation, justification, ticket number, approval for the highest roles — put your admin groups under PIM for Groups, scope helpdesk rights with administrative units, create and test two cloud-only break-glass accounts with passkeys and sign-in alerting, switch on PIM's own security alerts, and hand over a written privileged-access procedure your administrators have already walked through. $3,950 per project, fixed, for one tenant with up to 25 administrator accounts; larger admin populations and PIM across a wide Azure estate are quoted per tenant. Microsoft Entra ID P2 or Microsoft Entra ID Governance for each administrator who holds an eligible assignment, and for each approver, is a licensing prerequisite billed by Microsoft or your CSP — not part of this fee.

Timeline 2 weeksService owner Roman SotnikMicrosoft Entra IDMicrosoft Entra ID GovernanceMicrosoft 365

What this engagement is

A Microsoft 365 tenant that grew up with a handful of permanent Global Administrators is not unusual; it is the default. Every one of those accounts is a standing path from a phished password to the whole tenant, and every auditor, cyber-insurance questionnaire and CISA SCuBA baseline now asks how many of them you have. Microsoft's answer is Privileged Identity Management: an administrator stays *eligible* for a role and activates it for a bounded window when there is work to do, proving who they are on the way in, stating why, and — for the roles that can take the tenant down — waiting for a named approver. When the window closes the privilege is gone. Microsoft's own guidance for Microsoft Entra roles is to keep Global Administrator to fewer than five people, to keep privileged role assignments under ten, and to hold zero permanently active assignments for anything other than the emergency access accounts. This engagement gets a single tenant to that state in two weeks, and it is deliberately PIM-only. We start with an inventory that most tenants have never seen in one place: every Microsoft Entra role assignment (built-in and custom, permanent and eligible, tenant-wide and scoped), every Microsoft 365 admin role that shows up through it, every role-assignable group and who sits in it, every Azure subscription Owner and User Access Administrator where you ask us to look, and every service principal or managed identity that holds an admin role — because the app registration from a project three years ago is the assignment nobody remembers. The design workshop turns that list into a role model: who genuinely needs Global Administrator (usually two or three people plus the break-glass accounts), which admins move to a least-privileged role instead, which roles get approval and by whom, and how long an activation should last for each tier. Microsoft's example settings are the sensible starting point — Global Administrator at one hour with MFA, a Conditional Access authentication context, a ticket and approval by another Global Administrator; Exchange Administrator at two hours with MFA and no approval; Helpdesk Administrator at eight hours with a ticket — and we adjust them to how your team actually works rather than copy them blindly. Before a single assignment changes we build the safety net, because PIM has a well-documented lockout: if every Global Administrator is eligible rather than active, activation requires approval, and no approver is configured, nobody can approve anyone. So the first configuration day is the two emergency access accounts, built the way Microsoft's June 2026 guidance specifies — cloud-only on your .onmicrosoft.com domain, not synchronized or federated, a passkey (FIDO2 security key) as the credential rather than the Authenticator app your other admins use, Global Administrator as a permanent active assignment, excluded from every Conditional Access policy that could block them (Microsoft's managed policies included), credentials stored under a procedure you own, and an alert on any sign-in by either account. We test both before we continue. Then the role settings go in per role, the Conditional Access policy behind the authentication context is created and enabled first (PIM falls back to plain MFA only if no policy targets the context — and not if the policy is off or report-only), your admin groups are onboarded to PIM for Groups so one activation can light up several roles at once, administrative units scope your helpdesk to the users they support, and PIM's security alerts are tuned to your numbers: how many Global Administrators is too many, how many days without activation makes an assignment stale, and who gets the email when a role is assigned outside PIM. Conversion follows Microsoft's own deployment order — Global Administrators first, as a pilot with the people who feel the change most, then Security Administrator and the rest of the privileged roles, then the workload and helpdesk roles. Standing assignments come off only after the eligible ones are proven by an activation drill. Every administrator walks through an activation with us on a call, approvers approve a real request, and the break-glass accounts are signed in one more time after the policies are enforced. What you keep is a privileged-access runbook — the role model, the activation and approval procedure, the break-glass procedure with its quarterly test, the alert responses, and the licensing dependency stated plainly — plus an inventory you can hand to an auditor. Programme-scale identity governance — access packages, lifecycle workflows, recurring access-review campaigns across applications and groups — is a different engagement, our Microsoft Entra ID Governance Implementation, and we say so at the first call rather than stretch this one.

Success criteria

01A complete, dated inventory of privileged access in the tenant exists — every Microsoft Entra and Microsoft 365 admin role assignment, role-assignable group, in-scope Azure Owner and User Access Administrator assignment, and admin-role-bearing service principal — with permanent versus eligible and owner recorded for each.
02No human account holds a permanently active privileged Microsoft Entra role except the two emergency access accounts; Global Administrator is held by the people named in the approved role model, within Microsoft's fewer-than-five guidance.
03Every in-scope role has PIM settings agreed per tier: activation maximum duration, MFA or Conditional Access authentication context on activation, justification, ticket information where chosen, approval with at least two named approvers for the highest roles, and notification recipients.
04Two cloud-only emergency access accounts sign in with a passkey, hold Global Administrator as a permanent active assignment, are excluded from every blocking Conditional Access policy, trigger an alert on sign-in, and have passed a live test after enforcement.
05PIM for Groups governs the admin groups agreed at the workshop, administrative units scope helpdesk and regional admin rights to their user populations, and — where in scope — Owner and User Access Administrator on the agreed Azure subscriptions are eligible rather than standing.
06PIM security alerts are configured with your thresholds and recipients, and the 'roles assigned outside PIM' alert has been shown to fire in the validation.
07Every administrator has completed at least one activation, every approver has approved a real request, and the privileged-access runbook — role model, procedures, break-glass test schedule, licensing dependency — has been walked through with your admins and accepted.

What you receive

Privileged-access inventory — Microsoft Entra roles (built-in and custom; permanent and eligible; tenant-wide and scoped), Microsoft 365 admin roles, role-assignable groups and their members, admin-role-bearing service principals and managed identities, and in-scope Azure subscription Owner and User Access Administrator assignments, with a licence check against the Microsoft Entra ID P2 or Microsoft Entra ID Governance requirement for each affected administrator and approver
Target role model, signed off at the design workshop — who keeps Global Administrator, who moves to a least-privileged role, which roles require approval and who approves, and the activation settings for each role tier
Two emergency access (break-glass) accounts — cloud-only on the .onmicrosoft.com domain, passkey (FIDO2) credentials registered, Global Administrator as permanent active, excluded from blocking Conditional Access policies, credentials stored under your procedure, and a sign-in alert rule through Azure Monitor on a Log Analytics workspace or Microsoft Sentinel where you already run it
PIM role settings per role — activation maximum duration, MFA or Conditional Access authentication context on activation, justification, ticket information, approval and approvers, eligible and active assignment durations, and notification recipients
Conditional Access policy for the activation authentication context — phishing-resistant authentication strength and, where your devices allow, a compliant device, with sign-in frequency set to every time so activation always re-authenticates; a second policy scoped to the directory roles where the workshop chooses it
Eligible assignments in place and standing assignments removed for every in-scope role, converted in Microsoft's recommended order (Global Administrators first as a pilot, then the remaining privileged roles), with time-bound active assignments only where a role cannot be eligible
PIM for Groups on the admin groups agreed at the workshop — role-assignable where they carry Microsoft Entra roles, with membership and ownership activation policies
Administrative units for scoped helpdesk and regional administration, with the scoped role assignments and — where wanted — dynamic membership rules
Optional: PIM for Azure resources — Owner and User Access Administrator made eligible on the Azure subscriptions agreed at scoping, with activation settings and approvers
Service principal and workload identity review — every application or managed identity that holds an admin role documented with an owner, reduced to a least-privileged role or Graph permission where the owner agrees, and time-bound where Microsoft's assignment options allow
PIM security alerts configured — too many Global Administrators, administrators not using their roles, potential stale accounts, roles that do not require MFA for activation, roles assigned outside PIM, roles activated too frequently — with thresholds and email recipients set to your numbers
Validation record and privileged-access runbook — activation drills per tier, approval test, break-glass sign-in test after enforcement, alert test; the runbook covering the role model, activation and approval procedure, break-glass procedure with its quarterly test, alert responses, onboarding and offboarding an administrator, and the licensing dependency — delivered in an admin walkthrough

How the work unfolds

Days 1–2 — Access, inventory and licence check

We take time-bound delegated access that you approve, export every role assignment, role-assignable group, PIM eligibility, service-principal role and in-scope Azure role assignment, and reconcile it against the licences in the tenant. You get the inventory as a document and a spreadsheet, with the surprises highlighted — the shared mailbox account that is a Global Administrator, the app registration with Directory.ReadWrite.All, the contractor who left.

Day 3 — Design workshop

A two-hour working session with your IT lead and whoever owns security. We agree the role model — who keeps Global Administrator, who moves to Exchange, SharePoint, User, Helpdesk or a scoped role instead — the approvers, the activation settings per tier, which admin groups go under PIM for Groups, which administrative units to create, whether Azure subscriptions are in scope, and how break-glass credentials will be stored and by whom. Decisions are written up the same day and signed off before configuration starts.

Day 4 — Emergency access accounts first

Two cloud-only accounts on your .onmicrosoft.com domain, passkeys registered, Global Administrator assigned as permanent active, a dedicated exclusion group applied to every Conditional Access policy that could block them, the sign-in alert rule created with your recipients, and a test sign-in from each. Nothing else changes until both accounts have proven they work.

Days 5–6 — PIM settings, Conditional Access context, groups and units

Role settings are configured per role from the workshop decisions. The Conditional Access policy behind the activation authentication context is created and enabled before the context is referenced in any role setting. Admin groups are onboarded to PIM for Groups, administrative units are created and populated, and — where in scope — PIM is enabled on the agreed Azure subscriptions. PIM security alert thresholds and recipients are set.

Days 7–8 — Conversion and activation drills

Global Administrators go first: eligible assignments created, each person activates on a call with us, approvers approve a real request, and only then do the permanent assignments come off. The remaining privileged roles follow, then workload and helpdesk roles, then service principals reviewed with their owners. The 'roles assigned outside PIM' alert is deliberately triggered and confirmed.

Days 9–10 — Validation, runbook and handover

Break-glass accounts are signed in again with every policy enforced. The validation record and the privileged-access runbook are delivered and walked through with your administrators in a session that doubles as their training: how to activate, how to approve, what the alerts mean, what to do when someone joins or leaves the admin team, and what happens if the Entra ID P2 or Entra ID Governance licences lapse. Our delegated access is removed and you confirm the removal.

Prerequisites

One Microsoft Entra tenant, with Microsoft Entra ID P2 or Microsoft Entra ID Governance licences available for every administrator who will hold an eligible assignment and for every approver — included in Microsoft 365 E5 (Entra ID P2) and the Microsoft Entra Suite (Entra ID Governance), or bought as add-ons; Microsoft 365 Business Premium and E3 carry Entra ID P1, which does not include PIM
A Global Administrator or Privileged Role Administrator who can approve our time-bound delegated access and who is available for the design workshop and the conversion calls
Two FIDO2 security keys (or an equivalent passkey arrangement you have already standardized on) for the emergency access accounts, and a decision on where their credentials will be kept and who may open them
Conditional Access already in use, or the willingness to have us create the small set of policies this engagement needs — Conditional Access requires Microsoft Entra ID P1 or higher; if your tenant has no Conditional Access baseline, our Conditional Access Policy Implementation is the right first step
For the sign-in alert on the break-glass accounts: an Azure subscription in the tenant to hold a Log Analytics workspace, or an existing Microsoft Sentinel workspace; the workspace's consumption is Microsoft's metered charge on your subscription
For the optional Azure scope: an Owner or User Access Administrator on each subscription in scope who can approve the change, and the list of subscriptions agreed at the workshop
Administrators available for a 15-minute activation drill each during the conversion days, and one named owner for the runbook after handover

Who does what

IT Partner

  • Produce the privileged-access inventory and licence check, and run the design workshop to a written, signed-off role model
  • Create and test the two emergency access accounts, their Conditional Access exclusions and their sign-in alert before any other change
  • Configure PIM role settings, the activation authentication-context policy, PIM for Groups, administrative units, PIM security alerts and — where in scope — PIM for Azure resources
  • Convert standing assignments to eligible ones in Microsoft's recommended order, run the activation and approval drills, and remove the permanent assignments only after each tier is proven
  • Deliver the validation record and the privileged-access runbook, walk your administrators through them, and remove our own access at the end

Your team

  • Approve time-bound delegated access for the work and name the decision-makers for the design workshop
  • Decide the role model — who keeps which role, who approves — and accept the activation settings per tier
  • Buy or assign the Microsoft Entra ID P2 or Entra ID Governance licences the inventory shows are needed, and pay Microsoft for them and for any Azure consumption behind the alerting workspace
  • Provide the FIDO2 keys for the emergency access accounts, decide where their credentials live, and own the quarterly break-glass test after handover
  • Make administrators and approvers available for their activation drills, and own the runbook after the walkthrough

What's not included

Programme-scale identity governance — entitlement-management access packages, lifecycle workflows, and recurring access-review campaigns across applications and groups — is Microsoft Entra ID Governance Implementation; this engagement is PIM for admin roles and groups only
Protected actions — binding specific high-risk Microsoft Entra permissions to a Conditional Access authentication context — is Implementation of Protected Actions in Microsoft Entra ID; the authentication-context policy we create here is a natural foundation for it
Restricting Microsoft 365 access to approved, phishing-resistant, Entra-joined devices for all users, and the mobile-access model behind it, is Trusted Device and Phishing-Resistant Access; a full Conditional Access baseline is Conditional Access Policy Implementation
On-premises Active Directory tiering, privileged-group cleanup and attack-path remediation — Active Directory Security Assessment and Hardening; where a synced on-premises account holds a cloud admin role we flag it and recommend a cloud-native admin account, per Microsoft's guidance, but we do not re-home accounts
Licences — Microsoft Entra ID P2, Microsoft Entra ID Governance and the Microsoft Entra Suite are billed by Microsoft or your CSP at Microsoft's price; we can transact them through our CSP, and the licence cost is never folded into this fee
Running PIM after handover — the monthly review of who is eligible, who is permanently active where they should not be, whose activation nobody would approve today, plus the quarterly access-review campaigns — is Managed Entra ID Identity Hygiene and Access Reviews
PIM across a wide Azure estate — many subscriptions, a management-group hierarchy, resource-group and resource-level roles — is quoted separately; the fixed fee covers Owner and User Access Administrator on the subscriptions agreed at scoping
Third-party privileged-access-management products, password vaults and session-recording tools, and integration of PIM with a ticketing system (PIM's ticket field is information-only and is not validated against any system)
FIDO2 security keys and other hardware; investigation or recovery of an already-compromised administrator account, which is Business Email Compromise Investigation and Recovery
24/7 support and ongoing monitoring; escalation to Microsoft through our Premier Support agreement is available as a paid add-on where a case needs it

Limitations & technical notes

!Licensing is the boundary that decides everything. Microsoft requires Microsoft Entra ID P2 or Microsoft Entra ID Governance for every user with an eligible or time-bound assignment to a Microsoft Entra or Azure role, every eligible member or owner in PIM for Groups, and every approver. If those licences later expire, Microsoft removes the eligible assignments and the PIM settings while permanent assignments stay — which means a lapse does not quietly re-open standing access; it locks your eligible administrators out until the licence is back or an emergency access account intervenes. The runbook says this on page one.
!The fixed fee covers one tenant and up to 25 administrator accounts — distinct human accounts holding at least one privileged Microsoft Entra or Microsoft 365 admin role at inventory, each counted once however many roles they hold; the emergency access accounts and service principals do not count. Above 25, or across several tenants, the work is quoted per tenant.
!PIM activation takes a minute and lasts up to the maximum you set (Microsoft allows one to 24 hours). For roles with permissions in SharePoint, Exchange or Microsoft Purview, Microsoft documents activation delays when the role reaches the user through PIM for Groups membership; for those roles we make the person eligible for the Microsoft Entra role directly, or make users active in the group and the group eligible for the role.
!The authentication-context control has two consequences we design around: anyone who can edit Conditional Access policies can loosen or block role activation, so Conditional Access Administrator and Security Administrator are treated as top-tier roles; and Microsoft applies a ten-minute window after a re-authentication in which further activations do not prompt again. Activation controls where a role is activated from, not where it is used afterwards — the second, role-scoped Conditional Access policy is how you require a compliant device for the whole session.
!Microsoft's managed Conditional Access policies and Baseline security mode policies arrive on Microsoft's schedule — a managed policy left in report-only is enabled no less than 30 days after it appears — and can only be edited for state and exclusions. We exclude the emergency access accounts from them and align our admin policies with them; we do not own Microsoft's timetable.
!Administrative units scope management permissions only: a scoped Helpdesk Administrator manages users inside the unit but can still read the directory like any user. Units cannot be nested, and each unit-scoped administrator needs at least Microsoft Entra ID P1.
!Service principals and managed identities can be assigned Microsoft Entra roles, but Microsoft's eligible-assignment workflow is built for users and groups; where an application must keep an admin role we document the owner, reduce it to the least privilege that still works, and time-bound it where the assignment options allow rather than promise just-in-time activation for it.
!Emergency access accounts are yours to keep alive: Microsoft's guidance is to validate them at least every 90 days and after any change in IT staff, and to store their credentials in separate, secure locations. We build the procedure and run the first test; the recurring test is a client responsibility unless it is folded into a managed service.
!Product names, admin-center paths and settings ranges on this page were checked against Microsoft's documentation in September 2026 — PIM licensing (May 2026), role settings and PIM for Groups (April 2026), emergency access accounts (June 2026), Microsoft-managed Conditional Access policies (May 2026), Microsoft Entra role best practices (June 2026). Where your tenant shows something different, the work follows your tenant.

Frequently asked questions

What does the Microsoft Entra PIM and Privileged Access Hardening service actually do?

It takes one Microsoft Entra tenant from standing administrator access to just-in-time access in two weeks. We inventory every privileged assignment, agree a role model with you, configure Privileged Identity Management role by role (activation duration, MFA or authentication context, justification, ticket, approval), onboard your admin groups to PIM for Groups, scope helpdesk rights with administrative units, build and test two break-glass accounts with passkeys and sign-in alerts, tune PIM's security alerts, convert the assignments in Microsoft's recommended order, and hand over a runbook after every administrator has done a real activation with us.

Do we need Microsoft Entra ID P2 for every user in the company?

No. Microsoft requires Entra ID P2 or Entra ID Governance for the people PIM actually governs: each user with an eligible or time-bound assignment to a Microsoft Entra or Azure role, each eligible member or owner in PIM for Groups, and each approver. Microsoft's own worked example is 14 administrators managed through PIM plus three approvers, which needs 17 licences. Our inventory on days 1–2 gives you the exact count for your tenant before you buy anything.

We are on Microsoft 365 Business Premium or E3. Can we still do this?

Yes, with add-on licences for the administrators only. Business Premium and E3 include Microsoft Entra ID P1, which covers Conditional Access and administrative units but not PIM. You add Microsoft Entra ID P2 or Microsoft Entra ID Governance for the admins and approvers the inventory identifies — typically a handful of seats, not the whole company. Microsoft 365 E5 includes Entra ID P2, and the Microsoft Entra Suite includes Entra ID Governance. We can transact any of them through our CSP; the licence cost is Microsoft's and is not part of the project fee.

What happens to our existing Global Administrators?

They keep the role if the role model says they need it, but as an eligible assignment they activate for a bounded window with approval, rather than as a permanent one. Microsoft's guidance is fewer than five Global Administrators; most tenants we work with land on two or three people plus the two break-glass accounts. Everyone else moves to the least-privileged role that covers their actual work — Exchange, SharePoint, User, Helpdesk, Intune or a scoped role — and those roles are eligible too, with lighter activation settings.

Will this slow our IT team down?

Activation takes about a minute — pick the role, satisfy the MFA or authentication-context check, type a reason — and lasts up to the maximum set for that role, which Microsoft allows to be anywhere from one to 24 hours. The friction is deliberately unequal: Global Administrator gets a short window and approval, workload roles get a longer window and no approval, and a helpdesk role can run a whole shift. PIM for Groups lets one activation light up several roles at once for people who wear more than one hat.

What are break-glass accounts and why two of them?

Emergency access accounts are the way back in when normal administration fails — an identity-provider outage, every admin's MFA device unavailable, or the PIM lockout where all Global Administrators are eligible and nobody can approve. Microsoft's guidance is two or more, cloud-only on the .onmicrosoft.com domain, with a phishing-resistant credential that differs from what your other admins use (a FIDO2 passkey is the recommendation), Global Administrator as a permanent active assignment, exclusion from every Conditional Access policy that could block them, an alert on every sign-in, and a test at least every 90 days. Two, so that one lost key or one unavailable custodian does not leave you with none.

Microsoft says MFA is mandatory now. Do the break-glass accounts comply?

Yes. A passkey (FIDO2 security key) or certificate-based authentication satisfies Microsoft's mandatory multifactor authentication requirement on its own, which is exactly why Microsoft recommends those methods for emergency access accounts rather than a password with an exclusion. The accounts are excluded from Conditional Access policies that could block them, not from strong authentication.

Microsoft has started pushing Conditional Access policies for our admins. How does this fit?

Those are the trigger for most of the conversations we have about this service. Microsoft's managed policy requires multifactor authentication for admins accessing the Microsoft admin portals, and the Baseline security mode policy in the Microsoft 365 admin center requires phishing-resistant authentication for admins; a managed policy left in report-only is enabled by Microsoft no less than 30 days after it appears. We keep them on, exclude the emergency access accounts from them, and build the PIM activation policy to the same phishing-resistant standard so an administrator meets one consistent bar everywhere.

Do you cover our Azure subscriptions as well?

Optionally, yes. PIM for Azure resources makes Owner and User Access Administrator eligible rather than standing on the subscriptions we agree at scoping, with the same activation settings and approvers. Microsoft's recommendation is to protect at least Owner and User Access Administrator on every subscription and to bring the roles inside critical subscriptions under PIM; a wide Azure estate — many subscriptions, a management-group hierarchy, resource-level roles — is a separately quoted piece of work.

What about service accounts and applications that hold admin roles?

They are in the inventory, and they are usually the finding that surprises people most — an app registration with Directory.ReadWrite.All or an automation account that is a Global Administrator. For each one we document an owner, reduce it to the least-privileged role or Microsoft Graph permission that still does the job, and time-bound the assignment where Microsoft's options allow. Microsoft's eligible-assignment workflow is built for users and groups, so we do not promise just-in-time activation for an application; we make its standing access smaller, owned and visible.

What happens if our Entra ID P2 licences lapse later?

Microsoft removes the eligible assignments and the PIM settings while leaving permanent assignments alone — so your eligible administrators lose the ability to activate until the licence is restored, and the emergency access accounts are the way in. That is why the runbook states the licensing dependency on its first page, why the break-glass accounts are permanent active, and why we recommend that licence renewal for admin seats is owned by a named person.

How is this different from your Microsoft Entra ID Governance Implementation?

Scope and price. This engagement is PIM-only — admin roles, admin groups, break-glass, alerts — at a fixed $3,950 for up to 25 administrator accounts. Microsoft Entra ID Governance Implementation is the broader programme: entitlement-management access packages, lifecycle workflows for joiners and leavers, recurring access reviews across applications and groups, with PIM as one capability among several, and it is quoted from $6,950 on the scope. If you need the programme, we tell you at the first call and you get one project instead of two.

Who runs PIM after you leave?

You do, with the runbook — activation and approval, onboarding and offboarding an administrator, the alert responses and the quarterly break-glass test are written for the people who will do them. If nobody on the team has time to review eligibility every month and run access-review campaigns, Managed Entra ID Identity Hygiene and Access Reviews takes that over for a monthly per-user fee and begins where this project ends.

What access do you need, and how do we know it is gone afterwards?

Time-bound delegated access that you approve — our published policy is granular GDAP rather than standing Global Administrator — with Privileged Role Administrator for the PIM work and, where Azure is in scope, User Access Administrator on the agreed subscriptions. The last item in the handover is removing that access and showing you the audit log entry that proves it.

How does pricing work?

$3,950 per project, fixed, quoted in writing before work begins, and you pay after you approve delivery. It covers one Microsoft Entra tenant with up to 25 administrator accounts, PIM for Groups on the admin groups agreed at the workshop, administrative units, two emergency access accounts, PIM alerts and the runbook, plus PIM for Azure resources on the subscriptions agreed at scoping. Larger admin populations, additional tenants or a wide Azure estate are quoted per tenant. Microsoft's licences and any Azure consumption behind the alerting workspace are billed by Microsoft or your CSP and are not part of the fee.

Didn’t find your question?

Ask it here. A real engineer answers by email within one business day — and if it’s a good one, it becomes part of this page so the next person finds it.

Answered by a person, one time, to your inbox. Nothing you type here is published without a human reviewing and anonymizing it first.

Often combined with

$3,950 per project
2 weeks
Get the fixed quote