Privileged Identity Management: How a Two-State Role Assignment Retired Standing Admin

1. The Tenant with Zero Standing Global Administrators#

At 14:03:01 on a Tuesday in 2026, alice@contoso.com became Global Administrator of her company's Microsoft Entra tenant. At 15:03:01 the same day, she stopped being one. In between, she restored a deleted user, exported an audit log, and produced a single PIM record: Justification reads "incident MSRC-2026-PIM-12345, ticket SNOW-INC-987654"; Approver reads "bob@contoso.com (decided 14:02:17)"; ActivatedAt and ExpiredAt differ by exactly PT1H. The SOC 2 auditor signed it off without follow-up questions.

The 2015-vintage version of the same tenant looked nothing like this. Twelve standing Global Administrators. No multifactor challenge at privilege use. No approval workflow. No justification field. No audit trail beyond ordinary sign-in logs. A single phish of any one of those twelve identities was tenant takeover. The math required no sophistication: the attack surface for "Global Administrator of contoso.com" equalled the union of twelve personal attack surfaces, indefinitely.

What changed between the two tenants is not a habit, not a policy, not a culture shift. It is a single field on a single object inside Microsoft Entra ID.

Standing admin was never a deliberate design decision. It was the only deployment posture a single-state role-assignment object could produce. Once Microsoft made the role-assignment object two-state, JIT admin became expressible -- and standing admin became visibly the anti-pattern it had been since 1975.

To explain that field, and to explain why it took fifty-one years to ship, we start where the principle did: a 1975 paper by two MIT researchers who knew what privilege should look like but had no mechanism to enforce it.

2. The Default Wasn't a Decision#

Who designed the standing Domain Admin pattern? No one. It was the only assignment category Active Directory shipped with.

A forty-year deployment posture with no author. That is the first thing to internalize. Standing admin is what happens when a data model offers exactly one assignment category and operators still have real work to do. Every later "best practice" was an attempt to talk operators out of the one tool they had been given.

1975: The principle without a mechanism#

In September 1975, Jerome Saltzer and Michael Schroeder published The Protection of Information in Computer Systems in the Proceedings of the IEEE ^[1]. The paper is a survey of secure-systems design, organized around eight named design principles that the authors crystallized from work on Multics and other early protected operating systems. Both authors were affiliated with MIT's Project MAC and the Department of Electrical Engineering and Computer Science ^[2].

The sixth principle, named Least Privilege, is the one every later JIT-admin product cites:

"Every program and every user of the system should operate using the least set of privileges necessary to complete the job." -- Saltzer & Schroeder, The Protection of Information in Computer Systems, 1975, Design Principle (f), the sixth of eight ^[1]

Read the principle carefully. It does not say "every user should hold the least set of privileges." It says they should operate using the least set of privileges. The two formulations look identical until you ask what a person does between bursts of administrative work. A user who holds the privilege "permanently active" is operating using it permanently, whether they touch the system or not. The 1975 paper points at the temporal dimension and walks past it. The worked examples cover static mechanisms -- protection rings, access control lists, capability tickets -- not time-bounded ones. The principle was correct. The mechanism did not yet exist.

For the next forty years, every approximation tried to compensate. UNIX sudo (1980) bound elevation to a single command. Kerberos delegation (1988) bound impersonation to a ticket. Windows DACLs and Active Directory groups (1993 and 2000) bound access to a static membership list. None made temporal least privilege a first-class data-model property. None let an operator say "I am eligible to be Domain Admin, but I am not Domain Admin right now."

2000-2013: Group membership as a boolean#

When Active Directory shipped with Windows 2000 on February 17, 2000 ^[3], privileged access was structurally a boolean property of the principal. A user was either a member of BUILTIN\Administrators, Domain Admins, Enterprise Admins, or Schema Admins, or they were not. The membership lived in the directory as the member attribute on the group object (and the memberOf back-link on the user). It was set when assignment was made, unset when an administrator manually revoked it. No third state. No attribute could hold one.

Kerberos's Privilege Attribute Certificate -- the PAC -- carried the user's group SIDs forward into every Kerberos ticket the user obtained. The Privilege Attribute Certificate is the data structure inside a Kerberos ticket that lists the user's group SIDs. Pre-2016 Active Directory had no per-membership TTL metadata in the PAC. There was nowhere in the existing schema to put an expiry timestamp, which is why on-prem JIT membership later required a separate forest rather than an in-directory mechanism. A ticket's lifetime was bounded; the SID set inside it was not. There was no per-membership TTL anywhere in the system. If you wanted "Alice is Domain Admin between 14:00 and 15:00 today and not otherwise," the directory had no machinery to express it. Alice was Domain Admin permanently, or not at all.

Twenty years of deployment matched the data model exactly. A typical 2010-vintage enterprise ran ten to thirty standing Domain Administrators across business units, because manually adding and removing membership for each task was untenable at human scale. The data model did not punish standing membership; the operator chose the only category the directory offered.

December 2012: Microsoft names the failure mode#

In December 2012, Patrick Jungles, Mark Simos, Aaron Margosis, Roger Grimes, Laura Robinson and the Microsoft Trustworthy Computing team published Mitigating Pass-the-Hash and Other Credential Theft, Version 1 ^[4], ^[5]. It is the first formal Microsoft acknowledgment that credential-theft propagation through Active Directory was not a software defect to be patched but a structural property of standing admin membership.

The argument is direct. If twelve Domain Admins exist, the attack surface of "Domain Admin of contoso.local" is the union of those twelve people's personal attack surfaces. Any one gets phished, or gets hash-extracted from a Tier-1 server they accidentally signed into, and the attacker has Domain Admin permanently. The MIM PAM documentation later restated the failure in one sentence: "Today, it's too easy for attackers to obtain Domain Admins account credentials, and it's too hard to discover these attacks after the fact" ^[6].

2014: The tier model arrives, the mechanism does not#

The 2014 update -- Mitigating Pass-the-Hash, Version 2 ^[4] -- generalized the threat model and introduced the Tier-0 / Tier-1 / Tier-2 framing as a structural mitigation. v2 said two things clearly that v1 had only implied. First, standing membership in Tier-0 groups was the root cause, not a downstream defect. Second, the mitigation pattern -- isolate tiers, reduce the standing count, use dedicated Privileged Access Workstations -- was guidance, not a mechanism. Microsoft Trustworthy Computing did not yet have a product that could mechanically time-bound group membership in Active Directory.

v2 named the problem, drew the threat model, and recommended the structural fix. What it could not do was ship a mechanism. The mechanism would come, but on the wrong side of the cloud boundary.

3. The On-Prem Detour: MIM 2016 PAM, Bastion Forests, and Shadow Principals#

Microsoft's first mechanical JIT-admin product was not in the cloud. It was on-premises, and it required a separate Active Directory forest.

Stop and re-read that. To bound the duration of a group membership in pre-2016 Active Directory, Microsoft had to build a different directory and inject SIDs from one into the other across a trust. The reason was the data model. The production forest's member attribute had no TTL field. Adding one meant changing the AD schema. Changing the schema meant a Windows Server release. So while the schema change was in flight, Microsoft shipped the on-prem JIT-admin product on a different architecture: ask the operator to stand up a second forest whose only job was to issue time-bounded SIDs into the first.

August 6, 2015: MIM 2016 ships PAM#

On August 6, 2015, Microsoft Identity Manager 2016 reached general availability and shipped a new capability named Privileged Access Management ^[6]. The architecture is the interesting part. MIM PAM uses three primitives that, together, give Active Directory a mechanically time-bounded group membership for the first time:

