Entra ID Governance at Scale: Entitlement Management, Access Reviews, and Lifecycle Workflows

Most tenants treat identity governance as a portal you visit during an audit. That is how you end up with a contractor who still holds Owner on three production subscriptions, a security group whose membership nobody can explain, and 400 guest accounts that last signed in 18 months ago. Access creep is not a one-time cleanup problem — it is a rate problem. Grants happen continuously through tickets and group adds; removal happens almost never. Governance at scale means building the machinery that revokes at the same rate access is granted: entitlement management (access packages) for time-bound self-service, lifecycle workflows for joiner-mover-leaver automation, and access reviews for periodic re-attestation. This guide wires all three together with Microsoft Graph, ties them back to Privileged Identity Management (PIM) and audit evidence, and closes with a worked joiner-mover-leaver design you can adapt.

The three features are complementary, not interchangeable, and confusing them is the most common design error. Entitlement management governs requested access — the analyst who needs the BI workspace fills a form, a manager approves, and the grant self-destructs in 180 days. Lifecycle workflows govern event-driven access — the joiner gets default groups on day one, the leaver loses everything the moment employeeLeaveDateTime passes, no ticket required. Access reviews govern residual access — the mover who changed teams but kept an old group, or the manual grant made outside any package, gets re-attested on a schedule with a deny-by-default outcome. Miss any one of the three and a whole class of access decay slips through.

Everything here requires Microsoft Entra ID Governance (or the broader Entra Suite) licensing for the principals being governed — entitlement management, lifecycle workflows, and recurring reviews are not in the base P2 SKU. Get licensing settled before you design, because the feature you scope to 9,000 employees is the feature you must license for 9,000 employees. By the end you will be able to design catalogs and access packages with real policies, stand up JML workflows with the documented built-in tasks, schedule enforcing access reviews of every object type, model separation of duties as a preventive gate, integrate PIM so privilege is time-boxed twice over, and prove all of it ran from AuditLogs rather than assuming it from config state.

What problem this solves

The pain is quantifiable and it always shows up in the same three places: the audit finding, the incident, and the offboarding gap.

The audit finding is a SOX or ISO 27001 auditor asking “who has access to the payment system, who approved it, when was it last reviewed, and prove access is removed when someone leaves.” If your answer is a spreadsheet a human maintains, you fail — a manually maintained list is a detective control at best and stale the moment it is exported. Auditors increasingly demand preventive controls: not “we caught the toxic combination in a quarterly review” but “the toxic combination was structurally impossible to grant.” Entitlement management’s separation-of-duties gate is exactly that preventive control, and access reviews are the recurring re-attestation on top of it.

The incident is a compromised or malicious account with standing privilege. A contractor account with permanent Owner, phished on a Tuesday, is a breach on Tuesday. The mitigation is not detection — it is not having standing privilege to steal in the first place. Governance delivers access as PIM-eligible rather than active, so a compromised account that has not activated holds nothing, and even an activated session is time-boxed to hours.

The offboarding gap is the leaver who departs Friday and still has VPN, email, and three SaaS seats on Monday. Manual offboarding via a ticket queue is slow, error-prone, and invisible to audit. Lifecycle workflows fire on the HR-driven leave date and de-provision in real time — disable the account, strip groups and licenses, revoke refresh tokens — with a run history you can point an auditor at.

Who hits this: every regulated organization (finance, healthcare, government), every company past a few hundred employees where central IT cannot personally know who should have what, and every tenant with a large guest population from partner collaboration. The larger the tenant, the more the rate mismatch between granting and revoking dominates, and the more the machinery matters.

To frame the whole field, here is the failure-mode map — every governance gap, what it looks like in production, and the primary control that closes it:

The mental shift: stop asking “who has access?” Start asking “who has access, granted by whom, justified how, expiring when, and last reviewed on what date?” If you cannot answer all five from a query, you do not have governance — you have a list.

Learning objectives

By the end of this article you can:

• Distinguish entitlement management, access reviews, and lifecycle workflows by the kind of access decay each one closes, and combine all three into a coherent program.
• Design catalogs, access packages, resource roles, and assignment policies — including delegation to resource owners, multi-stage approval, verified-ID requirements, and time-bound expiration — with real Microsoft Graph configuration.
• Enforce separation of duties as a preventive request-time gate using incompatible access packages and groups, in both directions.
• Configure auto-assignment policies so access follows a user attribute rule with no request at all, and know when that beats a request policy.
• Schedule access reviews of groups, applications, directory/PIM roles, and access packages — choosing reviewers, recurrence, decision helpers, non-response defaults, and auto-apply — so a review enforces rather than merely reports.
• Build joiner, mover, and leaver lifecycle workflows with the documented built-in taskDefinitionId tasks, correct triggers and scope, and custom task extensions for systems Graph cannot reach.
• Integrate governance with PIM so privileged access is delivered as expiring eligibility on a PIM-enabled group, and reviewed as eligibility rather than active membership.
• Onboard external partners with connected organizations so B2B guests flow through governed catalogs, and prove the whole machine ran from AuditLogs and per-cycle decision exports.

Prerequisites & where this fits

You should already understand core Entra ID: users, groups (security and Microsoft 365), enterprise applications and app roles, directory roles, and the difference between P1 and P2. You should be comfortable with Microsoft Graph PowerShell (Connect-MgGraph, the Microsoft.Graph.Identity.Governance module) and reading JSON/@odata.type payloads, because the portal cannot express everything governance can and IaC-style repeatability lives in Graph. Familiarity with PIM for roles and groups is assumed at the level of “eligible vs active, activation with justification” — this article uses PIM but does not re-teach it.

This sits at the top of the identity governance stack. It assumes the primitives from Privileged Identity Management and PAM Architecture: Just-in-Time Access at Scale (this article delivers governed access into PIM), and it is the operational sibling of Zero Trust on Microsoft Entra: Conditional Access + PIM, Step by Step — governance decides what a principal may hold; Conditional Access decides under what conditions they may use it. For external identities it builds directly on Entra External ID B2B and Cross-Tenant Access: Guest Collaboration, Direct Connect, and Trust Settings Done Right. Governance is one pillar of the broader Zero Trust Architecture Blueprint: Identity, Network, and Data Pillars.

A quick map of who owns and confirms each control, so you route work to the right team:

Before any config, install the module and connect with the least-privilege scopes governance actually needs — four scopes cover almost everything below:

Install-Module Microsoft.Graph.Identity.Governance -Scope CurrentUser
Connect-MgGraph -Scopes @(
  "EntitlementManagement.ReadWrite.All",   # catalogs, packages, policies, assignments
  "AccessReview.ReadWrite.All",            # access review definitions and decisions
  "LifecycleWorkflows.ReadWrite.All",      # JML workflows, tasks, runs
  "RoleManagement.ReadWrite.Directory"     # PIM eligible role/group assignments
)

Core concepts

Six mental models make every later section obvious. Read these once; the rest is application.

Entitlement management is a hierarchy: catalog → resource → resource role → access package → policy. A catalog is a container of governed resources plus a delegation boundary — a resource owner manages their catalog without tenant-wide admin. A resource (a group, an app, a SharePoint site) is added to the catalog. Each resource exposes resource roles (group membership, an app role like “Reader”, a site permission level). An access package bundles specific resource roles into one requestable unit. A policy on the package defines who can request it, who approves, and how long the grant lasts. The policy is where governance lives; the package without a policy is inert.

