MSA1.7 The Identity Lifecycle — Joiner, Mover, Leaver

Most organizations have no lifecycle automation. New employees are provisioned manually — someone in IT creates the AD account, someone else assigns a license, someone adds them to groups (probably not all the right ones, probably by copying another user's membership). When someone changes department, their old group memberships persist because nobody removes them. When someone leaves, their account is disabled but their group memberships, application access, Teams channel memberships, and SharePoint permissions remain intact. The identity exists in a zombie state — disabled but not deprovisioned, retaining access that could be reactivated. This sub teaches you to understand the identity lifecycle as an architectural system: where identities come from (the HR source of truth), how they flow into Entra ID (HR-driven provisioning), what happens at each stage (Lifecycle Workflows), and why the mover stage — the one almost nobody automates — creates more security risk than the other two combined.

Estimated time: 50 minutes.

Why the lifecycle is an architectural problem — not an HR problem

The identity lifecycle isn't about employee onboarding and offboarding. It's the mechanism that determines whether access is correctly provisioned when someone joins, correctly adjusted when responsibilities change, and correctly revoked when they leave. If this mechanism is manual — if it depends on someone remembering to do each step, in the right order, at the right time, for every one of 810 users — then access accumulation isn't possible. It's guaranteed.

Here's the architectural reasoning. A manual process works for high-visibility events. New employee starts work — the hiring manager sends an email to IT, IT creates the account. This happens because the new employee is visible: they're sitting at a desk without access, generating helpdesk tickets. A termination occurs — HR sends an email to IT, IT disables the account. This happens because it's documented in a termination checklist.

The mover stage has neither visibility nor a checklist. Someone transfers from Engineering to the SOC. HR updates the job title in the HR system. The Department and JobTitle attributes may update in AD if the HR system is connected (at NE, it isn't). But group memberships don't change. Application assignments don't change. Teams memberships don't change. SharePoint permissions don't change. The former engineer now has SOC access and retains all Engineering access — because no automated process exists to revoke role-specific access when the role changes. Nobody even knows the change happened unless they query it.

The HR system as the source of truth

The first architectural decision is: where do lifecycle events originate? In most organizations, they originate in the HR system. An employee is hired — the record is created in the HR system. An employee changes department — the record is updated in the HR system. An employee leaves — the record is terminated in the HR system. The HR system is the authoritative source for "who works here, in what capacity, starting when, and ending when."

The architectural problem is that the HR system and the identity system (Entra ID, Active Directory) are often disconnected. HR creates a record; IT manually creates the corresponding identity. HR updates a department; nobody tells IT. HR terminates an employee; IT finds out via email (or doesn't find out at all until someone notices the account is still active).

HR-driven provisioning closes this gap by connecting the HR system directly to the identity system. When HR creates a record, the identity is automatically provisioned. When HR updates a department, the identity attributes update. When HR terminates the record, the identity is disabled. No manual steps. No email chains. No forgotten role changes.

Microsoft Entra ID supports three HR-driven provisioning methods:

Method 1 — Direct connector (SAP SuccessFactors or Workday)

Microsoft provides pre-built enterprise application connectors for SAP SuccessFactors and Workday — the two largest cloud HR platforms. These connectors are available in the Entra enterprise application gallery.

The connector reads employee data from the HR system via API (SuccessFactors uses OData; Workday uses SOAP/REST Web Services). It maps HR attributes (employee ID, department, manager, start date, termination date) to Entra ID or Active Directory attributes. The provisioning service runs on a configurable schedule (default: 40 minutes) and detects changes in the HR system — new hires, attribute updates, terminations.

HR System (SuccessFactors/Workday)
    │
    ▼ (API — reads employee data on schedule)
Entra Provisioning Service (cloud)
    │
    ├──▶ Active Directory (via provisioning agent)
    │         │
    │         ▼ (Cloud Sync replicates to Entra ID)
    │    Entra ID (user attributes updated)
    │
    └──▶ Entra ID directly (for cloud-only users)

The provisioning flow supports two target paths. For organizations with on-premises AD (like NE), the connector provisions users into AD, and Cloud Sync replicates them to Entra ID. For cloud-only organizations, the connector provisions directly into Entra ID.

Method 2 — API-driven inbound provisioning

For organizations that don't use SuccessFactors or Workday, Microsoft offers API-driven inbound provisioning — a SCIM-based API endpoint that accepts identity data from any source. The source could be a different HR system (BambooHR, Personio, ADP), a flat file (CSV extract from a legacy HR database), a SQL staging table, or a custom application.

The flow is: the source system (or an integration layer like a PowerShell script, Azure Logic App, or Azure Automation runbook) sends SCIM-formatted user data to the Entra provisioning API. The provisioning service processes the data and creates or updates users in Entra ID or Active Directory.

This method requires more integration work than the pre-built connectors (you write the data extraction and SCIM formatting yourself), but it works with any HR source.

# Check if any provisioning apps are configured
Connect-MgGraph -Scopes "Application.Read.All"

$provisioningApps = Get-MgServicePrincipal -All `
  -Filter "tags/any(t: t eq 'WindowsAzureActiveDirectoryGalleryApplicationNonPrimaryV1')" |
  Where-Object { $_.DisplayName -match "SuccessFactors|Workday|Provisioning|HR" }

if ($provisioningApps.Count -eq 0) {
  Write-Host "No HR provisioning connectors found"
  Write-Host "All identity provisioning is manual"
} else {
  $provisioningApps | Select-Object DisplayName, AppId | Format-Table -AutoSize
}

No HR provisioning connectors found
All identity provisioning is manual

the tenant has no HR provisioning connectors. Every identity is provisioned manually. This confirms the architectural gap.

Method 3 — Manual provisioning (the organization's current state)

Without HR-driven provisioning, NE relies on email-based requests from HR or hiring managers to IT. IT creates the account manually, assigns a license manually, and adds the user to groups — often by copying another user's configuration.

The problems with manual provisioning are structural, not about IT competence:

Template copying propagates accumulated access. When IT creates a new user by copying an existing employee's configuration, the new user inherits every group membership the template user has — including memberships accumulated over years of role changes. A new graduate engineer joining NE might be copied from a senior engineer who has Engineering access, Safety Compliance project access, and legacy application access from three previous roles. The new hire starts with excessive access from Day 1.

No connection to employee start/leave dates. Without the employeeHireDate and employeeLeaveDateTime attributes populated in Entra ID, time-based triggers in Lifecycle Workflows can't fire. Query the coverage:

$users = Get-MgUser -All -Property DisplayName, EmployeeHireDate, EmployeeLeaveDateTime `
  -ConsistencyLevel eventual

$hireDate = ($users | Where-Object { $_.EmployeeHireDate }).Count
$leaveDate = ($users | Where-Object { $_.EmployeeLeaveDateTime }).Count

Write-Host "employeeHireDate coverage:      $hireDate / $($users.Count) ($([math]::Round($hireDate/$users.Count*100,1))%)"
Write-Host "employeeLeaveDateTime coverage: $leaveDate / $($users.Count) ($([math]::Round($leaveDate/$users.Count*100,1))%)"

employeeHireDate coverage:      0 / 810 (0%)
employeeLeaveDateTime coverage: 0 / 810 (0%)

Zero coverage on both attributes. This is the foundational blocker for lifecycle automation. Until the HR system populates these attributes (via one of the three provisioning methods), time-based Lifecycle Workflow triggers have nothing to trigger on. On-demand execution is still possible — an admin can trigger a workflow manually — but the architectural goal is automation, not faster manual processes.

Lifecycle Workflows — the automation platform

Lifecycle Workflows are an Entra ID Governance feature that automates tasks based on the JML model. A workflow consists of two components: execution conditions (who and when) and tasks (what happens). Workflows can be triggered on a tenant-wide schedule (default: every 3 hours, configurable 1–24 hours), on-demand for specific users, or in real-time for urgent events like terminations.

Query the current state:

Connect-MgGraph -Scopes "LifecycleWorkflows.Read.All"

$workflows = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/identityGovernance/lifecycleWorkflows/workflows"

Write-Host "Total Lifecycle Workflows: $($workflows.value.Count)"
$workflows.value | Group-Object category |
  Select-Object @{N='Category';E={$_.Name}}, Count | Format-Table -AutoSize

Total Lifecycle Workflows: 0

Zero workflows. the tenant has no lifecycle automation of any kind. Every joiner, mover, and leaver action is manual.

Designing a joiner workflow for NE

A joiner workflow executes tasks before or on the employee's start date. The execution condition defines who (the scope rule) and when (the trigger). The tasks define what happens.

{
  "category": "joiner",
  "displayName": "NE Engineering Onboarding — Pre-Hire",
  "description": "Provisions Engineering department employees 2 days before start date",
  "isEnabled": true,
  "isSchedulingEnabled": 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": "employeeHireDate",
      "offsetInDays": -2
    }
  },
  "tasks": [
    {
      "continueOnError": false,
      "isEnabled": true,
      "taskDefinitionId": "6fc52c9d-398b-4305-9763-15f42c1676fc",
      "displayName": "Enable user account",
      "arguments": [
        { "name": "enableOnPremisesAccount", "value": "true" }
      ]
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "683c87a4-2ad4-420b-97d4-220d90afcd24",
      "displayName": "Assign M365 E3 license",
      "arguments": [
        { "name": "licenses", "value": "05e9a617-0261-4cee-bb44-138d3ef5d965" }
      ]
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "22085229-5809-45e8-97fd-270d28d66910",
      "displayName": "Add to SG-Engineering-All group",
      "arguments": [
        { "name": "groupID", "value": "GROUP-ID-SG-Engineering-All" }
      ]
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "e440ed8d-25a1-4618-84ce-091ed5be5594",
      "displayName": "Add to Team-Engineering-General",
      "arguments": [
        { "name": "teamID", "value": "TEAM-ID-Engineering-General" }
      ]
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "70b29d51-b59a-4773-9280-8841dfd3f2ea",
      "displayName": "Generate Temporary Access Pass",
      "arguments": [
        { "name": "tapLifetimeMinutes", "value": "480" },
        { "name": "tapIsUsableOnce", "value": "true" }
      ]
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "aab41899-9571-4669-85fe-37b6d86fcd15",
      "displayName": "Send welcome email to new hire",
      "arguments": []
    }
  ]
}

Every element is an architectural choice:

The execution condition has two parts. The scope uses a rule expression that filters by department — only Engineering employees match. The trigger fires 2 days before employeeHireDate (offsetInDays: -2). This gives the workflow two business days to complete before the employee arrives. If any task fails, IT has two days to investigate and remediate before the new hire is affected.

Task 1 — Enable user account. The enableOnPremisesAccount: true argument enables both the Entra ID account and the on-premises AD account (via Cloud Sync writeback). Without this argument, only the cloud account is enabled — the employee can't sign in to on-premises resources on Day 1. continueOnError: false means if this task fails, the workflow stops. An account that can't be enabled is a blocker — there's no point assigning a license to an account that doesn't work.

Task 2 — Assign license. The licenses value 05e9a617-0261-4cee-bb44-138d3ef5d965 is the SKU ID for Microsoft 365 E3 — the standard license for non-E5 Engineering employees. the organization's licensing split is 250 E5 (IT, Security, Executives) and 600 E3 (all others). The correct license is assigned by the workflow, not copied from another user. continueOnError: true — if the license assignment fails (e.g., insufficient available licenses), the workflow continues and the failure is logged for IT to investigate.

Task 3 — Add to group. The explicit group ID means every Engineering hire gets exactly the same group membership. No template copying, no inherited historical accumulation. The group SG-Engineering-All is defined in MSA1.10 as the department-level security group that gates access to Engineering SharePoint sites, Teams channels, and applications.

Task 5 — Generate TAP. A Temporary Access Pass is a time-limited, one-use-only credential that the new hire uses for their first sign-in. During that first sign-in, they register a phishing-resistant MFA method (FIDO2, passkey, or Windows Hello). The TAP eliminates the need for IT to set a temporary password and communicate it insecurely. The tapLifetimeMinutes: 480 gives the employee an 8-hour window on Day 1 to complete registration.

Task 6 — Welcome email. The built-in email task sends a notification to the new hire's personal email address (from the HR record) with onboarding instructions and their TAP. This is the only "manual" touchpoint — the employee receives an automated email with everything they need.

The mover problem in depth — why access accumulates

The mover stage is the lifecycle stage that creates the most security debt and receives the least investment. Consider SOC Analyst 2's career at NE.

Priya joined 18 months ago as a graduate engineer. During onboarding (manual, since the tenant has no lifecycle automation), she was added to these groups:

$priya = Get-MgUser -UserId "p.sharma@yourtenant.onmicrosoft.com"
$groups = Get-MgUserMemberOf -UserId $priya.Id -All |
  Where-Object { $_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.group' }

Write-Host "Group memberships for $($priya.DisplayName): $($groups.Count)"
Write-Host ""
$groups | ForEach-Object {
  $name = $_.AdditionalProperties['displayName']
  $type = $_.AdditionalProperties['groupTypes'] -join ', '
  $created = $_.AdditionalProperties['createdDateTime']
  Write-Host "  $name"
}

Group memberships for SOC Analyst 2: 11

  SG-All-Staff
  SG-Engineering-All
  SG-Manchester-Staff
  Team-Engineering-General
  SP-Engineering-Projects
  App-CAD-Users
  App-PLM-Users
  SG-Safety-Compliance-Project
  SP-Safety-Compliance-Docs
  Team-Safety-Compliance
  SG-SOC-Analysts

11 group memberships. Let's trace the history:

Joining (18 months ago): IT created Priya's account by copying a senior engineer's configuration. She received: SG-All-Staff (org-wide, correct), SG-Engineering-All (department, correct), SG-Manchester-Staff (site, correct), Team-Engineering-General (Teams channel, correct), SP-Engineering-Projects (SharePoint, correct), App-CAD-Users (application access, correct for Engineering), App-PLM-Users (application access, correct for Engineering). Total: 7 groups. All appropriate for her role.

Project assignment (12 months ago): Priya was assigned to the Safety Compliance project. Someone added her to: SG-Safety-Compliance-Project, SP-Safety-Compliance-Docs, Team-Safety-Compliance. Total: 10 groups. The project ended 3 months later. Nobody removed the 3 project groups.

Role change (3 months ago): Priya moved from Engineering to the SOC team. Someone added her to SG-SOC-Analysts. Nobody removed her from the 6 Engineering groups or the 3 project groups. Total: 11 groups.

Her current effective access:

Group                          Current Role?  Verdict
-----------------------------  ------------   -------
SG-All-Staff                   Yes            Keep — org-wide
SG-Manchester-Staff            Yes            Keep — site
SG-SOC-Analysts                Yes            Keep — current department
SG-Engineering-All             No             STALE — previous department
Team-Engineering-General       No             STALE — previous department
SP-Engineering-Projects        No             STALE — previous department
App-CAD-Users                  No             STALE — previous department
App-PLM-Users                  No             STALE — previous department
SG-Safety-Compliance-Project   No             STALE — completed project
SP-Safety-Compliance-Docs      No             STALE — completed project
Team-Safety-Compliance         No             STALE — completed project

Priya needs 3 groups for her SOC role. She has 11. The 8 excess memberships give her access to Engineering SharePoint sites (potentially containing designs and intellectual property), Engineering applications (CAD and PLM software), a completed project's documents, and a project Teams channel. Each is access she shouldn't have. Each is a path an attacker could exploit if Priya's account is compromised.

Multiply this by 810 users, 4-year average tenure, 1.5 role changes per employee. The accumulated stale access across the tenant is substantial. MSA1.8 quantifies this at scale. MSA12 designs the access reviews that catch it. But the architectural fix is preventing accumulation in the first place — and that requires automated mover workflows.

Designing a leaver workflow for NE

The leaver stage has two time horizons. Immediate actions must happen within minutes: disable the account, revoke active sessions. Delayed actions happen over days: remove group memberships, revoke licenses, transfer OneDrive, convert mailbox, and eventually delete.

{
  "category": "leaver",
  "displayName": "NE Real-Time Offboarding",
  "description": "Immediate account disable and access revocation upon termination",
  "isEnabled": true,
  "isSchedulingEnabled": false,
  "executionConditions": {
    "@odata.type": "#microsoft.graph.identityGovernance.triggerAndScopeBasedConditions",
    "scope": {
      "@odata.type": "#microsoft.graph.identityGovernance.ruleBasedSubjectSet",
      "rule": "(department ne null)"
    },
    "trigger": {
      "@odata.type": "#microsoft.graph.identityGovernance.timeBasedAttributeTrigger",
      "timeBasedAttribute": "employeeLeaveDateTime",
      "offsetInDays": 0
    }
  },
  "tasks": [
    {
      "continueOnError": false,
      "isEnabled": true,
      "taskDefinitionId": "6fc52c9d-398b-4305-9763-15f42c1676fc",
      "displayName": "Disable user account",
      "arguments": [
        { "name": "enableOnPremisesAccount", "value": "true" }
      ]
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "1953a66c-751c-45e5-8bfe-01462c70da3c",
      "displayName": "Remove all license assignments",
      "arguments": []
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "b3a31406-2a15-4c9a-b25b-a658fa5f07fc",
      "displayName": "Remove user from all groups",
      "arguments": []
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "4a4b880a-0f10-4b65-bcc0-72f2d6c8ebe4",
      "displayName": "Remove user from all Teams",
      "arguments": []
    },
    {
      "continueOnError": true,
      "isEnabled": true,
      "taskDefinitionId": "d79d1fcc-16be-490c-a865-f4533b1639ee",
      "displayName": "Notify manager and revoke VPN (custom)",
      "arguments": [
        { "name": "customTaskExtensionID", "value": "EXTENSION-ID" }
      ]
    }
  ]
}

Task 1 — Disable user account. continueOnError: false. If the account can't be disabled, the workflow stops. A failed disable means the leaver can still authenticate — this is the one step that absolutely must succeed. The enableOnPremisesAccount: true argument ensures both cloud and on-premises accounts are disabled via writeback. Without this, only the cloud account is disabled — the leaver can still authenticate to on-premises resources (file shares, internal apps, VPN via RADIUS).

Task 3 — Remove from all groups. This is the task that the organization's current manual process misses. MSA1.8 found 27 disabled accounts with residual group memberships — the direct consequence of disabling accounts without removing group access. If someone re-enables a disabled account (accidentally or maliciously), every group membership is immediately active.

Task 5 — Custom task extension. The built-in tasks cover Entra ID and M365 actions. External systems — VPN (Prisma Access), physical access control, third-party SaaS applications — require custom task extensions that call Azure Logic Apps. The Logic App receives the termination event, calls the external system's API to revoke access, and reports success or failure back to the workflow. Designing these extensions is an MSA12 deliverable.

The isSchedulingEnabled: false setting is deliberate. Real-time leaver workflows should not run on the tenant-wide schedule (every 3 hours). They should be triggered on-demand by HR (when the termination decision is made) or automatically when employeeLeaveDateTime is set in the HR system. The offsetInDays: 0 means the workflow fires on the leave date itself. For planned departures (resignations with notice), the leave date is future — the workflow fires automatically when the date arrives. For immediate terminations, HR sets the leave date to today and triggers the workflow on-demand.

the organization's lifecycle architecture gap

Lifecycle Stage   Current Process        Gap                           Remediation
--------------    ---------------------  ----------------------------  ---------------------------
Source of truth   HR system (manual)     No connection to Entra ID.    API-driven inbound
                                         employeeHireDate and          provisioning (connects
                                         employeeLeaveDateTime at 0%   any HR source). Attribute
                                                                       population required.

Joiner            IT copies another      Template copying propagates   Lifecycle Workflow joiner
                  user's config          accumulated access. No TAP.   template per department.
                                         No pre-hire provisioning.     Explicit group lists.

Mover             No process exists      Access accumulates with       Lifecycle Workflow mover
                  (HR doesn't notify     every role change. Priya      template. Attribute-driven
                  IT of role changes)    has 8 stale memberships.      triggers. Group-mediated
                                                                       access model (MSA1.10).

Leaver            IT disables account    Account disabled but groups,  Lifecycle Workflow real-time
                  (manually, via email   apps, Teams not revoked.      leaver template. Custom
                  from HR)              27 disabled accounts retain    task extension for VPN
                                         group memberships.            and external systems.

The foundational blocker is the HR data pipeline. Without employeeHireDate and employeeLeaveDateTime populated in Entra ID, time-based workflow triggers can't fire. The first remediation step is connecting the HR system to Entra ID. the organization's HR system is a mid-tier product (not SuccessFactors or Workday), so the API-driven inbound provisioning method is the appropriate integration path. This is a cross-functional project between IT, HR, and Security — it can't be solved by the identity architect alone.

Licensing requirement: Lifecycle Workflows require Microsoft Entra ID Governance or Microsoft Entra Suite licenses. This is an additional license cost beyond E3/E5. The cost is justified by the risk reduction — the alternative (manual lifecycle management) has a measurable cost in access accumulation, delayed offboarding, and helpdesk provisioning time.

Before moving on, verify your understanding: Explain why the mover stage creates more security risk than the joiner or leaver stage. Use SOC Analyst 2's example — how many excess group memberships does she have, how did each accumulate, and what access does each provide? Query your tenant for Lifecycle Workflows and HR provisioning connectors. How many of each exist? If both are zero, explain what this tells you about the lifecycle architecture.

Reusable script — the commands from this sub assembled for operational use:

Copy the NE lifecycle gap table into your architecture package at 01-identity/lifecycle-gap-assessment.md. For each stage, document the current process, the specific gap, and the remediation with module references. This assessment feeds directly into MSA1.11 (NE Identity Assessment) and MSA12 (Governance Architecture) where you design the complete lifecycle automation.

The critical dependency is the HR data pipeline. Document:

• Current HR system name and capabilities (does it support SCIM, API export, or manual CSV?)
• Which of the three provisioning methods is appropriate
• The specific attributes required (employeeHireDate, employeeLeaveDateTime, department, jobTitle, manager)
• Current coverage of each attribute (run the coverage query)
• Estimated timeline to establish the HR connection (this is typically a 2–4 month project)