1. A bastion forest -- an entirely separate Active Directory forest, sometimes called the "red" forest or "admin" forest, where privileged accounts live.
2. A one-way PAM trust from the production forest to the bastion forest, configured for selective authentication.
3. Shadow principal objects in the bastion forest, each carrying a SID that names a real privileged group in the production forest.

The activation flow is direct. A user in the bastion forest requests privilege through the MIM Portal. An approver decides. MIM writes a TTL-bounded membership in the appropriate shadow principal, with the TTL enforced by the Windows Server 2016 temporal-group-membership feature ^[7]. The bastion KDC injects the production-forest SID into the user's Kerberos PAC. The production forest accepts that SID across the PAM trust. After the TTL expires, subsequent ticket renewals exclude the privileged SID, and the user no longer holds the privilege.

flowchart LR
subgraph BASTION["CORP-PRIV bastion forest"]
A["Privileged user account"]
SP["Shadow principal (msDS-ShadowPrincipal) carries production SID, TTL"]
BKDC["Bastion KDC"]
A -->|"Time-bound membership"| SP
SP --> BKDC
end
subgraph PROD["CORP production forest"]
DA["Domain Admins"]
PKDC["Production KDC"]
end
BKDC -->|"Kerberos ticket carries injected SID via PAM trust"| PKDC
PKDC -->|"SID in PAC grants membership for TTL only"| DA

October 15, 2016: Windows Server 2016 makes the mechanism real#

For the first fourteen months of MIM 2016's life, the full feature did not work. The temporal-group-membership and shadow-principal schema classes that MIM PAM depends on are AD primitives that arrived only with Windows Server 2016, which reached general availability on October 15, 2016 ^[8]. Microsoft Learn states the requirement directly: "With Windows Server 2016, PAM features of time-limited group memberships and shadow principal groups are built into Windows Server Active Directory" ^[9], and "All domain controllers in the bastion environment for the PRIV forest must be Windows Server 2016 or later" ^[9]. The PAM trust is technically a forest trust with selective authentication enabled. The selective authentication flag is what prevents the bastion forest's privileged identities from being usable for anything other than the explicit shadow-principal SID injection -- without it, the bastion forest would itself become a sprawling privileged-access surface.

This is the moment AD itself gains a temporal least-privilege primitive, forty-one years after Saltzer and Schroeder published the principle. The mechanism is real, but the operational profile is brutal.

Three reasons it did not generalize#

MIM PAM solved exactly one problem and could not be extended to the next. Three structural constraints kept it confined to a niche.

First, it was on-premises only. A bastion forest is an Active Directory artifact. Microsoft Entra ID, Office 365, and Azure RBAC role assignments live in a different identity system, with no concept of a forest, no PAM trust target, and no place to plug a shadow-principal object. MIM PAM had no cloud story, and by 2015 the cloud was already where most new Microsoft privileged-access surfaces were being deployed.

Second, the operational complexity filtered out everyone except the most security-mature shops. A bastion forest is a separate Active Directory forest, with its own domain controllers, replication, backup, disaster recovery, and PKI implications. The deployment also requires MIM Service, MIM Portal, MIM Web Service, and SQL Server. Auditing the PAM trust correctly is itself non-trivial work. Microsoft Learn now positions MIM PAM as appropriate only for isolated, non-Internet-connected deployments ^[6]; the verbatim positioning and the MIM 2016 lifecycle details are in the Callout below.

Third, the forest-functional-level dependency delayed real deployment by more than a year. Shadow principals were not usable until Windows Server 2016 reached GA in October 2016. MIM 2016 had been generally available since August 2015. For its first fourteen months in market, the headline JIT-admin feature could not be configured at full fidelity. By the time Windows Server 2016 shipped, Microsoft was already operating its cloud PIM in production.

What the on-prem detour reveals about the cloud's shape#

MIM PAM mechanically bounds membership in groups via shadow principals in a separate forest. The cloud has no concept of a forest. So the cloud-native mechanical bound must attach to the assignment object directly, not to the group object indirected through a separate forest. The cloud needed a new assignment-category type, not a new forest topology.

The cloud does not have a forest. It has a role-assignment object. What if that object grew a second state?

4. The Breakthrough: A Two-State Role-Assignment Object#

By August 2015, while MIM 2016 PAM was still in late preview for the on-premises case, the Microsoft Identity Division had already shipped something different for the cloud. They shipped a role-assignment object with one new field. That field changed everything that came after it.

The 2015 preview#

Alex Simons's August 27, 2015 capability-update post on the CloudBlogs (now migrated to Microsoft Tech Community) is the first public articulation of what Azure AD PIM was building ^[11]. It introduced four surfaces: an eligible assignment category distinct from active, multifactor authentication required at activation, security alerts that watched for privileged-role anomalies, and what the post called Security Reviews -- the precursor to access reviews. The architecture under those four surfaces is the load-bearing part: a single new field on the role-assignment object.

On September 15, 2016, Azure AD Premium P2 reached general availability and carried the first generally-available cloud-native PIM, attributed to Joy Chik (then Corporate Vice President of the Identity Division) and the Identity engineering team ^[12]. Eligible-versus-active was now a billable, supported, production-grade feature.

The one-function spine#

Read this carefully. It is the article's central claim.

Standing admin was the default not because anyone thought it was secure, but because the role-assignment object had only one state. PIM's contribution is to add a second state -- eligible -- and to make the transition from eligible to active a gated, audited, time-bounded operation that is by definition mediated by PIM.

The principle was Saltzer and Schroeder, 1975. The recognition that standing admin was the failure mode was Mitigating Pass-the-Hash, 2012 and 2014. The on-premises mechanism was MIM 2016 PAM. The cloud answer is a different shape entirely: not a new directory and a SID-injection trust, but a single field on the assignment object itself.

Microsoft Learn documents the resulting terminology in the PIM overview. A principal -- user, group, service principal, or managed identity -- can be eligible or active for a role, and either assignment can be permanent or time-bound ^[13]. The same page elevates a forty-year-old phrase into a product term: "principle of least privilege access -- A recommended security practice in which every user is provided with only the minimum privileges needed to accomplish the tasks they're authorized to perform" ^[13]. The 1975 sentence is now a glossary entry inside a 2026 product, and the product has a mechanism that makes the sentence enforceable.

The formal tuple#

Concretely, a PIM-managed role assignment is a 5-tuple. Let $A = (p, r, s, t, d)$ where $p$ is the principal, $r$ is the role, $s$ is the scope, $t \in \{\text{eligible}, \text{active}\}$, and $d \in \{\text{permanent}, \text{time-bound}[s_0, e_0]\}$. The activation transition is

$\text{activate}: A_{t=\text{eligible}} \longrightarrow A_{t=\text{active},\ d=\text{time-bound}[\text{now},\ \text{now}+\Delta]}$

subject to the per-role activation policy. The interesting part is what the tuple makes expressible:

RoleAssignment = {
    principal:  user | group | service principal | managed identity,
    role:       Entra directory role | Azure RBAC role | group membership | group ownership,
    scope:      directory | management-group | subscription | resource-group | resource | group,
    type:       eligible | active,
    duration:   permanent | time-bound[start, end]
}

activate: eligible_assignment -> active_assignment   // PIM-mediated, gated, audited