Access packages come in two flavours: request policies and auto-assignment policies. A request policy is self-service — a user (or a request on their behalf) asks, an approver decides, and the grant is time-bound. An auto-assignment policy has no request at all — it is a membership rule (department -eq 'Finance') and every matching user is automatically granted the package’s roles, losing them when they no longer match. Request policies fit discretionary access; auto-assignment fits birthright access that should track an attribute.

Access reviews are a scope, reviewers, and settings. An accessReviewScheduleDefinition reviews a scope (a group’s members, an app’s assigned users, a role’s members, an access package’s assignments), assigns reviewers (owners, managers, the users themselves, or named people), and applies settings (recurrence, duration, decision helpers, and — critically — what happens on non-response). The two settings that turn a review from a survey into a control are autoApplyDecisionsEnabled and defaultDecision; without them, “remove” decisions rot in a report nobody actions.

Lifecycle workflows are a trigger, an execution scope, and ordered tasks. A workflow has a trigger (a time offset relative to an attribute like employeeHireDate or employeeLeaveDateTime, or an on-demand run), an execution scope (a rule selecting which users it applies to), and an ordered list of tasks referenced by stable taskDefinitionId GUIDs. Categories are joiner, mover, and leaver; the same task (e.g. “Add user to groups”) can appear in multiple categories.

PIM is orthogonal and stacks on top. Reviews and packages govern which roles a person can hold; PIM governs when they hold them. The clean pattern is that governance makes someone a member of a PIM-enabled group, and that group is eligible (not active) for a privileged role. Governance controls group membership; PIM controls activation. Two expirations then stack — eligibility (governed, months) and activation (PIM, hours).

Connected organizations extend all of this to partners. A connected organization is a registered external tenant (or domain) whose users may be invited into your catalogs. It lets an access package’s requestor scope include “users from partner X’s tenant” without opening self-service to the entire internet, and it makes the catalog the lifecycle boundary for those guests.

The vocabulary in one table

Pin down every moving part before the deep sections. The glossary repeats these for lookup; this is the mental model side by side:

Which control for which decay — the routing table

The single most useful decision you make is which of the three features owns a given access problem. Get this wrong and you build the machine but point it at the wrong door:

Design catalogs, access packages, and policies

Entitlement management’s hierarchy exists for one reason: to let a business domain own its own access without central IT in the loop for every request. The biggest design error is one giant catalog owned by central IT — that recreates the ticket bottleneck you are trying to kill. Build catalogs per business domain (Finance, Engineering, Data Platform) and delegate ownership to those teams.

Catalogs and delegation

A catalog carries a delegation boundary. Users granted the Catalog owner role manage resources and packages inside it; Catalog reader can view. Critically, adding a directory role as a resource, or governing privileged resources, may require the actor to hold a matching directory role — you cannot delegate away more than you hold.

# Catalog scoped to a business domain, delegable to its owners
$catalog = New-MgEntitlementManagementCatalog -BodyParameter @{
  displayName         = "Data Platform"
  description         = "Governed access for the data platform domain"
  isExternallyVisible = $false   # internal only; flip to $true for B2B sharing via connected orgs
}

# Add a Microsoft Entra group as a governed resource in the catalog
New-MgEntitlementManagementResourceRequest -BodyParameter @{
  requestType = "AdminAdd"
  catalog     = @{ id = $catalog.Id }
  resource    = @{
    originId     = "f3f9a4d2-0000-0000-0000-000000000001"   # group objectId
    originSystem = "AadGroup"
  }
}

The catalog design choices and their consequences:

Resources and resource roles

Once a resource is in the catalog, you attach one or more of its resource roles to an access package. For a group the role is membership; for an app it is a specific app role (e.g. “Reports.Read”); for a SharePoint site it is a permission level. This is the granularity control — a package can grant “member of group X and the Reader app role on app Y and Contribute on site Z” as one unit.

Access packages and assignment policies

Create the package, then bind a policy. The policy is where expiration, requestApprovalSettings, and requestorSettings live — these are not optional decorations, they are the control.

$ap = New-MgEntitlementManagementAccessPackage -BodyParameter @{
  displayName = "Data Platform - Analyst (read)"
  description = "Read access to the data lake and BI workspace"
  catalog     = @{ id = $catalog.Id }
}

New-MgEntitlementManagementAssignmentPolicy -BodyParameter @{
  displayName   = "Analyst - 180 day, manager approval"
  accessPackage = @{ id = $ap.Id }
  # Who may request: all members (scope can be narrowed to specific groups or connected orgs)
  requestorSettings = @{
    enableTargetsToSelfAddAccess    = $true
    enableTargetsToSelfRemoveAccess = $true
    allowCustomAssignmentSchedule   = $true
    onBehalfRequestorsAllowed       = $false
  }
  # Approval: single-stage, the requestor's manager, justification required, auto-deny after 7 days
  requestApprovalSettings = @{
    isApprovalRequiredForAdd = $true
    stages = @(
      @{
        durationBeforeAutomaticDenial   = "P7D"
        isApproverJustificationRequired = $true
        primaryApprovers = @(
          @{ "@odata.type" = "#microsoft.graph.requestorManager"; managerLevel = 1 }
        )
      }
    )
  }
  # Time-bound: access expires, forcing re-request
  expiration = @{ type = "afterDuration"; duration = "P180D" }
}

The expiration block is the antidote to access creep. With afterDuration set to P180D, every grant self-destructs in 180 days; if the analyst still needs it, they re-request and a manager re-approves. No standing analyst access exists by default. The expiration options:

The requestor-settings knobs that shape self-service:

Approvals, separation of duties, and expiration

Two policy capabilities turn a request form into a control: multi-stage approval and separation of duties.

Multi-stage approval

A single stages object is one approval hop. Add a second object to the array to chain independent approvers — use it when the resource owner and the requestor’s manager must both sign off, or when a security review follows a business approval. Each stage has its own timeout, its own approvers, and optional escalation.

# Two-stage approval: manager first, then the resource owner, with escalation on stage 2
requestApprovalSettings = @{
  isApprovalRequiredForAdd = $true
  stages = @(
    @{  # Stage 1 — requestor's manager
      durationBeforeAutomaticDenial   = "P3D"
      isApproverJustificationRequired = $true
      primaryApprovers = @(
        @{ "@odata.type" = "#microsoft.graph.requestorManager"; managerLevel = 1 }
      )
    }
    @{  # Stage 2 — named resource owner, escalate to a backup if idle
      durationBeforeAutomaticDenial   = "P4D"
      isApproverJustificationRequired = $true
      isEscalationEnabled             = $true
      escalationTimeInMinutes         = 1440
      primaryApprovers = @(
        @{ "@odata.type" = "#microsoft.graph.singleUser"; userId = "1111...owner" }
      )
      escalationApprovers = @(
        @{ "@odata.type" = "#microsoft.graph.singleUser"; userId = "2222...backup" }
      )
    }
  )
}

The approver types and when each fits:

Approval-stage settings that matter beyond who approves:

Separation of duties (SoD)

Separation of duties blocks toxic combinations at request time, before the grant exists. If holding both “Vendor Onboarding” and “Payment Approval” enables fraud, mark them incompatible: a user assigned to one cannot even request the other. This is far stronger than a detective control in a SIEM — the conflicting access never gets granted, so there is no window of exposure to detect. The difference between a guardrail and an alarm.

# Mark another access package as incompatible with this one (SoD)
New-MgEntitlementManagementAccessPackageIncompatibleAccessPackageByRef `
  -AccessPackageId $paymentApprovalPkgId `
  -BodyParameter @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages/$vendorOnboardingPkgId"
  }

