Chapter 2: Identity Lifecycle Management (JML)

2.1 — What is an Identity? The Technical Reality

Before touching JML, you need to understand what an “identity” actually is at a technical level — because most people get this wrong.

The Identity vs Account Problem

Most people think:
"Identity = User Account"

This is wrong.
IDENTITY is the abstract representation 
of a real person or entity.
It is the SOURCE.
ACCOUNT is a specific instance of that 
identity in a particular system.
It is the REPRESENTATION.
One identity → Many accounts
AMAN VARMA (Identity)
        │
        ├── Entra ID Account
        │   aman.varma@xyz.com
        │
        ├── Active Directory Account  
        │   ISTA\avarma
        │
        ├── SAP Account
        │   AV-29481
        │
        ├── ServiceNow Account
        │   aman.varma@xyz.com
        │
        ├── Salesforce Account
        │   aman.varma@xyz.com
        │
        └── GitHub Account
            avarma-xyz
THIS is why lifecycle management 
is complex.
When Aman leaves:
You don't disable ONE account.
You disable ALL of them.
Simultaneously.
Across every system.
Miss one = security gap.

The Identity Anchor

TECHNICAL CONCEPT:
Every identity needs an ANCHOR —
a unique, immutable attribute that 
ties all accounts together across 
all systems.

WHY IT MATTERS:
What if two people are named 
"John Smith"?
What if someone gets married 
and changes their name?
What if their email changes?
If you use email as anchor:
→ Email changes = 
  identity correlation breaks
→ SAP thinks it's a new person
→ Old SAP account becomes orphaned
→ New SAP account gets created
→ Duplicate access. Security gap.
CORRECT ANCHOR:
Employee ID from HR System
Properties of a good anchor:
→ Unique (no two people share it)
→ Immutable (never changes)
→ Assigned at hire
→ Exists in HR system
→ Propagated to ALL systems
→ Never reused after termination
In Microsoft Entra ID:
The anchor is stored in:
→ employeeId attribute
→ OR onPremisesImmutableId 
  (for synced hybrid identities)
→ OR objectId (internal Entra GUID)
In Active Directory:
→ objectGUID (immutable)
→ employeeID (from HR)
→ sAMAccountName (mutable — 
  bad choice for anchor!)
TECHNICAL PROBLEM WITH sAMAccountName:
sAMAccountName = "jsmith"
John leaves. Account deleted.
New John Smith joins.
Gets sAMAccountName = "jsmith"
(same as previous John!)
SailPoint or any IGA tool 
thinks it's the same person.
Access correlation breaks completely.
THIS is why immutable IDs matter.
THIS is why Employee ID is the anchor.

2.2 — The Source of Truth

What It Is and Why It Matters Technically

DEFINITION:
The Source of Truth is the ONE system 
whose data is considered authoritative 
for identity attributes.

In enterprise IAM:
Source of Truth = HR System
Technical examples:
→ SAP SuccessFactors
→ Workday
→ Oracle HCM
→ BambooHR
WHY THE HR SYSTEM?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Because HR is the system of record 
for the employment relationship.
HR knows:
→ When someone is hired (start date)
→ What their official role is
→ Which department they belong to
→ Who their manager is
→ When they change roles
→ When their contract ends
→ Whether they are active or terminated
IT systems should NEVER be the 
source of truth for this data.
WHY NOT?
Because then you have this problem:
HR says: "John left on July 1st"
IT says: "John's account is still active"
Who is right?
→ HR is always right.
→ IT follows HR.
→ Never the other way.

The Technical Integration Between HR and IAM

HOW DOES HR DATA REACH IAM TECHNICALLY?

METHOD 1: SCIM 2.0 (Best Practice)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SCIM = System for Cross-domain 
       Identity Management
It is a standardized REST API protocol
specifically designed for provisioning.
What happens technically:
HR System                  IAM System
(Workday)                  (SailPoint/Entra)
    │                           │
    │  HTTP POST /Users         │
    │  {                        │
    │    "userName": "jsmith",  │
    │    "name": {              │
    │      "givenName": "John", │
    │      "familyName": "Smith"│
    │    },                     │
    │    "department": "Finance"│
    │    "active": true         │
    │  }                        │
    │──────────────────────────►│
    │                           │ Creates account
    │                           │ Assigns groups
    │                           │ Assigns licenses
    │  HTTP 201 Created         │
    │◄──────────────────────────│