flowchart TD
subgraph Permanent["Permanent duration"]
PE["Permanent eligible -- standing eligibility, no privilege held"]
PA["Permanent active -- legacy standing admin"]
end
subgraph TimeBound["Time-bound duration"]
TE["Time-bound eligible -- standing eligibility with end date"]
TA["Time-bound active -- JIT admin after activate()"]
end
PE -->|"activate()"| TA
TE -->|"activate()"| TA
TA -->|"expire or deactivate()"| PE
PA -->|"legacy posture being retired"| PE

The grid has only four cells. Permanent active is the pre-PIM world, the standing-admin posture every later best practice has been trying to retire. Time-bound active is the JIT-admin state, materialized only at the moment of work and expired shortly after. The two eligible states -- permanent or time-bound -- are the standing relationships between a principal and a role that grant no privilege at rest. The expressive change is small. The deployment consequences are total.

PIM did not add eight features. It added one field, and everything else is downstream.

This is Aha #1. The reader who came in believing standing admin persisted for forty years because operators lacked discipline now sees it differently. Operator discipline was a fragile workaround for a missing data-model field. The 1975 principle was correct. The 2012-2014 PtH whitepapers were correct. The operators were not the problem. The role-assignment object had one state to be in, and the deployment matched the data model exactly. The fix was a structural change to the data model.

The next nine years of PIM history are about extending that two-state primitive: to Azure RBAC, to security groups, to partner tenants, to the conditional-access plane, and to a detection layer that flags people who try to skip activation entirely. We walk each extension in turn. First, the mechanism itself.

5. Anatomy of an Activation#

We have seen what changed. Walk through what happens, end to end, when alice@contoso.com clicks "Activate" on her eligible Global Administrator assignment at 14:00:00 on a Tuesday.

The activation flow, step by step#

Six things happen, in order, and each writes audit-log evidence:

1. The eligible assignment already exists. Alice has been a permanent-eligible Global Administrator since she was hired. The PIM directory object records principal alice@contoso.com, role Global Administrator, scope directory, type=eligible, duration=permanent. Today she holds zero of the role's permissions.
2. The activation request lands on PIM. Alice clicks Activate in the Entra admin centre, or fires the equivalent Microsoft Graph call. PIM pulls the activation policy for (role=Global Administrator, scope=directory) and prepares to evaluate the gates ^[14].
3. The policy gates evaluate. This is the load-bearing part, and the place readers most often misread the docs. The gates are per-role configurable, not universal. Microsoft Learn documents five gates the tenant can independently switch on or off ^[14]:
   • Multifactor authentication at activation if requires_mfa is set.
   • Approval routing to named approvers or an approver group if requires_approval is set.
   • Justification text capture if requires_justification is set.
   • Ticket number capture, optionally tagged with a ticketing-system identifier, if requires_ticket is set.
   • Activation duration validation against the per-role configurable maximum -- one to twenty-four hours, with one hour the default for the highest-privileged Entra roles such as Global Administrator and Privileged Role Administrator ^[14].
4. PIM materializes the active assignment. Microsoft Learn states the latency directly: "Microsoft Entra PIM creates active assignment (assigns user to a role) within seconds" ^[15]. A new token Alice obtains after this moment will carry the activated role's claims.
5. The PIM audit log records the entire transaction. A new entry captures the request, the approver's decision and decision time, the justification text, the ticket reference, the activation start, and the planned expiry. The audit log is retained for thirty days by default and can be routed to Azure Monitor for longer retention ^[16].
6. Auto-deactivation fires at the duration boundary. At 15:00:00 -- one hour after activation -- PIM deactivates the assignment within seconds ^[15]. Alice can also call deactivate() explicitly to return early.

sequenceDiagram
autonumber
participant User as alice
participant PIM
participant MFA
participant Approver as bob
participant Graph as Microsoft Graph
participant Audit as PIM audit log
User->>PIM: Activate Global Administrator
PIM->>MFA: Require MFA challenge
MFA-->>PIM: MFA passed
PIM->>Approver: Route approval request
Approver-->>PIM: Approve with justification context
PIM->>Graph: Materialize active assignment within seconds
PIM->>Audit: Write request, decision, materialization records
Note over PIM,Audit: Token issued with activated role claims
Note over PIM,Graph: One-hour TTL begins
PIM->>Graph: Auto-deactivate at expiry within seconds
PIM->>Audit: Write deactivation record

Activation policies are configured, not assumed#

Two of the most common misunderstandings the documentation receives are about this configurability. First, MFA at activation is not universally required by PIM. The role's activation policy must be set to require it. Second, the activation maximum is configurable per role per scope inside a one-to-twenty-four-hour range, with the default for Global Administrator and Privileged Role Administrator at one hour ^[14]. A "PIM tenant" where one role requires MFA and approval and another role requires only justification text is a perfectly valid configuration; both roles are PIM-gated, but their gate sets differ.

Authentication context: gating activation, not sign-in#

Conditional Access has gated sign-in since 2014. Until 2023, it had no way to gate the activation event itself. The integration between PIM and Conditional Access changes that by attaching an authentication context label to the activation, which Conditional Access can target the same way it targets any other authentication. Microsoft Learn includes the activation policy option "On activation, require Microsoft Entra Conditional Access authentication context" ^[14].

The activation gate, as code#

To make the gate-composition idea concrete, here is the activation policy as a small JavaScript function. Edit the policy or the request and re-run it.

function activate(request, policy) {
// policy gates are independent; any combination can be required
if (policy.requires_mfa && !request.mfa_passed) {
  return { ok: false, reason: 'MFA challenge failed or absent' };
}
if (policy.requires_approval && !request.approval_decision) {
  return { ok: false, reason: 'Approval pending' };
}
if (policy.requires_justification && !request.justification) {
  return { ok: false, reason: 'Justification text missing' };
}
if (policy.requires_ticket && !request.ticket_number) {
  return { ok: false, reason: 'Ticket number missing' };
}
if (request.duration_hours > policy.max_duration_hours) {
  return { ok: false, reason: 'Requested duration exceeds policy maximum' };
}
// activation succeeds: materialize a time-bound active assignment
const expires_at = new Date(Date.now() + request.duration_hours * 3600 * 1000);
return {
  ok: true,
  active_assignment: {
    principal: request.principal,
    role: request.role,
    scope: request.scope,
    type: 'active',
    duration: { kind: 'time-bound', start: new Date(), end: expires_at }
  }
};
}

const policy = {
requires_mfa: true, requires_approval: true,
requires_justification: true, requires_ticket: true,
max_duration_hours: 1
};
const request = {
principal: 'alice@contoso.com', role: 'Global Administrator', scope: 'directory',
mfa_passed: true, approval_decision: 'approve',
justification: 'MSRC-2026-PIM-12345', ticket_number: 'SNOW-INC-987654',
duration_hours: 1
};
console.log(activate(request, policy));

The function is mechanical and short for a reason. Every PIM gate is independently expressible, the policy is a record, the request is a record, and the active-assignment output is itself a record the system can audit. The complexity of PIM, such as it is, lives in the surrounding infrastructure -- the directory, the audit log, Conditional Access, the alert engine -- not in the gate itself.

The Azure-resource five-minute floor#

One operational detail belongs here. Azure resource role assignments under PIM-for-Azure-Resources carry an additional latency floor: an Azure resource role assignment cannot be made for a duration of less than five minutes and cannot be removed within five minutes of being created ^[17]. This is the rare place where the cloud control plane exposes a hard minimum-time bound in its assignment-state machine, and it shapes the lower limit of any tightening strategy on Azure RBAC scopes.