# You can also make membership of a security group incompatible with a package
New-MgEntitlementManagementAccessPackageIncompatibleGroupByRef `
  -AccessPackageId $paymentApprovalPkgId `
  -BodyParameter @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/groups/$contractorsGroupId"
  }

Two subtleties decide whether SoD actually holds:

• Reciprocity. Marking A incompatible with B blocks requesting B while holding A. To block the reverse (requesting A while holding B) you also add the mirror reference on the other package. Configure both directions or the gate is one-way.
• Existing holders. SoD is preventive — it blocks new requests. Users who already hold both packages are not auto-removed; resolve them with a one-time targeted review, not bulk deletion, so you do not strip access someone legitimately needs.

Auto-assignment: access that follows an attribute

Some access is birthright — every Finance employee should have the Finance apps, full stop, with no request form. That is an auto-assignment policy: instead of requestorSettings, it carries a specificAllowedTargets membership rule, and every user matching the rule is granted the package’s roles automatically, losing them when they stop matching. There is no approval because there is no request — the rule is the approval.

New-MgEntitlementManagementAssignmentPolicy -BodyParameter @{
  displayName   = "Finance staff - birthright apps (auto)"
  accessPackage = @{ id = $financeAppsPkgId }
  # Auto-assignment: a filter over user attributes, no request/approval
  specificAllowedTargets = @(
    @{
      "@odata.type" = "#microsoft.graph.attributeRuleMembers"
      membershipRule = "(user.department -eq `"Finance`") and (user.employeeType -eq `"Employee`")"
    }
  )
  automaticRequestSettings = @{
    requestAccessForAllowedTargets = $true
    removeAccessWhenTargetLeavesAllowedTargets = $true   # de-provision when the rule stops matching
    gracePeriodBeforeAccessRemoval = "P7D"               # keep access N days after they fall out
  }
  expiration = @{ type = "noExpiration" }   # governed by the rule, not a timer
}

Request policy vs auto-assignment, decided by the nature of the access:

The removeAccessWhenTargetLeavesAllowedTargets flag is what makes auto-assignment a governance control rather than a one-way grant: when the mover’s department changes away from Finance, the package (and its roles) are removed after the grace period — an automatic, attribute-driven de-provision that complements the mover lifecycle workflow.

Automate joiner-mover-leaver with lifecycle workflows

Access packages handle requested and attribute-driven access. Lifecycle workflows handle event-driven access tied to employment milestones — the joiner who needs default groups on day one, and far more importantly, the leaver who must lose everything the moment they depart.

A workflow has a trigger (a time offset relative to an attribute like employeeHireDate or employeeLeaveDateTime), an execution scope (a rule selecting which users it applies to), and an ordered list of tasks referenced by stable taskDefinitionId GUIDs. The attribute values must actually be populated — usually by HR-driven inbound provisioning (Workday, SuccessFactors) or Entra Connect — or the workflow has nothing to fire on.

The leaver workflow — real-time offboard

The highest-value workflow. It fires on the employee leave date and de-provisions cleanly: disable, strip groups and licenses, revoke tokens. These GUIDs are the documented built-in task definitions.

New-MgIdentityGovernanceLifecycleWorkflow -BodyParameter @{
  displayName  = "Leaver - real-time offboard"
  description  = "Disable, strip groups/licenses, revoke tokens on departure"
  category     = "leaver"
  isEnabled    = $true
  executionConditions = @{
    "@odata.type" = "#microsoft.graph.identityGovernance.triggerAndScopeBasedConditions"
    scope = @{
      "@odata.type" = "#microsoft.graph.identityGovernance.ruleBasedSubjectSet"
      rule = "(department -eq 'Engineering')"
    }
    trigger = @{
      "@odata.type" = "#microsoft.graph.identityGovernance.timeBasedAttributeTrigger"
      timeBasedAttribute = "employeeLeaveDateTime"
      offsetInDays       = 0                 # fire exactly on the leave date
    }
  }
  tasks = @(
    @{ category = "leaver"; displayName = "Disable user account"; isEnabled = $true
       taskDefinitionId = "1dfdfcc7-52fa-4c2e-bf3a-e3919cc12950"; arguments = @() }
    @{ category = "leaver"; displayName = "Remove user from all groups"; isEnabled = $true
       taskDefinitionId = "b3a31406-2a15-4c9a-b25b-a658fa5f07fc"; arguments = @() }
    @{ category = "leaver"; displayName = "Remove all licenses for user"; isEnabled = $true
       taskDefinitionId = "8fa97d28-3e52-4985-b3a9-a1126f9b8b4e"; arguments = @() }
    @{ category = "leaver"; displayName = "Revoke all refresh tokens for user"; isEnabled = $true
       taskDefinitionId = "509589a4-0466-4471-829e-49c5e502bdee"; arguments = @() }
  )
}

Order matters: revoke tokens after disabling and stripping access, so an in-flight session cannot re-acquire anything before the tokens are killed. The built-in task catalogue you will actually use:

Treat the GUIDs above as the reference set, but confirm the exact taskDefinitionId in the current Microsoft docs before pasting into production — a handful are versioned and a wrong GUID makes the task silently invalid. The three leaver GUIDs and the two joiner GUIDs shown in the code blocks are the stable, commonly used ones.

The joiner workflow — ready before day one

The joiner side triggers ahead of the hire date so accounts are ready on day one, not provisioned at 9 a.m. while the new hire waits. Set offsetInDays = -7 against employeeHireDate.

executionConditions = @{
  "@odata.type" = "#microsoft.graph.identityGovernance.triggerAndScopeBasedConditions"
  scope = @{
    "@odata.type" = "#microsoft.graph.identityGovernance.ruleBasedSubjectSet"
    rule = "(employeeType -eq 'Employee')"
  }
  trigger = @{
    "@odata.type" = "#microsoft.graph.identityGovernance.timeBasedAttributeTrigger"
    timeBasedAttribute = "employeeHireDate"
    offsetInDays       = -7                  # provision a week before start
  }
}
tasks = @(
  @{ category = "joiner"; displayName = "Add to default groups"; isEnabled = $true
     taskDefinitionId = "22085229-5809-45e8-97fd-270d28d66910"
     arguments = @( @{ name = "groupID"; value = "aaaa-...all-staff" } ) }
  @{ category = "joiner"; displayName = "Send welcome email"; isEnabled = $true
     taskDefinitionId = "70b29d51-b59a-4773-9280-8841dfd3f2ea"; arguments = @() }
)

The mover workflow — the subtle one

The mover is the workflow people forget, and the one reviews were invented to backstop. A mover changed department, title, or manager; some access should follow them (new team’s groups), some should be stripped (old team’s groups), and much is invisible to any rule. Mover workflows trigger on a change to an attribute rather than a fixed date, so the trigger model differs — you scope by the attribute change and run on-demand or scheduled reconciliation, then let an access review catch the residue the workflow’s known-group list cannot.

Triggers and their attributes, side by side:

Execution-scope rule attributes (a subset — the rule uses the same filter syntax as dynamic groups):

Custom task extensions for systems Graph cannot reach

Built-in tasks cover Entra-native objects. For anything external — de-provisioning a Salesforce seat, releasing a phone number, archiving a mailbox via a third party, notifying a ticketing system — use the Run a Custom Task Extension task, which calls an Azure Logic App. Two execution modes matter:

• Launch and continue — fire the Logic App, do not wait. For fire-and-forget side effects where downstream success does not gate later tasks.
• Launch and wait — block the workflow on the Logic App’s callback (up to the configured timeout). Use when downstream success must gate a later task, e.g. confirm the external system disabled the account before you delete the Entra object.

Keep the workflow declarative and push all integration logic into the Logic App — that keeps the JML model readable and the vendor-specific glue in one place.

Recurring access reviews for groups, apps, roles, and packages

Lifecycle workflows catch the clean leaver. They do not catch the mover who changed teams but kept their old group, or access granted manually outside any package. That residue is what access reviews re-attest on a schedule.

A review is an accessReviewScheduleDefinition: a scope (what is reviewed), reviewers (who decides), and settings (recurrence, duration, decision helpers, and what happens to non-responses). The two settings that make a review a control rather than a survey are autoApplyDecisionsEnabled and defaultDecision — without auto-apply, “remove” decisions sit in a report nobody actions.

Review of a group’s membership

$params = @{
  displayName             = "Quarterly - Data Platform Admins group"
  descriptionForAdmins    = "Re-attest membership of the data platform admin group"
  descriptionForReviewers = "Confirm each member still needs admin on the data platform."
  scope = @{
    "@odata.type" = "#microsoft.graph.accessReviewQueryScope"
    query     = "/groups/02f3bafb-448c-487c-88c2-5fd65ce49a41/transitiveMembers"
    queryType = "MicrosoftGraph"
  }
  reviewers = @(
    @{ query = "/groups/02f3bafb-448c-487c-88c2-5fd65ce49a41/owners"; queryType = "MicrosoftGraph" }
  )
  settings = @{
    mailNotificationsEnabled        = $true
    reminderNotificationsEnabled    = $true
    justificationRequiredOnApproval = $true
    recommendationsEnabled          = $true    # sign-in-based approve/deny hints (decision helper)
    instanceDurationInDays          = 14
    autoApplyDecisionsEnabled       = $true     # ENFORCE the outcome
    defaultDecisionEnabled          = $true
    defaultDecision                 = "Deny"    # no response = revoke (deny-by-default)
    recurrence = @{
      pattern = @{ type = "absoluteMonthly"; dayOfMonth = 1; interval = 3 }   # quarterly
      range   = @{ type = "noEnd"; startDate = "2026-07-01" }
    }
  }
}
New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter $params

defaultDecision = "Deny" is the load-bearing choice. A reviewer who ignores the review removes the access by inaction. That is the only model that scales: it makes keeping access the deliberate act, not losing it. For lower-stakes reviews you may prefer "None" (no change on silence), but for privileged groups, deny-by-default is correct.

What you can review, and the scope for each

Each object type has a distinct scope query. Getting the query right is most of the work:

Reviewer, recurrence, and decision-helper reference

Who reviews:

Recurrence patterns:

Decision helpers and non-response behaviour — the settings that make a review scale:

For application access reviews, scope to the app’s assigned users; for privileged role reviews, prefer reviewing the PIM-eligible assignments (see the PIM section) over active role members — otherwise you review only who is currently active, missing everyone who is merely eligible.

Govern guests and external access

Guests are the highest-decay population in any tenant — project-based, rarely offboarded by the inviting employee, and invisible to HR-driven lifecycle workflows because they have no employeeLeaveDateTime. Three controls contain them: connected organizations for governed onboarding, inactive-guest reviews for decay, and externally visible catalogs for automatic lifecycle boundaries.

Connected organizations — governed B2B onboarding

A connected organization registers a partner tenant (or domain) so its users can request packages from your externally visible catalogs, with the partner’s sponsors as approvers. This is what lets you offer self-service to known partners without opening the door to any guest from any tenant.

# Register a partner tenant as a connected organization
New-MgEntitlementManagementConnectedOrganization -BodyParameter @{
  displayName = "Contoso Partners"
  description = "External auditors and co-dev partner"
  state       = "configured"
  identitySources = @(
    @{
      "@odata.type" = "#microsoft.graph.azureActiveDirectoryTenant"
      tenantId    = "contoso.onmicrosoft.com-tenant-guid"
      displayName = "Contoso"
    }
  )
}

You then scope an access package’s requestors to that connected organization, and set its sponsors as the approvers, so external requests are governed exactly like internal ones.

Inactive-guest reviews

Scope a review to guests who have not signed in for a defined window using the inactive-users scope, and let the team owners decide. Auto-apply with deny-by-default so silence removes the stale guest.

$guestReview = @{
  displayName          = "Inactive guests on M365 groups (90d)"
  descriptionForAdmins = "Remove guest access to groups with no recent sign-in."
  instanceEnumerationScope = @{
    "@odata.type" = "#microsoft.graph.accessReviewQueryScope"
    query     = "/groups?`$filter=(groupTypes/any(c:c+eq+'Unified'))"
    queryType = "MicrosoftGraph"
  }
  scope = @{
    "@odata.type" = "#microsoft.graph.accessReviewInactiveUsersQueryScope"
    query            = "./members/microsoft.graph.user/?`$filter=(userType eq 'Guest')"
    queryType        = "MicrosoftGraph"
    inactiveDuration = "P90D"
  }
  reviewers = @( @{ query = "./owners"; queryType = "MicrosoftGraph" } )
  settings  = @{
    mailNotificationsEnabled  = $true
    instanceDurationInDays    = 7
    autoApplyDecisionsEnabled = $true
    defaultDecisionEnabled    = $true
    defaultDecision           = "Deny"
    recurrence = @{ pattern = @{ type = "absoluteMonthly"; dayOfMonth = 1; interval = 1 }
                    range = @{ type = "noEnd"; startDate = "2026-07-01" } }
  }
}
New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter $guestReview

Catalog as the lifecycle boundary

Combine an externally visible catalog with entitlement management’s external-user settings so guests provisioned through the catalog are auto-removed when their last access package assignment expires — closing the orphaned-guest gap by construction. The catalog, not a manual cleanup, becomes the lifecycle boundary for external identities.

The external-user removal behaviours a catalog offers:

For the full cross-tenant access model — inbound/outbound trust, MFA and compliant-device trust, and B2B direct connect — see Entra External ID B2B and Cross-Tenant Access: Guest Collaboration, Direct Connect, and Trust Settings Done Right.

Integrate with PIM for time-bound privilege

Reviews and packages govern which roles a person can hold. PIM governs when they hold them. For any high-value role, the assignment delivered by governance should be eligible, not active — the person activates just-in-time, with justification and a time box.

The clean pattern: an access package or lifecycle task makes someone a member of a PIM-enabled group, and that group is itself eligible (not active) for the privileged role. Governance controls group membership; PIM controls activation. Create the eligible group-to-member relationship via the privileged access group eligibility schedule request:

New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter @{
  accessId      = "member"                               # eligible as a member of the group
  principalId   = "aaaaaaaa-0000-0000-0000-000000000001" # the user
  groupId       = "bbbbbbbb-0000-0000-0000-000000000002" # PIM-enabled privileged group
  action        = "adminAssign"
  scheduleInfo  = @{
    startDateTime = (Get-Date).ToString("o")
    expiration    = @{ type = "afterDuration"; duration = "P90D" }   # eligibility itself expires
  }
  justification = "Quarterly eligible assignment via governance"
}

Two expirations now stack: eligibility expires in 90 days (governed, re-attested by a review), and each activation expires in hours (PIM policy). A compromised account that has not activated holds no standing privilege, and even an active session is time-boxed. Then run an access review over the eligible assignments themselves so eligibility does not become the new standing privilege — PIM exposes reviews for eligible role and group assignments precisely for this.