SCIM Operations:
POST   /Users    → Create new identity (Joiner)
PATCH  /Users/id → Update identity (Mover)
DELETE /Users/id → Remove identity
PUT    /Users/id → Replace identity attributes
For account disable (Leaver):
PATCH /Users/id
{
  "Operations": [{
    "op": "replace",
    "path": "active",
    "value": false
  }]
}
WHY SCIM IS PREFERRED:
→ Standardized — works with any 
  SCIM-compliant system
→ Real-time — changes propagate 
  within minutes
→ Bidirectional capability
→ Error handling built in
→ Audit trail built in
→ No custom code needed
METHOD 2: CSV File Import (Legacy/Bad)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HR exports CSV every night at midnight
IAM imports CSV every night at 1am
Problems:
→ 24 hour delay minimum
→ Employee leaves at 9am
→ Account disabled at 1am next day
→ 16 hours of unauthorized access!
→ File format errors break everything
→ No real-time capability
→ Error-prone
METHOD 3: Direct API Integration
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HR system calls IAM API directly
when an event happens
→ More real-time than CSV
→ More custom than SCIM
→ Requires development work
→ Harder to maintain
→ Works well for specific use cases

2.3 — JOINER: Technical Deep Dive

What Actually Happens When Someone Joins

TRIGGER:
HR creates employee record
Status = Active
Start Date = defined

What happens next depends on 
your IAM architecture:
SCENARIO A: SailPoint-driven
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SailPoint receives SCIM event from HR
→ Creates Identity object in SailPoint
→ Runs Role Assignment Engine:
  "What roles does this identity qualify for 
   based on their attributes?"
→ Calculates required entitlements
→ Provisions accounts across ALL connected
  sources simultaneously:
  - Entra ID account created
  - Active Directory account created
  - SAP account created
  - ServiceNow account created
→ All from ONE HR event
SCENARIO B: Entra ID + SCIM directly
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HR pushes SCIM to Entra ID directly
→ Entra ID creates user object
→ Dynamic groups evaluate 
  new user's attributes
→ User automatically joins 
  correct groups
→ Groups have app assignments
→ User gets access to apps
  via group membership
The difference:
SailPoint handles MULTIPLE systems
Entra ID handles Microsoft ecosystem
For non-Microsoft apps you still 
need connectors or SCIM separately

Identity Attributes — The Technical Detail

When a user object is created 
in Entra ID it has these attributes:

CORE ATTRIBUTES:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
objectId              → Entra's internal GUID
                        Immutable. Never changes.
                        Example: 89f4c3a1-2b3d-...
userPrincipalName     → The login name
                        Format: user@domain.com
                        Must be unique in tenant
                        
displayName           → Full name shown in UI
givenName             → First name
surname               → Last name
mail                  → Email address
mailNickname          → Alias (before the @)
employeeId            → HR system anchor ⭐
                        Critical for correlation
department            → Used by dynamic groups
                        to auto-assign access
                        
jobTitle              → Role classification
manager               → Manager object reference
                        (not just a string —
                         actual reference to 
                         another user object!)
                        
accountEnabled        → true/false
                        The on/off switch
                        
usageLocation         → Country code (DE, NL...)
                        Required for license 
                        assignment!
                        
userType              → Member or Guest
                        Member = internal employee
                        Guest = external B2B user
EXTENSION ATTRIBUTES:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Entra ID allows custom attributes
called extension attributes or
directory schema extensions
Example custom attributes:
→ extension_costCenter
→ extension_contractEndDate
→ extension_clearanceLevel
These come from HR and drive
additional IAM logic
Example: contractEndDate drives
automatic Leaver trigger

Dynamic Groups — The Technical Engine Behind Auto-Provisioning

WHAT THEY ARE:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Dynamic Groups in Entra ID
automatically add or remove members
based on user attribute rules.