Activation is the per-event control. But what about the standing posture across the tenant -- the eligibility surface, the drift you did not notice, the assignment configuration in places PIM does not reach by default? For that, you need access reviews, and you need to push the eligible/active primitive beyond the original twenty-eight built-in directory roles.

6. Beyond Directory Roles: Extending Eligible and Active Across Four Boundaries#

PIM at GA in September 2016 covered roughly twenty-eight built-in Entra directory roles. Everything else -- Azure RBAC, security groups, partner-tenant delegation, the Conditional Access activation event -- was still single-state and permanent-active. The next nine years of PIM history are the story of closing those four boundaries, one at a time.

flowchart TD
Core["Two-state assignment object, 2016"]
Core --> Azure["PIM for Azure Resources, 2017-2019, RBAC at four scopes"]
Core --> Groups["PIM for Groups, GA October 2023, membership and ownership"]
Core --> Partner["GDAP May 2022 plus Azure Lighthouse eligible authorizations"]
Core --> CA["PIM with Conditional Access authentication context, GA October 2023"]

Boundary 1: PIM for Azure Resources#

Between 2017 and 2019, Microsoft extended the eligible-versus-active model from Entra directory roles to Azure RBAC. The extension covers four scopes -- management group, subscription, resource group, and individual resource -- and supports both built-in roles (Owner, Contributor, User Access Administrator, and the security roles) and custom roles ^[17].

The non-obvious operational property of PIM-for-Azure-Resources is that role settings do not inherit down the RBAC hierarchy. A policy you tighten on Owner at the management-group scope does not automatically flow down to Owner on subscriptions, resource groups, or resources beneath it. Each (role, scope) pair is its own policy slot, and each must be configured.

Boundary 2: PIM for Groups#

The PIM-for-Groups timeline is three distinct events. In August 2020, Microsoft previewed the feature under its original name, "Privileged Access Groups," and limited the preview scope to role-assignable security groups ^[18]. In January 2023, Microsoft renamed the feature to "Privileged Identity Management for Groups" in the Entra admin centre; the underlying eligible/active model was unchanged ^[19]. In October 2023, more than three years after the preview, PIM for Groups reached general availability with a broader scope -- role-assignable security groups (carried forward), non-role-assignable security groups (newly supported), and Microsoft 365 groups (newly supported), with JIT for both membership and ownership ^[20], ^[19], ^[21]. The three events span more than three years and should not be conflated. August 2020: preview of "Privileged Access Groups," role-assignable security groups only ^[18]. January 2023: rename to "PIM for Groups"; same scope and model ^[19]. October 2023: general availability with the broader scope (non-role-assignable security groups plus M365 groups), and JIT for both membership and ownership ^[20]. Two structural exclusions persist throughout: dynamic-membership groups and groups synchronized from on-premises Active Directory ^[19]. The scope is broad: any Entra security group and any Microsoft 365 group, except dynamic-membership groups and on-premises-synced groups, can be PIM-enabled ^[19].

The interesting design choice is that PIM-for-Groups gates two distinct surfaces per group: membership and ownership. The two surfaces each get their own activation policy ^[21].

Boundary 3: Partner tenants -- GDAP and Azure Lighthouse#

Until 2022, the Microsoft partner channel -- Cloud Solution Providers and Managed Service Providers -- worked through a model called Delegated Admin Privileges (DAP), in which the partner held standing Global Administrator on every customer tenant they touched. The Nobelium supply-chain attack tradition of 2020-2021 made the structural risk of that posture unignorable ^[22]: one compromise of one partner credential meant Global Administrator across hundreds or thousands of customer tenants simultaneously.

In May 2022, Microsoft introduced Granular Delegated Admin Privileges (GDAP) ^[23], ^[24]. GDAP replaces the standing-GA pattern with time-bound (one to seven-hundred-thirty days) and role-scoped delegation between partner and customer tenants. Microsoft Learn's framing makes the design explicit: "GDAP is a security feature that provides partners with least-privileged access following the Zero Trust cybersecurity protocol. It lets partners configure granular and time-bound access to their customers' workloads in production and sandbox environments. Customers must explicitly grant the least-privileged access to their partners" ^[23].

The Azure plane has a parallel construct. Azure Lighthouse eligible authorizations, introduced alongside GDAP, extend PIM-for-Azure-Resources eligibility across the tenant boundary ^[25]. The customer (not the partner) controls the PIM policy on the delegated authorization. One important exception: service principals cannot use eligible authorizations, because there is currently no way for a service principal to elevate its access ^[25]. The application-identity gap we reach in section 9 reaches into Lighthouse too.

Boundary 4: PIM and Conditional Access authentication context#

The October 2023 GA wave closed the activation-gate-versus-sign-in-gate gap. Before October 2023, Conditional Access could gate sign-in into the tenant, but it could not gate the activation event itself. After October 2023, an authentication-context-tagged Conditional Access policy can target activation specifically ^[20]. A policy of the form "activation of any control-plane role requires a compliant device and a fresh MFA challenge" becomes expressible without third-party tooling ^[14].

The retirement of Tier-0, Tier-1, Tier-2#

The umbrella framing has also shifted. Microsoft's 2014 Tier-0 / Tier-1 / Tier-2 model is being progressively retired in favour of the Enterprise Access Model (EAM), which uses control plane, management plane, and data/workload plane as the structural divisions ^[26]. EAM is cloud-native where Tier-0/1/2 was on-premises-centric. Microsoft Learn states the mapping: "Tier 0 expands to become the control plane and addresses all aspects of access control", and "what was tier 1 is now split into the following areas: Management plane ... Data/Workload plane" ^[26].

The retirement is partial. The practitioner audience still uses Tier-0/1/2 more often than EAM in day-to-day language. The Microsoft Learn page for Securing Privileged Access explicitly cross-references both ^[28].

Coverage is one half of the story. The other half is detection. What does PIM do when someone in the Privileged Role Administrator role simply assigns Global Administrator to a user directly through Microsoft Graph, bypassing the activation workflow entirely?

7. The Detection Layer: Six PIM Alerts and the Assignment-Bypass Class#

PIM gates activation. The first question every adversary thinks of, and every architect should think of next, is: what about the assignment itself? What happens when someone in the Privileged Role Administrator role just creates a permanent-active Global Administrator assignment directly, skipping the eligible-to-active workflow entirely?

The answer is the article's second aha moment, and it is deliberately surprising.

The six PIM Alerts#

Microsoft Learn documents seven named alerts in the PIM Alerts surface for Microsoft Entra roles ^[29]. Six of them are behavioural detections; the seventh is a licensing-precondition alert that fires when the tenant lacks the appropriate license. The seventh alert, named "The organization doesn't have Microsoft Entra ID P2 or Microsoft Entra ID Governance," is a low-severity licensing-precondition alert. The "six PIM Alerts" framing in this article refers to the six behavioural alerts; the licensing alert is structurally distinct. The six behavioural alerts, with the canonical names verbatim from the documentation, are:

The third row -- "Roles are being assigned outside of Privileged Identity Management" -- is the load-bearing one. Microsoft Learn rates it High severity because it is the alert that fires when somebody routed around PIM entirely ^[29]. The verbatim documentation reads: "Privileged role assignments made outside of Privileged Identity Management aren't properly monitored and might indicate an active attack" ^[29].

Detective, not preventive -- and why#