How governance and PIM divide responsibility:

The two-expiration stack, concretely:

For the full PIM design — role settings, activation policies, approval on activation, and PAM patterns — see Privileged Identity Management and PAM Architecture: Just-in-Time Access at Scale.

Licensing: what you must own before you design

Governance features are licensed per governed principal, and the license gates the feature, not just the admin. Design to what you can license.

The licensing rules that catch teams out:

Confirm before you build:

# What Governance-related service plans are enabled on the tenant's SKUs?
Get-MgSubscribedSku | Select-Object SkuPartNumber, `
  @{n='Enabled';e={$_.PrepaidUnits.Enabled}}, @{n='Consumed';e={$_.ConsumedUnits}}

Architecture at a glance

Picture the governance machine as three intake lanes feeding one directory, with PIM as a gate on the privileged lane and audit as a tap on the output. There is no single diagram because the value is in how the lanes interlock, not in a box chart — so walk it as a flow.

Lane one is event-driven (lifecycle workflows). The HR/HCM system is the source of truth for employment: it sets employeeHireDate, employeeLeaveDateTime, department, and manager via inbound provisioning. Those attributes are the triggers. Seven days before a hire date, the joiner workflow adds default groups and sends a welcome email; on the leave date, the leaver workflow disables the account, strips groups and licenses, and revokes tokens; on an attribute change, the mover workflow reconciles known groups. Anything external (SaaS seat, phone number) is a custom task extension calling a Logic App. This lane needs no human in the loop — the employment event is the authorization.

Lane two is request-driven (entitlement management). A user opens the My Access portal, requests an access package from a delegated catalog, and one or more approval stages decide. Separation-of-duties gates block toxic combinations at this exact point — the request for the incompatible package never completes. The grant is time-bound; it self-destructs on expiration, forcing a re-request. Partners flow through the same lane via connected organizations and externally visible catalogs, with sponsors as approvers.

Lane three is attribute-driven (auto-assignment). Birthright access — the Finance apps for Finance staff — is granted by a membership rule with no request, and removed when the rule stops matching. This lane overlaps the mover workflow deliberately: when someone leaves Finance, both the auto-assignment removal and the mover workflow act, and the belt-and-suspenders is intentional.

The privileged gate (PIM). Where a lane would grant a privileged role, it instead grants membership of a PIM-enabled group that is merely eligible for the role. The user must activate through PIM — justification, MFA, a time box — so no standing privilege exists. Eligibility itself expires and is re-attested.

The re-attestation loop and the audit tap (access reviews + AuditLogs). Over all three lanes, recurring access reviews re-attest what the lanes left behind — the mover’s residual groups, the manual grant outside any package, the eligible assignment that outlived its need — with deny-by-default and auto-apply so silence removes access. Every action any lane takes lands in AuditLogs (workflow runs, package grants, review decisions), which is the evidence tap: you prove the machine ran from the log, never from the config. Read left to right — HR event / user request / attribute match on the left, a governed and time-boxed directory in the middle, PIM gating privilege, and an audit trail on the right — and the whole system is one picture.

Real-world scenario

A 9,000-employee insurer ran SOX and faced a finding that hits every regulated firm eventually. Claims adjusters could request the “Claims Write” access package and the “Payment Release” package, and 14 people held both. That combination let one person file and pay a fraudulent claim end to end. The external auditor wanted not just the toxic pairs removed, but a preventive control proving the combination could never recur — a quarterly cleanup spreadsheet was explicitly rejected as a detective control.

The platform team’s first instinct was a Sentinel rule to alert when both assignments coexisted. That failed the auditor for the right reason: it detects the violation after the access exists, leaving an exploitable window. The fix moved the control to request time. They marked the two packages mutually incompatible in entitlement management, so the second request is blocked — no toxic state is reachable. They then layered a quarterly review (deny-by-default) over the Payment Release package as recurring re-attestation on top of the preventive gate.

# Preventive SoD: Payment Release becomes unrequestable for anyone holding Claims Write
New-MgEntitlementManagementAccessPackageIncompatibleAccessPackageByRef `
  -AccessPackageId $paymentReleaseId `
  -BodyParameter @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages/$claimsWriteId"
  }

The reciprocal reference was added on the Claims Write package so the block holds in both directions. The 14 existing dual-holders were resolved through a one-time targeted review rather than bulk removal, preserving the access each legitimately needed. But the finding also exposed two adjacent gaps the auditor then probed. First, offboarding: three of the 14 had left the company months earlier and their accounts were still enabled — manual offboarding via a ticket queue had missed them. The team stood up a leaver workflow on employeeLeaveDateTime (disable, strip groups/licenses, revoke tokens) so departure de-provisioning stopped depending on a human remembering. Second, the “Payment Release” package granted an app role that was effectively privileged; the team re-plumbed it so the grant delivered membership of a PIM-enabled group that was eligible for the role, with activation requiring approval and MFA — turning standing capability into just-in-time.

The numbers told the story at the next audit. Standing dual-holders: zero, structurally impossible. Mean time to de-provision a leaver: from “up to weeks, ticket-dependent” to under an hour, on the leave date, with a run-history record per user. Reviewer effort on the Payment Release review dropped because the decision helper flagged the two members who had not signed in in 60 days, and deny-by-default removed a third who ignored the review entirely. The auditor signed off on the incompatibility configuration, the leaver workflow run history, and the review schedule as a combined preventive-and-detective control. The lesson the team carried forward: SoD belongs at the request gate, not in the SIEM, and offboarding belongs on the HR trigger, not in a ticket queue. A guardrail that prevents the state beats an alarm that reports it.

Advantages and disadvantages

The honest trade-off before you commit a program:

Where each advantage matters most: preventive SoD is decisive in regulated finance/healthcare where auditors demand it; real-time leaver workflows matter most where high staff churn or contractor populations make manual offboarding untenable; PIM interplay is essential wherever a compromised admin account is the top risk; delegated catalogs pay off hardest in large tenants where central IT cannot know every access need. Conversely, a 200-person startup with clean HR data and few privileged roles may get 80% of the value from access packages with expiry plus a leaver workflow, and defer the rest.

Hands-on lab

A safe, end-to-end walk-through in a non-production tenant: a delegated catalog, an expiring access package with manager approval, a leaver lifecycle workflow (created disabled), an enforcing access review, then verification and teardown. Requires Entra ID Governance licensing on the tenant and the scopes from Prerequisites. Use throwaway test users.

Step 0 — Connect and create test objects.

Connect-MgGraph -Scopes @(
  "EntitlementManagement.ReadWrite.All","AccessReview.ReadWrite.All",
  "LifecycleWorkflows.ReadWrite.All","Group.ReadWrite.All","User.ReadWrite.All")

# A test group to govern, and a test user
$grp = New-MgGroup -DisplayName "LAB-DataPlatform-Analysts" -MailEnabled:$false `
  -MailNickname "lab-dp-analysts" -SecurityEnabled:$true
"Group: $($grp.Id)"

Expected: a group object id prints. Note it as $grp.Id.

Step 1 — Create a delegated catalog and add the group as a resource.

$cat = New-MgEntitlementManagementCatalog -BodyParameter @{
  displayName = "LAB - Data Platform"; description = "Lab catalog"; isExternallyVisible = $false }
New-MgEntitlementManagementResourceRequest -BodyParameter @{
  requestType = "AdminAdd"; catalog = @{ id = $cat.Id }
  resource = @{ originId = $grp.Id; originSystem = "AadGroup" } }