No manual intervention.
No scripts needed.
Attribute changes → membership changes.
HOW THEY WORK TECHNICALLY:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Dynamic groups use 
MEMBERSHIP RULES written in 
a specific rule syntax.
When a user's attribute changes:
→ Entra evaluates ALL dynamic 
  group rules against this user
→ If rule matches → user added
→ If rule no longer matches → 
  user removed
→ This happens automatically
  within minutes of attribute change
RULE SYNTAX EXAMPLES:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
All enabled employees:
(user.accountEnabled -eq true) 
-and 
(user.userType -eq "Member")
Finance department users:
(user.department -eq "Finance")
All managers:
(user.jobTitle -contains "Manager")
German employees:
(user.usageLocation -eq "DE")
Senior staff in Finance:
(user.department -eq "Finance") 
-and 
(user.jobTitle -contains "Senior")
Users with specific license:
(user.assignedPlans -any 
 (assignedPlan.servicePlanId 
  -eq "guid-here" 
  -and assignedPlan.capabilityStatus 
  -eq "Enabled"))
ADVANCED: COMBINING RULES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
You can combine multiple conditions:
-and  → Both must be true
-or   → Either can be true
-not  → Must NOT be true
Example: Finance OR IT employees
(user.department -eq "Finance") 
-or 
(user.department -eq "IT")
Example: All employees NOT contractors
(user.userType -eq "Member") 
-and 
-not (user.jobTitle -contains "Contractor")
THE JOINER MAGIC WITH DYNAMIC GROUPS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HR sets department = "Finance"
↓
SCIM pushes to Entra ID
↓
User created with department = "Finance"
↓
Entra evaluates dynamic group rules
↓
Rule: (user.department -eq "Finance") ← MATCHES
↓
User automatically joins Finance-Users group
↓
Finance-Users group is assigned to:
  - SAP Finance app
  - Finance SharePoint
  - Finance Teams channel
↓
User gets all of those automatically
↓
Zero manual work required ✅
THE MOVER MAGIC WITH DYNAMIC GROUPS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HR changes department = "IT"
↓
SCIM updates Entra ID attribute
↓
Entra re-evaluates dynamic group rules
↓
Finance rule: (department -eq "Finance")
← NO LONGER MATCHES
→ User REMOVED from Finance-Users group
→ Finance app access REMOVED
→ Finance SharePoint REMOVED
IT rule: (department -eq "IT")
← NOW MATCHES
→ User ADDED to IT-Users group
→ IT app access ADDED
All automatically.
No human involved.
This is the power of dynamic groups.
LIMITATION OF DYNAMIC GROUPS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Dynamic groups work on attributes.
But not all access can be 
attribute-driven.
Example:
"Give John access to Project X 
SharePoint for 3 months"
→ No HR attribute for this
→ Dynamic group can't handle it
→ Need: Assigned group + 
  Entitlement Management
  for time-limited access

Birthright Access — The Technical Design

CONCEPT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Birthright access = the set of 
resources every employee gets 
automatically regardless of role.

TECHNICAL IMPLEMENTATION OPTIONS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
OPTION 1: All-Employees Dynamic Group
→ Rule: all enabled Member users
→ Assign birthright apps to this group
→ Every new user auto-joins
→ Simple and automatic
Problem:
Guest users might match the rule
if not filtered correctly
Better rule:
(user.accountEnabled -eq true)
-and (user.userType -eq "Member")
-and (user.employeeId -ne null)
The employeeId check ensures
only real HR-sourced employees
get birthright access.
Not manually created accounts.
OPTION 2: SailPoint Birthright Roles
→ Define a "Birthright" role in SailPoint
→ Rule: all active identities qualify
→ Role contains all birthright entitlements
→ Assigned automatically on Joiner event
Advantage over Entra groups:
→ Works across ALL systems
→ Not just Microsoft apps
→ SAP birthright access too
→ Salesforce birthright access too
→ Single role definition drives 
  provisioning everywhere
