PIM in Microsoft 365: Why Standing Admins Are Your Biggest Gap

The control nobody audits

An important security control is reducing standing privilege and requiring justified activation where the role supports it:

The standing administrator.

The Global Administrator account assigned 18 months ago, which nobody reviews anymore, which is active 24/7, which has MFA but no JIT (Just-In-Time), and which a single successful phishing message can convert into a tenant-wipe in under five minutes.

This is not a hypothetical exposure: a permanently active role increases the blast radius of a compromised account. NIST CSF 2.0 and ISO/IEC 27001:2022 support access control and least privilege, but do not by themselves make every standing assignment non-compliant.

Why this changed in the last 24 months

Until recently, "the Global Admin has MFA" was considered enough. Not anymore.

The regulatory trigger

• NIST CSF v2.0 (published Feb 2024): the Protect function now requires separation of identity from privilege. Authorization must be temporary, justified and audited — not permanent.
• ISO/IEC 27001:2022 Annex A 8.2: privileged access rights. Requires on-demand assignment with documented periodic review. Annual list-of-admins reviews no longer qualify.
• CNBV Circular Única de Bancos: for Mexican financial institutions, segregation of privileged duties is mandatory. A standing Global Admin is by definition incomplete segregation.
• LFPDPPP Art. 18: requires administrative, technical, and physical measures that consider factors including risk and possible consequences for data subjects. PIM can support least privilege; the law does not prescribe PIM or declare every standing assignment unlawful.

The other half: operational reality

It's not only regulatory. The real victims of the attacks that make headlines — from Lapsus$ to the double-extortion ransomware that hit Mexican companies in 2024-2025 — share one trait: the attacker obtained a Global Admin token and used it as a master key. In every one of those cases, if the admin had been PIM-eligible instead of permanently active, the kill chain would have stopped at activation.

How Privileged Identity Management works

Microsoft Entra Privileged Identity Management (PIM) shifts the model from "assigned role" to "eligible role":

1. Eligible assignment: the user is authorised to ASSUME the role, but doesn't have it active.

2. On-demand activation: the user requests the role when needed. The request can require MFA, written justification, an associated ticket, and approval from another admin.

3. Bounded duration: activation lasts a defined window — typically 1–8 hours, after which the role automatically deactivates.

4. Full audit: every activation is recorded with timestamp, justification, IP, device and session ID.

The result: an attacker who steals an eligible Global Admin's credentials gets no power. They get the ability to REQUEST power — which triggers MFA, justification and possible approval — and in the process triggers the detection alerts.

The 7 roles that should not be active today

Not every administrative role needs the same treatment. These seven warrant immediate conversion to eligible:

1. Global Administrator — total tenant control. Permanent access is never justifiable.

2. Privileged Role Administrator — can assign other privileged roles. Permanent equals a key that multiplies the keys.

3. Security Administrator — manages security policies. If compromised, can disable the detection that would catch the compromise itself.

4. Exchange Administrator — full mailbox access. Permanent means undetectable silent exfiltration.

5. SharePoint Administrator — full document access. Same risk, different repository.

6. User Administrator — can create, modify and disable accounts. Permanent means silent backdoor creation.

7. Conditional Access Administrator — defines MFA and device rules. Permanent means the doorman can open the door at will.

Break-glass accounts: the exception you actually defend

There is one legitimate case for a permanent admin: the emergency (break-glass) account. If PIM, MFA or the directory fail, someone has to be able to enter the tenant to restore service. This account:

• Is cloud-only (not synced from on-premises AD).
• Has long credentials, stored physically in a safe.
• Is excluded from the Conditional Access policy requiring MFA, because the scenario it exists for is precisely when MFA isn't working.
• Triggers an automatic alert to CISO + CEO every time it's used.
• Rotates every six months.

Maintaining two break-glass accounts per tenant is the standard practice. Documenting them explicitly in the risk register is what separates an audited exception from a forgotten admin.

30-day implementation without breaking operations

Converting 8–15 standing admins to eligible sounds risky. Done methodically, it isn't:

Week 1: discovery

• List every active PIM > Microsoft Entra role assignment.
• Identify who uses each role weekly vs. monthly vs. never.
• Document existing break-glass accounts (they typically exist, without a formal label).

Week 2: model configuration

• Configure role settings: 8-hour activation max, mandatory MFA, mandatory justification, approval required for Global Admin.
• Create the approver group (minimum 2 people, ideally CISO + CEO or CISO + IT lead).
• Enable notifications to approvers and the security team for every critical-role activation.

Week 3: pilot

• Convert 2–3 low-impact admins (User Administrator, SharePoint Administrator) to eligible.
• Collect operational feedback for 5 business days.
• Adjust max activation duration if operations justify it.

Week 4: tenant-wide cutover

• Convert the 7 critical roles to eligible for every user except the 2 break-glass accounts.
• Communicate the change to IT 72h in advance.
• Run a dry-run with each admin: activate the role, perform a typical task, deactivate.

By day 30 the model is live in production.

Common traps

Privilege creep

After 3–6 months, someone approves permanent activations "to avoid interruptions." In 12 months you're back where you started. Quarterly review of eligible assignments is mandatory, not optional.

Service accounts

Some integrators solve automation needs with a service Global Admin "because PIM can't be enabled on a non-human account". That's false: use Managed Identities or service principals with least-privilege, never a human service identity.

MFA bypass via exclusions

If the Conditional Access policy excludes corporate IP ranges from MFA, PIM activation from the office won't require MFA. The attacker who enters via VPN is inside that range. Conditional Access must require MFA on every activation, with no network exclusions.

False reporting

"Everything is fine" reports in some security dashboards only show whether roles have MFA, not whether they're eligible vs active. If your compliance report says "100% MFA" and you have permanent admins, the report is measuring what doesn't matter.

Measuring success

Three metrics, reviewed monthly:

1. Eligible activations vs permanent assignments: target = 0 permanent (except documented break-glass).

2. Average activation time: if the average exceeds 4 hours, the model is being used to bypass the control. Investigate.

3. Activations without documented justification: target = 0. If the justification field is empty on an activation, that account shouldn't have the eligible role.

Implementation checklist

• [ ] Standing-admin inventory documented (includes the forgotten ones)
• [ ] PIM model configured with MFA + mandatory justification
• [ ] Approvers assigned and trained (minimum 2 people)
• [ ] 2 break-glass accounts formally labeled and rotated
• [ ] All 7 critical roles converted to eligible for every human user
• [ ] Service principals with least-privilege for automations (not human admins)
• [ ] Conditional Access requires MFA on every activation, no network exclusions
• [ ] Quarterly eligible-assignment review on the calendar
• [ ] Global Admin activation alerts routed to CISO + CEO
• [ ] Monthly activation metrics reported to the security committee

First step: know your gap

Before installing anything, you need to know how many standing admins you have today and which roles are at risk. Our free scan evaluates the 155 Microsoft Graph rules of the 201-rule library — including privileged accounts, PIM configuration and Conditional Access policies — and delivers the verdict in minutes. The 46 Azure Resource Manager controls add on with admin consent.

Scan your tenant free →

---

Sources cited in this article:

• NIST Cybersecurity Framework v2.0 (NIST IR 8531, 2024) — Protect function, PR.AC-4 category
• ISO/IEC 27001:2022 Annex A 8.2 — Privileged access rights
• CNBV Circular Única de Bancos — Chapter IV, segregation of duties
• LFPDPPP (Mexico), Art. 18 — Security measures for personal data
• Microsoft Entra Privileged Identity Management — official documentation