Read the definition again. The alert fires after the assignment is created. PIM does not block direct assignments outside its workflow.

For most architects this lands hard. The reasonable next thought is "if PIM does not block the bypass, what is the point?" Sit with that thought, then read the design rationale.

The Microsoft Graph endpoints that allow direct role assignment are the integration surface every legitimate administrative tool uses. Identity Governance products use them. CI/CD identity provisioning scripts use them. Break-glass automations use them. Microsoft's own admin centres use them in some configurations. The customer-side tools that scan, audit, remediate, and provision against the tenant use them. A preventive block on direct assignment would break every one of those integrations. It would also break PIM itself; the eligible-to-active materialization step is a write to the same assignment surface.

This is Aha #2. The reader who walked in expecting PIM to be a "deny direct assignments" product walks out understanding why the design says "alert loudly via High severity, then let the customer layer preventive controls based on their tooling estate." The trade-off is named, not hidden.

The 1000-notification ceiling and the SIEM-side correlation#

One operational footnote and one wider observation. The notification fan-out has a hard cap: "The maximum number of notifications sent per one event is 1000. If the number of recipients exceeds 1000, only the first 1000 recipients will receive an email notification" ^[29]. Very large tenants whose privileged groups exceed the cap should not rely on email-notification fan-out alone. The detection layer beyond PIM Alerts is Microsoft Sentinel UEBA, which builds dynamic behavioural profiles for users, hosts, IP addresses, applications, and other entities and emits anomaly scores against AuditLogs operations including role-eligibility additions and activations ^[30]. Sentinel UEBA is the closest 2026 Microsoft-shipped activation-anomaly-scoring surface; it is detective SIEM correlation, not synchronous gating.

The wider observation is that the PIM detection layer is one piece of a larger pipeline. PIM Alerts give you the High-severity assignment-bypass detection. Microsoft Sentinel UEBA gives you per-user behavioural-anomaly scoring against the audit-log events ^[30]. Entra ID Protection gives you sign-in-risk and user-risk classifications for the principal whose token was used. The mature 2026 deployment correlates all three; the assignment-bypass alert is the floor of that pipeline, not the ceiling.

Microsoft solved the JIT-admin problem with a two-state assignment object, four extension surfaces, and a six-alert detection layer. Did the rest of the industry agree? Look at what AWS and Google bet on, and at the third-party vault market that predates both.

8. Competing Architectures: AWS Sessions, GCP Bindings, and the Vault Model#

Microsoft bet on a two-state assignment object. The rest of the industry placed different bets.

AWS bet on the session credential. Google bet on the conditional binding. The third-party PAM market bet on the vault. HashiCorp bet on the ephemeral credential. Each architecture is a different answer to one question: what should be the bounded unit of privilege? PIM bounds the assignment state; AWS bounds the session; GCP bounds the binding; CyberArk and Vault bound the credential. The methods are architecturally distinct, and they coexist in real estates more often than they compete.

AWS: bound the session#

AWS IAM Identity Center plus the Security Token Service AssumeRole API bound the session, not the assignment. Permanent role-bindings -- permission sets attached to identities -- are themselves standing. The temporary part is the session that materializes when the identity calls AssumeRole. AWS documents this directly: "Temporary security credentials are short-term, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, AWS no longer recognizes them or allows any kind of access from API requests made with them" ^[31].

The session lifecycle is concrete. AssumeRole returns an access key, a secret key, and a session token, with a minimum fifteen-minute and a maximum twelve-hour session duration; the API operation default is one hour ^[32]. IAM Identity Center permission sets ship with a one-hour default and a one-to-twelve-hour configurable range ^[33].

The AWS approach has clear strengths in multi-account AWS Organizations and in programmatic access. It is also the natural fit for any workload that needs short-lived credentials. The gaps relative to PIM: no built-in approval workflow, no equivalent of the PIM Alerts surface, and no eligible-versus-active distinction on the role-binding itself. A standing AssumeRole grant is, structurally, standing privilege; what is bounded is the session that consumes it.

Google Cloud: bound the binding#

Google Cloud IAM took a different route. IAM Conditional Bindings let an allow policy include a Common Expression Language predicate that is evaluated at request time. The canonical temporal pattern is request.time < timestamp(...), which expires the binding at a wall-clock instant ^[34]. There is a practical ceiling of one hundred conditional bindings per allow policy.

On top of conditional bindings, Google launched Privileged Access Manager (PAM) in public preview in May 2024 ^[35], ^[36]. PAM adds the entitlement-and-grant workflow that PIM ships natively: eligible principals, eligible roles, max duration, justification, approvers, and notifications, with grant duration enforced by the underlying conditional binding revocation. Audit-event correlation is documented in a separate page ^[37].

The GCP approach is the closest hyperscaler analogue to PIM's eligible/active model in architecture, but the PAM productization shipped in preview in May 2024 ^[35] -- nearly a decade after Azure AD PIM's 2016 GA -- and the alert and detection surfaces are correspondingly less mature.

The third-party vault: CyberArk, BeyondTrust, Delinea#

The longest-standing answer is the one the third-party PAM market built. CyberArk, BeyondTrust, and Delinea -- all three 2024 Gartner Magic Quadrant Leaders for Privileged Access Management ^[38], ^[39], ^[40] -- bound the credential, not the assignment or the session. The credential exists permanently in the vault; access to the credential is bounded by session brokering, periodic password rotation, and full session recording.

The vault model has structural strengths PIM's role-assignment-state model cannot match. The vault covers heterogeneous estates that include Windows, Linux, network devices, databases, mainframes, and OT/SCADA appliances -- every system whose credentials cannot be re-architected to a cloud-IAM eligible-active object. Vault-and-broker products provide session recording for SOX and PCI-DSS evidence collection, and they integrate with credential-rotation workflows for legacy vendor appliances whose hard-coded credentials cannot be eliminated.

Most large enterprises run both Entra PIM (for Entra and Azure role assignments) and a third-party PAM product (for SSH, on-premises service accounts, database passwords, network devices). The two markets are complements more than substitutes.

HashiCorp Vault and OpenBao: bound the credential's lifetime#

HashiCorp Vault took the credential-bounded idea and made it ephemeral through dynamic secrets: a credential materialized on demand by Vault for a configured backend (a database, a cloud IAM, a PKI), returned with a lease and TTL, and revoked at the backend when the lease expires ^[41]. The OpenBao fork, governed under the Linux Foundation, preserves the same dynamic-credential semantics ^[42]. OpenBao was created in late 2023 after HashiCorp moved Vault from the open-source MPL to the Business Source License. The Linux Foundation announced on April 30, 2024 that OpenBao would join LF Edge as one of four new projects (alongside EdgeLake, InfiniEdgeAI, and InstantX) at the Open Networking and Edge (ONE) Summit ^[43]. The dynamic-secret primitive -- "create a credential, hand it out, revoke it at lease expiry" -- is preserved on both code lines.

The Vault story matters for our purposes because it is the strongest 2026 coverage of the application-identity surface -- dynamic database credentials, Kubernetes service-account tokens, cloud-IAM short-lived credentials. PIM does not cover that surface today; Vault does. This previews the open boundary in section 9.

What is bound, in one comparison table#

The five methods occupy four positions on the "what is bound" axis: assignment-state (PIM), session-credential (AWS), policy-binding (GCP), and knowledge-of-credential (CyberArk and Vault). The methods are architecturally distinct, and the right enterprise answer in heterogeneous estates is some composition of more than one.