OPTION 3: Access Packages (Entra 
Entitlement Management)
→ Create access package: "Employee Baseline"
→ Assign policy: auto-assign to all members
→ Contains all birthright resources
→ Automatic assignment on account creation
→ Supports expiry and review policies
Best for: Organizations wanting 
governance around birthright access
with built-in review capability
THE LAYERED ACCESS MODEL:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌────────────────────────────────────┐
│         PRIVILEGED ACCESS          │
│   Admin roles, PIM, PAM            │
│   Strict approval, JIT only        │
├────────────────────────────────────┤
│         ROLE-BASED ACCESS          │
│   Department/job specific apps     │
│   Assigned via dynamic groups      │
│   or SailPoint role assignment     │
├────────────────────────────────────┤
│         BIRTHRIGHT ACCESS          │
│   M365, intranet, HR portal        │
│   Automatic for all employees      │
│   No approval needed               │
└────────────────────────────────────┘
Each layer has different:
→ Approval requirements
→ Review frequency
→ Monitoring level
→ Risk classification

Temporary Access Pass (TAP) — The Technical Detail

THE BOOTSTRAPPING PROBLEM:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
New user needs to register MFA.
To register MFA they must authenticate.
To authenticate they need MFA.
Classic chicken and egg problem.

TAP IS THE SOLUTION:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
A Temporary Access Pass is a 
time-limited passcode issued by 
an administrator.
It bypasses MFA requirements 
ONCE so the user can:
→ Log in for the first time
→ Register their MFA methods
→ Set their permanent password
→ After that TAP is useless
TECHNICAL REQUIREMENTS:
→ Authentication Methods Policy
  must have TAP enabled
→ Entra ID P1 or P2 license
→ Admin needs:
  Authentication Administrator role
  OR higher
TAP PROPERTIES:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
lifetimeInMinutes  → How long it's valid
                     Min: 10 minutes
                     Max: 43,200 (30 days)
                     Default: 60 minutes
isUsableOnce       → If true: 
                     TAP invalidated 
                     after first use
                     Recommended: true
                     More secure
startDateTime      → When TAP becomes active
                     Can schedule for 
                     future date!