"Catalog: $($cat.Id)"

Expected: catalog id prints; the resource-add request completes. Validate: Get-MgEntitlementManagementCatalogResource -AccessPackageCatalogId $cat.Id lists the group.

Step 2 — Create an access package with a 30-day, manager-approval policy.

$pkg = New-MgEntitlementManagementAccessPackage -BodyParameter @{
  displayName = "LAB - Analyst read"; description = "Lab package"; catalog = @{ id = $cat.Id } }

New-MgEntitlementManagementAssignmentPolicy -BodyParameter @{
  displayName = "LAB - 30 day manager approval"; accessPackage = @{ id = $pkg.Id }
  requestorSettings = @{ enableTargetsToSelfAddAccess = $true; onBehalfRequestorsAllowed = $false }
  requestApprovalSettings = @{ isApprovalRequiredForAdd = $true
    stages = @( @{ durationBeforeAutomaticDenial = "P7D"; isApproverJustificationRequired = $true
      primaryApprovers = @( @{ "@odata.type"="#microsoft.graph.requestorManager"; managerLevel=1 } ) } ) }
  expiration = @{ type = "afterDuration"; duration = "P30D" } }
"Package: $($pkg.Id)"

Expected: package id prints. Validate: the package appears in the My Access portal for an in-scope user, showing “requires approval” and a 30-day duration.

Step 3 — Create a leaver workflow, disabled, for safe inspection.

New-MgIdentityGovernanceLifecycleWorkflow -BodyParameter @{
  displayName = "LAB - Leaver (disabled)"; description = "Lab only"; category = "leaver"
  isEnabled = $false                                        # created OFF so it cannot fire
  executionConditions = @{
    "@odata.type" = "#microsoft.graph.identityGovernance.triggerAndScopeBasedConditions"
    scope = @{ "@odata.type" = "#microsoft.graph.identityGovernance.ruleBasedSubjectSet"
               rule = "(department -eq 'LAB-NONEXISTENT')" }   # matches nobody
    trigger = @{ "@odata.type" = "#microsoft.graph.identityGovernance.timeBasedAttributeTrigger"
                 timeBasedAttribute = "employeeLeaveDateTime"; offsetInDays = 0 } }
  tasks = @(
    @{ category="leaver"; displayName="Disable user account"; isEnabled=$true
       taskDefinitionId="1dfdfcc7-52fa-4c2e-bf3a-e3919cc12950"; arguments=@() }
    @{ category="leaver"; displayName="Revoke all refresh tokens"; isEnabled=$true
       taskDefinitionId="509589a4-0466-4471-829e-49c5e502bdee"; arguments=@() } ) }

Expected: the workflow is created with isEnabled=$false and a scope matching nobody — doubly safe. Validate: Get-MgIdentityGovernanceLifecycleWorkflow -Filter "displayName eq 'LAB - Leaver (disabled)'" shows it disabled.

Step 4 — Create an enforcing access review of the group.

New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter @{
  displayName = "LAB - Analyst group review"
  descriptionForAdmins = "Lab"; descriptionForReviewers = "Confirm membership"
  scope = @{ "@odata.type"="#microsoft.graph.accessReviewQueryScope"
    query = "/groups/$($grp.Id)/transitiveMembers"; queryType = "MicrosoftGraph" }
  reviewers = @( @{ query = "/groups/$($grp.Id)/owners"; queryType = "MicrosoftGraph" } )
  settings = @{ mailNotificationsEnabled=$true; recommendationsEnabled=$true
    instanceDurationInDays=3; autoApplyDecisionsEnabled=$true
    defaultDecisionEnabled=$true; defaultDecision="Deny"
    recurrence = @{ pattern=@{ type="absoluteMonthly"; dayOfMonth=1; interval=3 }
                    range=@{ type="numbered"; startDate="2026-07-01"; numberOfOccurrences=1 } } } }

Expected: a review definition is created (one occurrence, so it self-terminates). Validate: Get-MgIdentityGovernanceAccessReviewDefinition -Filter "displayName eq 'LAB - Analyst group review'" returns it with autoApplyDecisionsEnabled = true and defaultDecision = Deny.

Step 5 — Verify the machinery (read-only).

# Packages and policies exist and are time-bound
Get-MgEntitlementManagementAccessPackage -Filter "displayName eq 'LAB - Analyst read'" |
  Select-Object DisplayName, Id
# Workflow is present and safely disabled
(Get-MgIdentityGovernanceLifecycleWorkflow -Filter "displayName eq 'LAB - Leaver (disabled)'").IsEnabled
# Review enforces (auto-apply + deny default)
$def = Get-MgIdentityGovernanceAccessReviewDefinition -Filter "displayName eq 'LAB - Analyst group review'"
$def.Settings | Select-Object AutoApplyDecisionsEnabled, DefaultDecision

Expected: package prints; workflow IsEnabled is False; review shows True / Deny.

Step 6 — Teardown. Remove everything you created, in reverse order.

# Delete the review, workflow, package, catalog, and test group
Remove-MgIdentityGovernanceAccessReviewDefinition -AccessReviewScheduleDefinitionId $def.Id
$wf = Get-MgIdentityGovernanceLifecycleWorkflow -Filter "displayName eq 'LAB - Leaver (disabled)'"
Remove-MgIdentityGovernanceLifecycleWorkflow -LifecycleWorkflowId $wf.Id
Remove-MgEntitlementManagementAccessPackage -AccessPackageId $pkg.Id
Remove-MgEntitlementManagementCatalog -AccessPackageCatalogId $cat.Id
Remove-MgGroup -GroupId $grp.Id
"Torn down."

Expected: each removal returns without error and “Torn down.” prints. Validate: re-running any Get-...-Filter returns nothing.

Common mistakes & troubleshooting

The failure modes that actually bite in production — symptom, root cause, how to confirm, and the fix.

Three expanded root-causes for the ones that waste the most time:

Leaver workflow never fires (#2). The most common governance disappointment. The workflow is enabled, scoped correctly, and still does nothing — because the trigger attribute is empty. Time-based triggers fire off employeeLeaveDateTime/employeeHireDate, and if HR provisioning never writes those attributes, there is no event. Confirm with Get-MgUser -UserId <id> -Property employeeLeaveDateTime,employeeHireDate; if null, the fix is in the provisioning mapping (Workday/SuccessFactors attribute flow) or Entra Connect, not in the workflow.

Review completed but nobody lost access (#6/#7). A review can finish and change nothing in two ways: auto-apply is off (decisions are recorded but never enforced — the classic “report we email to nobody”), or the default decision is None so silence keeps access. Both feel like the review “ran.” Confirm both settings on the definition; for any privileged scope, autoApplyDecisionsEnabled = true and defaultDecision = Deny together are what make a review a control.

Privileged access still standing after governance (#13). Teams often grant a privileged app role or directory role directly through a package, achieving time-bound-but-still-standing access. The intended pattern delivers membership of a PIM-enabled group that is merely eligible; the user then activates through PIM. Confirm by checking whether the role assignment is active or eligible; the fix re-plumbs the package/task to grant group membership and moves the role relationship to PIM eligibility.

Best practices

• License first, design second. Confirm Entra ID Governance/Suite covers every governed principal — including guests — before you scope a feature to your whole workforce. A workflow you cannot license is a design you cannot ship.
• Split catalogs by business domain and delegate ownership. One catalog per domain (Finance, Engineering, Data Platform), owned by that team. A single central catalog recreates the ticket bottleneck governance exists to remove.
• Every request policy sets expiration. No perpetual grants. afterDuration (e.g. P180D) makes re-request the default and standing access the exception.
• Model toxic combinations as incompatible packages, in both directions. Preventive SoD at the request gate beats any SIEM alert. Add the reciprocal reference or the block is one-way.
• Reviews must enforce: autoApplyDecisionsEnabled = true and deny-by-default for privilege. A review without auto-apply is a survey; a review that keeps access on silence is theatre.
• Turn on decision helpers and reminders. recommendationsEnabled surfaces stale access; reminders and escalation stop a review stalling on one absent reviewer.
• Leaver workflow on employeeLeaveDateTime, in order: disable → strip → revoke. Revoke tokens last so an in-flight session cannot re-acquire access mid-teardown. Provision joiners ahead of the hire date.
• Back mover workflows with a review. The mover workflow strips known groups; a periodic review catches everything the rule cannot see.
• Deliver privileged access as PIM-eligible, never active. Governance controls membership of a PIM-enabled group; PIM controls activation. Then review the eligibility.
• Govern guests through connected orgs and catalog auto-removal. Make the catalog the lifecycle boundary so guests self-clean when their last assignment expires.
• Configure fallback and escalation on every approval and review. No control should stall because one person is on holiday.
• Prove it ran from AuditLogs, not config. An enabled workflow is not a workflow that ran; a scheduled review is not a review that applied. Verify from the log and export decisions per cycle.

Security notes

• Least-privilege Graph scopes and delegated roles. Grant EntitlementManagement.ReadWrite.All and friends only to the governance automation identity; delegate catalog ownership to domain teams so no one needs tenant-wide admin to run their own access. A delegated catalog owner cannot grant privilege they do not themselves hold — the boundary is real.
• Separation of duties is a security control, not just compliance. Incompatible packages structurally prevent one person from holding a fraud-enabling combination. This closes the exposure window entirely, unlike detection.
• Deny-by-default reviews are a containment mechanism. For privileged groups and eligible PIM assignments, non-response removes access — the safe failure mode. Reserve None for genuinely low-stakes reviews.
• Real-time leaver de-provisioning shrinks the breach window. Disabling and token-revocation on the leave date means a departed (or terminated-for-cause) employee loses access in minutes, not weeks — the difference between an orderly exit and an insider incident.
• PIM eligibility removes standing privilege. A compromised account that has not activated holds nothing worth stealing; even an activated session is time-boxed. Governance delivering eligibility (not active roles) is a core Zero Trust move — see Zero Trust on Microsoft Entra: Conditional Access + PIM, Step by Step.
• Protect the automation identity and the Logic Apps. The identity running governance Graph calls, and the Logic Apps behind custom task extensions, are high-value — secure them with managed identity, least-privilege, and monitoring, per Managed Identities Deep Dive: User-Assigned Identities, Federated Credentials, and RBAC Patterns for Azure Workloads.
• Break-glass accounts must be excluded and separately monitored. Governance workflows and reviews should never disable or strip your emergency-access accounts; exclude them explicitly and watch them, per Engineering Break-Glass Emergency Access Accounts in Entra ID: Exclusions, Hardening, and Tamper-Evident Monitoring.
• Audit evidence is a security asset. The per-decision review record (reviewedBy, decision, justification, timestamp) and workflow run history are your defensible answer to “prove access was removed / reviewed.” Export and retain them.

Cost & sizing

• Licensing dominates. Entra ID Governance (or the Entra Suite) is licensed per governed principal. If you scope lifecycle workflows and advanced reviews to your entire 9,000-person workforce, you license 9,000 principals — this is the single largest cost lever, so scope deliberately. In INR terms, budget by (per-user Governance list price) × (governed headcount, including active guests), and compare the standalone Governance add-on against the Entra Suite bundle if you also want Internet/Private Access or Verified ID.
• Guests count. External identities consuming governed catalogs fall under Microsoft’s external-user licensing model (MAU-based for customer scenarios); a large partner population is a real line item, not free.
• Logic Apps consumption. Custom task extensions run Azure Logic Apps — a small per-execution + connector cost. At leaver scale (say 300 departures/month, each firing two external de-provision actions) this is modest (low thousands of INR/month) but non-zero; use Consumption-tier Logic Apps and keep the workflow declarative.
• Compute is otherwise negligible. Entitlement management, reviews, and workflows are platform features — no VM or per-transaction Graph cost beyond your normal tenant. The “cost” is design and operational effort, front-loaded.
• The savings are in avoided incidents and audit hours. Preventing one standing-privilege breach or one failed SOX audit dwarfs the licensing. Real-time leaver de-provisioning also reclaims IT hours previously spent on manual offboarding tickets.

A rough monthly picture for the 9,000-employee insurer: Governance/Suite licensing for the governed workforce is the headline figure (negotiated per-user, so tenant-specific), plus a few thousand INR for Logic Apps behind external de-provisioning, plus normal Log Analytics ingestion for the AuditLogs you export as evidence. The controls themselves add no compute bill — the discipline is the investment.

Interview & exam questions

1. What is the difference between entitlement management, access reviews, and lifecycle workflows, and when do you use each? Entitlement management governs requested/attribute-driven access via access packages with policies (approval, expiry, SoD). Access reviews re-attest existing access on a schedule to remove creep and residue. Lifecycle workflows automate event-driven joiner-mover-leaver access on HR triggers. Use packages for discretionary and birthright access, workflows for employment-event provisioning/de-provisioning, and reviews for periodic re-certification of whatever the other two leave behind.

2. Walk the entitlement-management hierarchy. Catalog (container + delegation boundary) → resource (group/app/site added to the catalog) → resource role (membership, app role, permission level) → access package (a bundle of resource roles that is requestable) → assignment policy (who can request/get it, approval stages, and expiration). The policy is where governance lives; a package without a policy grants nothing.

3. How does separation of duties in entitlement management differ from a SIEM alert on toxic combinations? SoD is preventive and enforced at request time — a user holding an incompatible package cannot even request the conflicting one, so the toxic state is never reachable. A SIEM alert is detective — it fires after the access exists, leaving an exploitable window. SoD is a guardrail; the alert is an alarm. Auditors increasingly require the guardrail. Remember to configure both directions.

4. What two access-review settings turn a review from a report into a control? autoApplyDecisionsEnabled = true (decisions are enforced automatically at cycle end, not left in a report) and defaultDecision = Deny with defaultDecisionEnabled = true (non-response removes access). Together they make keeping access the deliberate act and losing it the default — the only model that scales for privileged scopes.

5. Design a leaver workflow. What triggers it, what tasks, in what order, and what’s the prerequisite? Trigger: time-based on employeeLeaveDateTime, offsetInDays = 0. Tasks in order: disable account → remove from all groups → remove all licenses → revoke all refresh tokens (revoke last so an in-flight session can’t re-acquire access). Prerequisite: employeeLeaveDateTime must be populated by HR-driven inbound provisioning, or nothing fires.

6. What is an auto-assignment policy and how does it differ from a request policy? An auto-assignment policy grants an access package’s roles to every user matching an attribute rule (e.g. department -eq 'Finance'), with no request and no approval — the rule is the gate — and removes access when the user stops matching (with an optional grace period). A request policy is self-service with approval stages and a timer-based expiry. Use auto-assignment for birthright access that tracks HR data; use request policies for discretionary access.

7. How do governance and PIM divide responsibility for a privileged role? Governance controls which role a person can hold and for how long they’re eligible — typically by making them a member of a PIM-enabled group that is eligible (not active) for the role, with the eligibility itself expiring and re-attested by a review. PIM controls when they actually hold it — activation with justification/MFA and an hours-long time box. Two expirations stack; no standing privilege exists.

8. A leaver workflow is enabled and correctly scoped but never runs. What’s the most likely cause and how do you confirm? The trigger attribute is empty. Time-based triggers fire off employeeLeaveDateTime; if HR provisioning never writes it, there is no event. Confirm with Get-MgUser -UserId <id> -Property employeeLeaveDateTime; if null, fix the provisioning attribute mapping or backfill.

9. How do you govern the lifecycle of B2B guests that have no employeeLeaveDateTime? Onboard them through connected organizations into an externally visible catalog (sponsor approval), give the package an expiration so access self-expires, run recurring inactive-guest reviews (deny-by-default) to catch decay, and configure the catalog’s external-user setting to remove/block the guest when their last assignment expires — making the catalog the lifecycle boundary. Constrain who can be invited with cross-tenant access settings.

10. Why review PIM-eligible assignments rather than only active role members? Because active membership shows only who is currently activated; the standing risk is everyone who is eligible and could activate. Reviewing only active members misses the population you most need to re-certify. PIM exposes reviews for eligible role and group assignments precisely so eligibility does not silently become the new standing privilege.

11. What is a custom task extension and when do you need one? A lifecycle-workflow task that calls an Azure Logic App, used to reach systems Graph cannot touch — de-provision a Salesforce seat, release a phone number, notify a ticketing system. It runs in “launch and continue” (fire-and-forget) or “launch and wait” (block on callback, up to timeout) mode; use “wait” when a later task depends on the external action completing. Up to 100 per tenant.

12. Which licensing is required for entitlement management and lifecycle workflows, and what’s the common trap? Microsoft Entra ID Governance (or the Entra Suite) — not base P1 or P2. The trap: the license is required per governed principal, not just the admin, so a workflow over 9,000 employees needs 9,000 Governance licenses, and guests in governed catalogs count too. Confirm licensing before designing scope.

These map to SC-300 (Identity and Access Administrator) — implement and manage identity governance (entitlement management, access reviews, PIM, entitlement lifecycle) — and touch SC-100 (Cybersecurity Architect) for the Zero Trust and least-privilege framing. Cert-mapping for revision:

Quick check

1. You need every Finance employee to automatically get the Finance apps, with no request form, and to lose them if they leave Finance. Which policy type, and which one flag makes the “lose them” part work?
2. A quarterly access review of a privileged group “completed” but no one lost access, even people who never responded. Name the two settings you check and their correct values for a privileged scope.
3. Two access packages, “Vendor Onboarding” and “Payment Approval”, must never be held together. What control do you use, and what is the one configuration step people forget?
4. Your leaver workflow is enabled and scoped to Engineering, but nobody is ever de-provisioned. What is the single most likely cause?
5. Governance made a user a member of a group that grants an app role, and the app role is privileged. What did you get wrong from a Zero-Trust standpoint, and what’s the fix?

Answers

1. An auto-assignment policy (attribute rule department -eq 'Finance', no request/approval). The flag that removes access when they no longer match is removeAccessWhenTargetLeavesAllowedTargets = true (optionally with a grace period).
2. autoApplyDecisionsEnabled must be true (otherwise decisions are recorded but never enforced — report-only) and defaultDecision must be Deny with defaultDecisionEnabled = true (otherwise non-response defaults to None and keeps access). For a privileged group, both together are required.
3. Separation of duties via incompatible access packages — mark each package incompatible with the other. The forgotten step is reciprocity: set the incompatible reference on both packages, or the block only works in one direction.
4. employeeLeaveDateTime is not populated on those users (the time-based trigger has no event to fire on). Fix the HR-driven inbound provisioning mapping that should write it. Confirm with Get-MgUser -Property employeeLeaveDateTime.
5. You delivered a privileged role as standing (active) access rather than eligibility. The fix: make the group a PIM-enabled group that is eligible (not active) for the role, so the user must activate through PIM (justification, MFA, time box) — and review the eligibility.

Glossary

• Entitlement management — the Entra ID Governance feature for self-service, policy-governed access via access packages.
• Catalog — a container of governed resources plus a delegation boundary; resource owners manage their catalog without tenant-wide admin.
• Resource / resource role — a group/app/site added to a catalog, and a specific role on it (membership, app role, permission level) that a package can grant.
• Access package — a bundle of resource roles that users request or are auto-assigned as one unit.
• Assignment policy — the policy on an access package defining who may request/get it, approval stages, and expiration; where governance actually lives.
• Request policy vs auto-assignment policy — request = self-service with approval and timer expiry; auto-assignment = attribute-rule grant with no request, removed when the rule stops matching.
• Separation of duties (SoD) — a preventive request-time gate marking two packages (or a package and a group) incompatible, so a holder of one cannot request the other.
• Access review — a scheduled re-attestation (accessReviewScheduleDefinition) of a scope by reviewers, with recurrence, decision helpers, and non-response handling.
• Decision helper (recommendation) — a sign-in-based approve/deny hint shown to reviewers, driven by recent inactivity.
• Auto-apply / default decision — autoApplyDecisionsEnabled enforces review outcomes automatically; defaultDecision (Deny/Approve/None) is applied to non-responders.
• Lifecycle workflow — a trigger + execution scope + ordered tasks automating joiner/mover/leaver access.
• Task definition (taskDefinitionId) — a stable GUID identifying a built-in workflow action (disable, remove from groups, revoke tokens, etc.).
• Custom task extension — a workflow task that calls an Azure Logic App to reach systems Graph cannot; “launch and continue” or “launch and wait”.
• Trigger (time-based / attribute-change / on-demand) — what starts a workflow: an offset from employeeHireDate/employeeLeaveDateTime, an attribute change, or a manual run.
• Execution scope — a dynamic-group-style rule selecting which users a workflow applies to.
• Connected organization — a registered external tenant/domain whose users may request packages from externally visible catalogs, with sponsor approval.
• PIM-enabled group — a group whose membership can be made eligible (not active), bridging governance to just-in-time privilege.
• Eligibility vs activation — governance grants eligibility (months, re-attested); PIM grants activation (hours, with justification/MFA) on top of it.
• Entra ID Governance / Entra Suite — the licensing that unlocks entitlement management, lifecycle workflows, and advanced access reviews, per governed principal.

Next steps

You can now stand up the full governance machine and prove it runs. Build outward:

• Next: Privileged Identity Management and PAM Architecture: Just-in-Time Access at Scale — the JIT layer governance delivers eligibility into; get activation policies and PAM patterns right.
• Related: Zero Trust on Microsoft Entra: Conditional Access + PIM, Step by Step — governance decides what a principal may hold; Conditional Access decides under what conditions they use it.
• Related: Entra External ID B2B and Cross-Tenant Access: Guest Collaboration, Direct Connect, and Trust Settings Done Right — the full cross-tenant trust model behind governed guest onboarding.
• Related: Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters — the persona model that pairs naturally with catalog and package design.
• Related: Engineering Break-Glass Emergency Access Accounts in Entra ID: Exclusions, Hardening, and Tamper-Evident Monitoring — the accounts your workflows and reviews must always exclude.
• Related: Zero Trust Architecture Blueprint: Identity, Network, and Data Pillars — where identity governance sits in the broader Zero Trust picture.