PIM is the most mature JIT-admin product in the cloud, and it has the most complete coverage of the user-principal surface. The remaining gaps are not about catching up to the competitors; they are about a class of identity the eligible/active model was never designed to gate.

9. What the JIT-Admin Pattern Does NOT Close#

For all the architectural elegance of the two-state assignment object, PIM does not close the JIT-admin problem. It closes a sub-problem, very well, and leaves five structural limits an honest treatment must name.

9.1 Standing eligibility is itself standing privilege#

PIM bounds the active duration. It does not bound the eligibility duration. A user with a permanent-eligible Global Administrator assignment is one activate() call away from the role's permissions for the next hour. If that user has been phished -- credential plus MFA bypass via a session-cookie capture, say -- the attacker can satisfy the gates. The MFA challenge passes. The justification text is whatever the attacker types. The approval, if required, routes to the legitimate approver, who may approve a legitimate-looking request that actually came from the attacker.

PIM produces an audit-log record of every step. It does not produce a structural impossibility. Eligibility is itself a security-critical property of the identity, and standing eligibility is the modern analogue of standing membership: a long-lived relationship between principal and role that a successful credential compromise can exercise.

9.2 Approver collusion#

The approval gate is two-phishee resistant only when the requester and approver are independently compromisable. Two-phishee collusion -- the requester and the approver are the same adversary, or two adversaries cooperating -- defeats the workflow at the mechanism layer. The usual mitigations raise the bar: named approvers rather than approver groups (which can be compromised at the group level), CA-gated approval actions, and four-eyes alternatives. None close the class.

9.3 The application-identity gap#

This is the article's heaviest limit, and it deserves the most space.

PIM's eligible-active state machine is currently defined over principal in (user | group). Service principals, managed identities, and OAuth consent grants do not flow through PIM activation. Their role assignments are permanent and active by default, and there is no eligible category that applies to them. Microsoft Learn's documentation for Workload ID Premium and Conditional Access for workload identities makes this explicit: ID Protection workload-identity risk detections cover service principals in single-tenant, non-Microsoft SaaS, and multitenant apps, but "Managed Identities aren't currently in scope" ^[44]. Conditional Access for workload identities applies similarly only to service principals owned by the organization, and CA policies "assigned to a group that contains a service principal are not enforced for that service principal" ^[45].

Andy Robbins's three-part Managed Identity Attack Paths series, published June 6-8, 2022 on the SpecterOps blog, is the canonical demonstration of how this gap is exploited ^[46], ^[47], ^[48]. The mechanism is direct. An Azure compute resource -- an Automation Account ^[46], a Logic App ^[47], or a Function App ^[48] -- carries an attached managed identity. The managed identity holds standing role assignments at whatever scope the operator granted, often Owner or Contributor on a subscription.

From inside the resource, any code can fetch an OAuth access token for the managed identity by calling the Azure Instance Metadata Service endpoint at http://169.254.169.254/metadata/identity/oauth2/token. No human in the loop. No MFA challenge. No PIM activation. The audit log records a service-principal token issuance, not an alice-clicked-Activate event.

"Managed Identity assignments are an extremely effective security control... But Managed Identities introduce a new problem: they can quickly create identity-based attack paths in Azure that may lead to escalation of privilege opportunities." -- Andy Robbins, Managed Identity Attack Paths, Part 1: Automation Accounts, June 6, 2022 ^[46]

sequenceDiagram
autonumber
participant Attacker
participant FunctionApp as Compromised Function App
participant IMDS as IMDS endpoint 169.254.169.254
participant ARM as Azure Resource Manager
participant PIMUnused as PIM activation (unused)
Attacker->>FunctionApp: Code execution via supply-chain or vuln
FunctionApp->>IMDS: GET /metadata/identity/oauth2/token
IMDS-->>FunctionApp: OAuth access token for managed identity
FunctionApp->>ARM: Action as Owner on subscription
ARM-->>FunctionApp: Action succeeds
Note over PIMUnused,Attacker: No human, no MFA, no activation, no PIM audit

MITRE ATT&CK maps the class explicitly. T1078.004 -- Valid Accounts: Cloud Accounts cites Robbins's Part 1 as primary reference for the managed-identity case ^[50]. The page reads: "In Azure environments, adversaries may target Azure Managed Identities, which allow associated Azure resources to request access tokens. By compromising a resource with an attached Managed Identity, such as an Azure VM, adversaries may be able to Steal Application Access Tokens to move laterally across the cloud environment" ^[50].

T1548.005 -- Temporary Elevated Cloud Access explicitly names PIM as an instance of the JIT-access pattern adversaries abuse: "Many cloud environments allow administrators to grant user or service accounts permission to request just-in-time access to roles... Just-in-time access is a mechanism for granting additional roles to cloud accounts in a granular, temporary manner" ^[51].

9.4 The assignment-bypass is detective, not preventive#