SECURITY CONSIDERATIONS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TAP is essentially a master key.
Handle it carefully:
→ NEVER send TAP via company email
  (User can't access email yet!)
  
→ Send to personal email
  OR read it to them on phone
  OR display on screen in person
→ Set isUsableOnce = true always
  (Once registered, TAP is dead)
→ Short lifetime: 60-120 minutes
  for new joiners
  
→ Longer lifetime only for 
  specific use cases
  (Lost device: 4-8 hours)
Get Aman Varma’s stories in your inbox
Join Medium for free to get updates from this writer.
Remember me for faster sign in
→ Every TAP issuance is logged
  in audit logs
  
→ If TAP is compromised:
  Delete it immediately
  New-MgUserAuthenticationTemporaryAccessPassMethod
  can be called again with new TAP

2.4 — MOVER: Technical Deep Dive

The Technical Challenge of a Mover

JOINER is relatively straightforward:
Create accounts and assign access.

MOVER is technically the hardest:
You must SIMULTANEOUSLY:
→ Remove access that no longer applies
→ Add access that now applies
→ Keep access that still applies
→ Update attributes across all systems
→ Maintain uninterrupted work capability
→ Leave zero access gaps
→ Leave zero privilege creep
→ All in real-time
→ With full audit trail
ONE WRONG STEP:
Remove access too early →
User cannot work → Business impact
Remove access too late →
Privilege creep → Security risk
Add access too late →
User cannot work in new role → 
Business impact
Don't update manager →
Wrong person gets approval requests →
Process failures

Privilege Creep — The Deep Technical Explanation

WHAT ACTUALLY HAPPENS TECHNICALLY:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

User starts as Finance Analyst:
Group memberships in Entra ID:
├── All-Employees (dynamic - stays forever)
├── Finance-Users (assigned)
├── SAP-Finance-ReadWrite (assigned)
├── Finance-SharePoint-Members (assigned)
└── M365-E3-License (dynamic - stays)
User moves to IT Department:
HR updates: department = "IT"
Dynamic groups react:
├── All-Employees ← still matches ✅
├── Finance-Users ← 
│   (assigned group - HR change 
│    does NOT auto-remove this!)
│   ← STILL ACTIVE ❌
├── SAP-Finance-ReadWrite ←
│   (assigned group - same problem)
│   ← STILL ACTIVE ❌
├── Finance-SharePoint-Members ←
│   (assigned group)
│   ← STILL ACTIVE ❌
├── M365-E3-License ← still matches ✅
├── IT-Users ← (needs to be ADDED)
├── Azure-Portal-Read ← (needs to be ADDED)
└── ServiceNow-Agent ← (needs to be ADDED)
THE ROOT CAUSE:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Dynamic groups handle attribute-based 
membership automatically.
But ASSIGNED group memberships
do NOT remove automatically
when attributes change.
Someone must explicitly remove them.
Either:
→ A person (manual, error-prone)
→ An automation (SailPoint/script)
→ Access Review (periodic cleanup)
This is the architectural gap
that causes privilege creep
in most organizations.
THE SOLUTION ARCHITECTURES:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SOLUTION 1: Full Dynamic Groups
All access driven by attributes.
No assigned groups for role access.
Finance access rule:
(user.department -eq "Finance")
IT access rule:
(user.department -eq "IT")
Department changes →
Old dynamic group auto-removes →
New dynamic group auto-adds →
Zero privilege creep possible ✅
Limitation:
Not all access can be 
expressed as attribute rules.
Project-based access can't be dynamic.
SOLUTION 2: SailPoint Role Management
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Define ROLES in SailPoint:
Role = bundle of entitlements
Finance Analyst Role contains:
→ Entra Finance-Users group
→ SAP Finance entitlement
→ Finance SharePoint access
→ Finance Teams channel
IT Specialist Role contains:
→ Entra IT-Users group
→ Azure Portal read access
→ ServiceNow Agent entitlement
When Mover happens:
SailPoint detects department change
→ Finance Analyst Role REVOKED
  (all entitlements in it removed)
→ IT Specialist Role ASSIGNED
  (all entitlements in it added)
→ ONE event = clean transition ✅
This is why IGA tools like SailPoint
are essential in large organizations.
SOLUTION 3: Hybrid Approach
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Use dynamic groups for core access.
Use SailPoint roles for app access.
Use Entitlement Management for
project-based temporary access.
Use Access Reviews as the safety net.

The Access Delta — Technical Calculation

WHAT IS ACCESS DELTA?
The mathematical difference between:
Current access (old role)
Required access (new role)

Calculated as:
REMOVE = CurrentAccess MINUS NewRoleAccess
ADD    = NewRoleAccess MINUS CurrentAccess
KEEP   = CurrentAccess INTERSECT NewRoleAccess
REAL EXAMPLE:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Current groups (Finance Analyst):
[All-Employees, Finance-Users, 
 SAP-Finance, Finance-SharePoint,
 M365-License]
New role groups (IT Specialist):
[All-Employees, IT-Users, 
 Azure-Read, ServiceNow-Agent,
 M365-License]
Delta calculation:
REMOVE = [Finance-Users, SAP-Finance,
          Finance-SharePoint]
ADD    = [IT-Users, Azure-Read,
          ServiceNow-Agent]
KEEP   = [All-Employees, M365-License]
TIMING OF DELTA APPLICATION:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
This is a critical design decision:
Option A: Simultaneous
Remove old AND add new at same time
→ Zero gap
→ Zero overlap
→ Best practice ✅
Option B: Remove first, then add
→ Window where user has NO access
→ Cannot work during transition
→ Business impact ❌
Option C: Add first, then remove
→ Window where user has BOTH accesses
→ Temporary privilege creep
→ SoD violation risk ❌
→ But better than no access
For most cases: Simultaneous ✅
For sensitive SoD-conflicting roles:
Remove first then add with 
deliberate review step between.

Segregation of Duties in the Mover Context

SoD VIOLATION THROUGH MOVER:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Imagine this scenario:

John moves from Finance to IT.
Finance access: 
→ Can CREATE vendor invoices in SAP
IT access:
→ Can MODIFY audit logs in SAP basis
If BOTH are active simultaneously:
→ John creates fraudulent invoice
→ John modifies audit log to hide it
→ Fraud undetectable
→ This is a TOXIC COMBINATION
SoD policies define these 
toxic combinations:
"If user has EntitlementA 
 they CANNOT have EntitlementB"
TECHNICAL ENFORCEMENT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
In SailPoint:
→ Define SoD policies in policy editor
→ Example policy:
  "SAP-Finance-Create" conflicts with 
  "SAP-Basis-AuditLog-Modify"
→ When Mover tries to ADD 
  "SAP-Basis-AuditLog-Modify"
  while user still has 
  "SAP-Finance-Create"
→ SailPoint BLOCKS the provisioning
→ Raises SoD violation alert
→ Requires senior approval 
  OR forces removal of old access first
In Entra ID alone:
→ No native SoD enforcement
→ Must build custom logic
→ Or rely on Access Reviews 
  to catch violations periodically
This is one reason why organizations 
with complex SoD requirements 
need a dedicated IGA tool like SailPoint
rather than relying only on Entra ID.

2.5 — LEAVER: Technical Deep Dive

Why Leaver is the Most Security-Critical Process

STATISTICS THAT PROVE THIS:
→ Average time to disable leaver accounts:
  Without automation: 2-7 days
  With automation: Minutes

→ In those days:
  Former employee still has full access
  To emails, files, systems, data
  Even customer data
  Even financial systems
→ Most insider threat incidents 
  happen in this window
→ GDPR Article 32 requires 
  "appropriate technical measures"
  to protect personal data
  Unrevoked leaver access = 
  potential GDPR violation
THE TECHNICAL GOAL:
Account disabled BEFORE or EXACTLY 
ON the last working moment.
NOT the next day. 
NOT after the weekend.
The SAME DAY. The SAME HOUR.
For involuntary terminations:
The SAME MINUTE.

The Technical Leaver Sequence

WHAT MUST HAPPEN AND IN WHAT ORDER:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 1: IMMEDIATE (Same minute)
For involuntary terminations.
For voluntary: on final working day.
1. DISABLE ACCOUNT
   accountEnabled = false in Entra ID
   
   This prevents NEW sign-ins.
   But does NOT kill existing sessions!
   Active sessions continue until 
   token expires (up to 1 hour!)
   
   This is a critical misunderstanding
   most people have.
   
2. REVOKE ALL ACTIVE SESSIONS
   This is a SEPARATE action.
   Invalidates all refresh tokens.
   Forces sign-out on ALL devices.
   Takes effect within minutes.
   
   Technical action:
   Revoke sign-in sessions
   via Graph API or Entra portal
   
   This kills:
   → Active browser sessions
   → Mobile app sessions
   → Teams sessions
   → SharePoint sessions
   → Any app using SSO
3. REVOKE REFRESH TOKENS
   Access tokens are short-lived 
   (60-90 minutes typically)
   Refresh tokens are long-lived
   (hours to days)
   
   Disabling account stops 
   new token issuance.
   
   But already-issued refresh tokens?
   They need explicit revocation.
   
   Until revoked:
   Attacker with stolen refresh token
   can still get new access tokens!
   
   This is why session revocation
   is critical — not just 
   account disabling.
PHASE 2: SHORT TERM (Same day)
4. REMOVE FROM ALL GROUPS
   Remove from every Entra ID group
   Removes all app access
   
   Note: License groups = 
   license gets freed up ✅
   Cost saving!
5. REMOVE PIM ELIGIBLE ROLES
   User might have PIM-eligible 
   admin roles assigned.
   These must be explicitly removed.
   Disabling account alone does NOT
   remove PIM eligibility.
   
   If forgotten:
   Account re-enabled later →
   Former employee still has 
   path to admin roles!
6. REMOVE MFA METHODS
   Delete registered authenticator apps
   Delete phone numbers
   Delete FIDO2 keys
   
   Why?
   If account is re-enabled 
   (accidentally or for investigation)
   former employee's MFA methods 
   should not work.
7. INVALIDATE APP-SPECIFIC SESSIONS
   Some apps maintain their own sessions
   independent of Entra ID tokens.
   
   Examples:
   → Salesforce: 
     Must revoke Salesforce session too
   → VPN: 
     Must remove VPN certificate/profile
   → GitHub: 
     Must remove SSH keys and 
     personal access tokens
   
   This is why SCIM deprovisioning 
   is critical for all connected apps.
   SCIM PATCH active=false 
   sent to every connected system.
PHASE 3: SAME WEEK
8. HANDLE MAILBOX
   Options (per org policy):
   A) Convert to shared mailbox
      → Manager can access
      → Useful for business continuity
      → No license needed
      
   B) Set auto-reply
      → "This person has left xyz. 
          Please contact manager@xyz.com"
          
   C) Forward to manager
      → All incoming emails go to manager
      → For defined period (30-90 days)
9. HANDLE ONEDRIVE/FILES
   → Give manager access to files
   → Set retention period
   → After retention: files deleted
   → Must comply with GDPR!
   → Cannot keep personal files forever
10. REMOVE LICENSES
    → Frees up license cost
    → Important in large orgs
    → M365 E3 = ~€30/month per user
    → 100 leavers = €3,000/month waste
    → Automate this!
PHASE 4: LONG TERM (Per retention policy)
11. KEEP ACCOUNT IN DISABLED STATE
    Do NOT delete immediately!
    
    Why keep disabled account?
    → Legal investigation might need it
    → Email archive might reference it
    → Audit trail preservation
    → Some compliance frameworks 
      require 90 days minimum retention
      
    How long to keep:
    → Typically 30-90 days disabled
    → Then move to "soft delete"
    → Then permanent deletion
    → Exact timeline per org policy
    → Must align with GDPR retention
12. GDPR CONSIDERATION
    After employment ends:
    Personal data must be handled 
    per your retention policy.
    Cannot keep personal data 
    indefinitely without legal basis.
    IAM team must coordinate with 
    legal/compliance on this.

The Orphaned Account Problem

WHAT IS AN ORPHANED ACCOUNT?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
An account that exists in a system
with no active owner or known purpose.

TYPES OF ORPHANED ACCOUNTS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TYPE 1: Forgotten Leaver Accounts
Person left. JML process failed 
or was skipped.
Account still active months later.
Nobody noticed.
TYPE 2: Dormant Service Accounts
Application account created for 
a project 3 years ago.
Project is finished.
Application is decommissioned.
But the service account remains.
Nobody knows what it does.
Nobody wants to delete it
"in case something breaks."
TYPE 3: Shared Accounts
Team shared a generic account:
"finance-team@xyz.com" password: Finance2020
Multiple people know the password.
IAM has no idea who is using it.
If misused: no individual accountability.
TYPE 4: Test Accounts
"test.user@xyz.com" created 
for testing during a project.
Project ended. Account forgotten.
Could have admin permissions.
Could be exploited.
WHY ORPHANED ACCOUNTS ARE DANGEROUS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
→ Nobody monitors them
→ Nobody reviews their access
→ If credentials are stolen:
  Attacker has persistent access
  that nobody is watching