The High-severity assignment-bypass alert documented in §7 is detective by design (see Aha #2). The structural limit it leaves open is that preventive blocking is not the PIM product's default: customers who want it layer a Conditional Access policy on the Microsoft Graph endpoint or an Azure Policy at the management-group scope ^[52], accepting that some legitimate Graph integration may need an exception.

9.5 Customer-owned PIM policy in CSP and Lighthouse scenarios#

In the partner-managed case, the customer (not the partner) controls the PIM policy on a delegated authorization ^[25]. This is the right place to put control, but it is also the place misconfiguration is most common. A customer whose Lighthouse eligible authorization is set with permissive activation policies (no MFA, no approval, large maximum duration) has an unmediated partner activation surface, and the partner cannot tighten the customer-side policy. The MSP-managed case is the operational gotcha most frequently raised at PIM-deployment review boards.

Aha #3: The gap is a data-model problem, not a patchable defect#

This is the third aha moment, and it lands differently from the first two.

The application-identity gap is not a backlog item. Extending the eligible-active state machine from principal in (user | group) to principal in (user | group | service principal | managed identity | OAuth consent grant) is a data-model extension that would require changes to the role-assignment object schema, the Microsoft Graph role-management endpoints, the PIM evaluation pipeline, the audit-log schema, the Sentinel detection schema, and every downstream IGA tool. The 2024+ Microsoft responses extend some controls to application identities. They do not yet introduce an eligible/active assignment-category type for application principals.

Microsoft has shipped partial responses. Entra Workload ID Premium ^[53] is a separate three-dollar-per-workload-identity-per-month SKU ^[53] that unlocks Conditional Access for workload identities ^[45] (with the explicit managed-identity exclusion clause) and ID Protection workload-identity risk detections ^[44]. The PIM page on access reviews documents that "Using Access Reviews for Service Principals requires a Microsoft Entra Workload ID Premium plan in addition to a Microsoft Entra ID P2 or Microsoft Entra ID Governance license" ^[54]. Microsoft's flagship Ignite 2025 announcement was Microsoft Entra Agent ID for AI agents ^[55]; the announcement is identity for AI workloads, not an eligible-active type extension for service-principal role assignments.

Robbins's class is closed-form within the 2026 PIM architecture. Closing it requires a new architecture, not a patch.

None of these limits is a defect. Each is a deliberate design boundary, and naming them is the academic honesty the topic deserves. The interesting question: where is active research happening, and what would closing the gap actually look like?

10. Open Problems: Where Active Research Is Happening#

The five limits in section 9 are settled architectural boundaries. The open problems are different. Each is something nobody has shipped a complete solution to as of 2026, but each has named partial results and named anchors.

10.1 JIT-gating application identities#

The data-model extension previewed in section 9's Aha #3 is the largest open problem in this space, and the one Microsoft is responding to most publicly.

What has been tried. Entra Workload ID Premium at three dollars per workload identity per month ^[53]. Conditional Access for workload identities, which lets the tenant block service-principal sign-ins based on IP range, ID-Protection risk score, or authentication context ^[45]. ID Protection workload-identity risk detections that flag suspicious sign-ins, leaked credentials, and admin-confirmed compromise for service principals ^[44]. Service-principal access reviews, gated behind Workload ID Premium plus Entra ID P2 or Governance ^[54]. Microsoft Entra Agent ID, the flagship Ignite 2025 announcement, brings first-class identity to AI agents ^[55] -- parallel to, but not the same as, an eligible-active type extension on application role assignments.

What is the conjecture? Closing this gap requires extending the role-assignment object's principal axis to include service principals, managed identities, and OAuth consent grants as first-class subjects of the eligible-active state machine. That extension would require a defined activate() semantics for non-human principals -- itself the hard problem, because the canonical user activation flow assumes an interactive MFA challenge.

Microsoft Learn states the difficulty bluntly: workload identities "can't perform multifactor authentication. Often have no formal lifecycle process. Need to store their credentials or secrets somewhere" ^[56]. The non-interactive case requires either programmatic policy gates (request from this caller, from this IP range, against this entitlement) or a delegation model where a human approver supplies the gate-passing event on the workload's behalf.

10.2 Real-time activation-anomaly blocking#

The PIM Alert "Roles are being activated too frequently" is post-hoc. It fires after the activation has already occurred and after the count crosses a threshold. The phished-but-still-authentic activation -- the attacker who supplies a valid MFA, a plausible justification, and a real ticket number -- is observationally indistinguishable from a legitimate emergency activation at the mechanism layer. The only signal that distinguishes them must come from behavioural telemetry.

What has been tried. Microsoft Defender for Cloud Apps ships an out-of-the-box user-and-entity behavioural analytics (UEBA) and machine-learning anomaly-detection layer; the documented policy weighs more than thirty risk indicators across eight risk-factor groups (risky IP, login failures, admin activity, inactive accounts, location, impossible travel, device and user agent, activity rate), with a seven-day initial learning period and a June 2025 transition to a dynamic threat-detection model ^[57]. Microsoft Sentinel UEBA scores anomalies post-event against AuditLogs operations including role-eligibility additions and activations ^[30]. Microsoft Defender for Identity correlates on-premises and cloud sign-in patterns for behavioural-anomaly detection. Neither Sentinel UEBA nor Defender for Cloud Apps is a synchronous gate. Both are detective layers that fire after the activation event has already created consequences.

The academic upper bound for what character-level and LSTM detectors achieve on adjacent tasks comes from Hendler, Kels, and Rubin's 2019 work on AMSI-based detection of malicious PowerShell code, which reports a true-positive rate of nearly 90% at a false-positive rate of less than 0.1% on the PowerShell-misuse classification problem ^[58]. That is the ceiling a probabilistic activation-anomaly classifier could approach. It is not enough to gate synchronously without false-positive operational pain, which is why the deployed surface is post-hoc UEBA scoring rather than pre-commit blocking.

The conjecture. Synchronous gating on behavioural signal at activation time would require Conditional Access (or its successor) to subscribe to an activation-event hook and consume a risk score from ID Protection, Defender for Cloud Apps, or Sentinel UEBA in the few hundred milliseconds before PIM materializes the active assignment. The architectural primitives exist; the synchronous risk-evaluation hook does not yet ship.

10.3 Hybrid-bridge JIT#

A single approval workflow spanning the on-premises (MIM PAM / shadow principals) and cloud (Entra PIM) boundaries is not a shipping product. Microsoft has Entra Cloud Sync and Entra Connect for directory synchronization; neither bridges the activation workflow. MIM 2016 is on extended support through January 9, 2029 ^[10]; Microsoft Learn states the path forward is cloud-first PIM with on-prem AD progressively scoped down to the few resources that cannot move ^[6].

10.4 Coverage-as-code#

How do you evaluate PIM policy coverage in CI/CD for a tenant with two hundred custom Azure roles and fifty directory roles, and gate every PR that touches the role-management policies?

Best partial results. Microsoft Cloud Security Benchmark v3 Privileged Access controls (PA-1, PA-2, ...) give Boolean per-recommendation pass/fail evaluation ^[59] -- close, but per-recommendation Boolean rather than composable policy. The PowerShell cmdlets Get-MgPolicyRoleManagementPolicy and Get-MgPolicyRoleManagementPolicyAssignment read role-management policies via Microsoft Graph; the cmdlets ship in the Microsoft.Graph.Identity.SignIns module, despite the Identity Governance branding ^[60]. The PIM role-management-policy cmdlets are commonly mis-attributed to the Microsoft.Graph.Identity.Governance PowerShell module because of the Identity Governance branding. They are actually in Microsoft.Graph.Identity.SignIns. The Import-Module line that gets the cmdlets into scope is Import-Module Microsoft.Graph.Identity.SignIns ^[60]. The EntraOps Privileged EAM community project on GitHub, maintained by Thomas Naunheim, demonstrates the "track changes and history of privileged principals and their assignments as code" idiom against the Enterprise Access Model classification ^[61]. Azure Policy itself operates on Azure resource configurations and does not directly evaluate PIM role-management policy state ^[52], which is the data-model gap that drives the GitOps-flavoured drift-detection community pattern.

// Take an array of role-management policy assignments
// (the kind Get-MgPolicyRoleManagementPolicyAssignment returns)
// and assert tenant-wide PIM coverage invariants.

function assertPrivilegedRoleCoverage(assignments, privilegedRoles, expected) {
const findings = [];
for (const role of privilegedRoles) {
  const a = assignments.find(x => x.roleDefinitionId === role);
  if (!a) {
    findings.push({ role, severity: 'High', issue: 'No PIM policy assignment' });
    continue;
  }
  const p = a.policy;
  if (p.requires_mfa !== expected.requires_mfa)
    findings.push({ role, severity: 'High', issue: 'MFA at activation not required' });
  if (p.requires_approval !== expected.requires_approval)
    findings.push({ role, severity: 'High', issue: 'Approval not required' });
  if (p.requires_justification !== expected.requires_justification)
    findings.push({ role, severity: 'Medium', issue: 'Justification not required' });
  if (p.max_duration_hours > expected.max_duration_hours)
    findings.push({ role, severity: 'Medium',
      issue: 'Maximum activation duration exceeds expected value',
      actual: p.max_duration_hours, expected: expected.max_duration_hours });
}
return findings;
}

const privileged = ['Global Administrator', 'Privileged Role Administrator',
                  'Security Administrator', 'User Access Administrator'];
const expected = { requires_mfa: true, requires_approval: true,
                 requires_justification: true, max_duration_hours: 1 };
const sample = [{ roleDefinitionId: 'Global Administrator',
policy: { requires_mfa: true, requires_approval: true,
          requires_justification: true, max_duration_hours: 4 } }];
console.log(assertPrivilegedRoleCoverage(sample, privileged, expected));

The conjecture. A full coverage-as-code primitive needs Azure Policy (or its successor) to evaluate PIM role-management policy state with the same first-class semantics it applies to Azure resource configuration. That extension would let a tenant declare an invariant -- "every role in the control plane has requires_mfa=true and max_duration_hours <= 1" -- and have the platform enforce it continuously across drift, the way Azure Policy already enforces resource invariants.

10.5 Adaptive-cadence eligibility reviews#

Should eligible membership be access-reviewed at higher cadence than active assignments? Eligible membership is standing privilege; active membership is bounded. The argument for adaptive cadence -- reviewing eligibility more frequently when behavioural signals or organizational events suggest the principal may no longer need the role -- is intuitive but mechanically unshipped.

Best partial result. The 2024+ ML-based access-review recommendations ^[62] -- inactive-user 30-day Deny, user-to-group-affiliation Deny -- are within-cycle reviewer-assist features. They help reviewers decide during a configured access review. They are not cross-cycle adaptive-cadence triggers that fire a new review off-schedule when conditions warrant.

These are research problems. The practitioner does not have the luxury of waiting for them to be solved. What does Monday morning look like for the architect who has read this far and now has to deploy?

11. Practical Guide: Monday Morning for the 2026 Tenant Architect#

You have read ten thousand words. You are responsible for a Microsoft 365 tenant that audits against SOX, SOC 2, and ISO 27001. You have a budget for Entra ID P2 (or Entra ID Governance) per privileged user. What do you do on Monday?

Work in this order. The list is ordered by cost-to-impact, with the cheapest, highest-impact items first.

Step 1: Baseline the Tier-0 surface#

Every directory role at "Privileged" classification or above should be PIM-eligible-only. The exceptions are the two emergency-access permanent-active Global Administrator accounts (break-glass), which we return to in Step 4.

Activation requires MFA, approval, justification, and ticket number for control-plane and management-plane roles. Maximum activation duration is one hour for Global Administrator and Privileged Role Administrator, and four hours for less-privileged roles. Configure per role per scope; remember that PIM-for-Azure-Resources policies do not inherit.

Import-Module Microsoft.Graph.Identity.Governance
Connect-MgGraph -Scopes 'RoleManagement.Read.Directory','User.Read.All'
$gaRoleId = (Get-MgRoleManagementDirectoryRoleDefinition `
    -Filter "displayName eq 'Global Administrator'").Id
Get-MgRoleManagementDirectoryRoleAssignment `
    -Filter "roleDefinitionId eq '$gaRoleId'" `
    -ExpandProperty Principal |
    Select-Object @{n='User';e={$_.Principal.AdditionalProperties.userPrincipalName}}, RoleDefinitionId

Step 2: Configure access reviews#

Quarterly for Tier-0 and control-plane roles. Semi-annually for Tier-1 and management-plane. Annually for Tier-2 and data/workload-plane ^[54]. Turn on the ML-based review recommendations: the 30-day inactive-user Deny recommendation is the reviewer-assist baseline, and the user-to-group-affiliation Deny recommendation helps reviewers spot principals who are organizationally distant from the rest of the group's membership ^[62].

Step 3: Turn on every PIM Alert and tune the GA-count threshold#

Enable all six behavioural PIM Alerts. Tune the "There are too many Global Administrators" alert to a minimum count of two and a percentage of 50% ^[29]. The expected steady-state count is "fewer than five standing GAs, most of which are break-glass." The High-severity assignment-bypass alert is non-negotiable; route it to a 24x7 SOC queue with an incident-response runbook. ※ Microsoft Secure Score's "Limit the number of Global Administrators" recommendation targets fewer than five standing GAs as the canonical baseline.

Step 4: Break-glass discipline#

Two emergency-access permanent-active Global Administrator accounts. Not one, not three.

Step 5: Extend PIM to the four boundaries#

PIM-for-Groups: gate ownership of every directory-role-assignable group, every privileged-access security group, and every group that grants management-group-level Azure RBAC. Membership alone is insufficient; ownership is a backdoor to membership.

PIM-for-Azure-Resources: gate Owner, User Access Administrator, and Contributor at the management-group scope, then explicitly at every subscription, every resource group, and every resource where the role is assignable. Inheritance does not flow; configure per scope.

GDAP and Lighthouse: every CSP partner authorization must be eligible, not active. Set the customer-side PIM policy explicitly. Audit annually.

PIM with Conditional Access: attach an authentication-context tag to activation policies on the privileged Entra roles. Add a CA policy that requires a compliant device and a fresh MFA challenge on activation. The activation gate becomes structurally tighter than the sign-in gate, which is the correct ordering for high-privilege actions.

Step 6: Continuous detection#

Pipe PIM activation events (via Microsoft Graph audit logs, surfaced in the AuditLogs and MicrosoftGraphActivityLogs Azure Monitor tables) to your SIEM. Cross-correlate with Entra ID Protection sign-in risk and Microsoft Sentinel UEBA anomaly signals ^[30]. KQL templates to write: (a) GA activations outside business hours; (b) activations from non-compliant devices; (c) the assignment-bypass alert correlated with the activating principal's recent sign-in risk score; (d) managed-identity token issuance against subscription-scoped Owner.

Step 7: Mind the application-identity surface#

This is the longest-running open item. Inventory every managed identity in the tenant. For each, document the role assignment, the scope, and the resource that holds it.

Apply the "Owner and User Access Administrator at subscription scope is dangerous" rule first; tighten those to Contributor or a custom role wherever possible. Where a managed identity must hold a high-privilege role at a high scope, treat the underlying resource (Function App, Logic App, VM, AKS cluster) as a Tier-0 asset for the purposes of patching, network exposure, and code-review process. Until PIM gates application identities natively, the Tier-0-asset framing is the substitute control.

That is the playbook for the user-principal side of the JIT-admin problem. The application-identity side is still being written. The next iteration of this material will be about the data-model extension that closes Robbins's gap, or the architectural successor that arrives in its place.

12. Frequently Asked Questions and Closing#

Three classes of question come up every time this material is taught. The first is conceptual ("what does eligible actually mean?"). The second is operational ("do I need MFA?"). The third is adversarial ("what about managed identities?"). Each appears below.

Closing#

Read the section 1 vignette again. The 2026 tenant where alice@contoso.com is Global Administrator for exactly one hour, with an audit log so complete the SOC 2 auditor signs it without questions, is not a configuration choice. It is the visible behaviour of an identity system whose role-assignment object carries one more field than the 2015 version did. Standing admin did not retire because operators got more disciplined. Standing admin retired because the data model grew a second state.

The forty years between Saltzer and Schroeder's 1975 paper and the 2015 Azure AD PIM Preview were not lost time. UNIX sudo, Kerberos delegation, DACLs, AD groups, MIM PAM, Pass-the-Hash v1 and v2, the Securing Privileged Access roadmap -- each built up the structural understanding that least privilege required a temporal mechanism, not just a static one, and that the temporal mechanism had to live on the assignment object itself, not on the group, the credential, the session, or any indirection through a separate forest. The single new field on the role-assignment object is what those forty years were preparing.

What remains undone is the application-identity boundary. The same role-assignment object Microsoft retrofitted to gate user activation does not yet gate the managed identity attached to a Function App. The IMDS endpoint at 169.254.169.254 is the canonical 2026 bypass path that proves it. Closing that gap, when it comes, will not be a patch to the existing eligible/active state machine. It will be the next chapter -- the one where the state machine learns to apply to a principal that cannot perform an interactive MFA challenge, and the activation semantics are reinvented for the non-interactive case.

The story is not finished. But the first chapter -- the chapter where standing admin became visibly the anti-pattern it had always been -- is.