→ They often have broad permissions
  from their original purpose
→ Classic attack vector:
  Find old service account →
  Access still works →
  Move laterally through organization
HOW TO DETECT ORPHANED ACCOUNTS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SIGNAL 1: Last sign-in date
Accounts that have never logged in
or haven't logged in for 90+ days
are candidates for review.
Note: Some service accounts 
legitimately never have interactive sign-ins.
Must distinguish between:
→ Interactive sign-ins (humans)
→ Non-interactive sign-ins (service accounts)
→ Never signed in (provisioned but unused)
SIGNAL 2: No manager attribute
Every human account should have
a manager assigned.
Accounts with no manager =
no owner = potential orphan.
SIGNAL 3: Department = blank
HR-sourced accounts always have 
department populated.
Blank department = 
manually created = investigate.
SIGNAL 4: Account predates IGA system
If your IGA tool was implemented 
2 years ago but account was 
created 5 years ago:
It was never brought under governance.
Review it.
HOW TO HANDLE ORPHANED ACCOUNTS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Identify them (quarterly audit)
2. Attempt to find owner
   → Check who created the account
   → Check last usage
   → Ask department heads
3. If owner found:
   → Bring under proper governance
   → Assign to IGA system
   → Set up review cycle
4. If no owner found after X days:
   → Disable the account
   → Wait 30 days (in case 
     something breaks and owner 
     comes forward)
   → Then delete
5. Document everything

2.6 — The Full JML Architecture

How All the Pieces Connect

THE COMPLETE TECHNICAL PICTURE:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

       HR SYSTEM (Source of Truth)
       Workday / SAP SuccessFactors
              │
              │ SCIM 2.0 / API
              │ Real-time events:
              │ employee.created
              │ employee.updated  
              │ employee.terminated
              ▼
       IGA LAYER (SailPoint ISC)
       ─────────────────────────
       → Receives HR events
       → Correlates with existing identities
         using Employee ID anchor
       → Runs role assignment engine
       → Calculates provisioning actions
       → Manages approval workflows
       → Maintains audit trail
       → Runs access certifications
              │
              │ Provisioning via:
              │ SCIM / REST API / 
              │ Connectors
              ▼
    ┌─────────────────────────────┐
    │   CONNECTED SYSTEMS         │
    │                             │
    │  Microsoft Entra ID         │
    │  ├── User Account           │
    │  ├── Group Memberships      │
    │  ├── App Assignments        │
    │  └── License Assignment     │
    │                             │
    │  Active Directory           │
    │  ├── AD Account             │
    │  ├── Group Memberships      │
    │  └── OU placement           │
    │                             │
    │  SAP                        │
    │  ├── User Account           │
    │  └── Role Assignments       │
    │                             │
    │  ServiceNow                 │
    │  ├── User Account           │
    │  └── Group Assignments      │
    │                             │
    │  + 50 other apps...         │
    └─────────────────────────────┘
              │
              │ Feedback loop
              │ Success/Failure reports
              ▼
       MONITORING & AUDIT
       ─────────────────────────
       → Sign-in logs (Entra)
       → Provisioning logs (SailPoint)
       → SIEM integration (Sentinel)
       → Power BI dashboards
       → Compliance reports
THE KEY INSIGHT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ONE HR event (hire/change/terminate)
cascades through the entire stack
and updates ALL systems.
This is why the architecture matters.
Not just individual tools.
The INTEGRATION between them
is what makes JML work at scale.

2.7 — What Breaks Without Proper JML

REAL CONSEQUENCES OF POOR JML:

SCENARIO 1: No Leaver Automation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Company has 500 employees.
Average 5% annual turnover = 25 leavers/year.
Manual process takes 3 days to disable.
Risk window per leaver: 3 days
3 days × 25 leavers = 75 days/year
of active unauthorized access.
One of those 25 leavers is 
a disgruntled employee.
75 days to exfiltrate data.
GDPR breach.
Average cost: €4.88 million.
SCENARIO 2: No Mover Process
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
200 role changes per year.
Each person keeps old access.
After 3 years: 
Average employee has 4x the 
access they actually need.
Audit happens.
Auditor finds Finance users 
with IT admin access.
Finds SoD violations.
Compliance failure.
Regulatory fine.
SCENARIO 3: No Joiner Automation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
100 new joiners per year.
Each waits 2 days for access.
100 × 2 days = 200 days 
of lost productivity per year.
At average €300/day salary:
€60,000 in lost productivity.
Plus helpdesk burden.
Plus frustrated new employees.
Plus bad employer reputation.
THE BUSINESS CASE FOR PROPER JML:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Proper JML automation:
→ Eliminates security gaps
→ Ensures compliance
→ Saves license costs
→ Improves new hire experience
→ Reduces helpdesk load
→ Provides audit-ready evidence
This is why JML is not just 
an IT process.
It is a business-critical function
with direct security, compliance,
and financial implications.
THIS is how you talk about 
JML in interviews.
Not just "we create and delete users."
But the full business and 
technical context behind it.