Skip to main content

User Offboarding

User offboarding revokes all IT access and recovers organisational assets when a staff member departs. The procedure addresses voluntary resignations, contract completions, and involuntary terminations through a structured sequence that prevents continued access while preserving data integrity and audit trails.

Timing coordination

Access revocation timing must coordinate with HR and line management. Revoking access before the agreed departure creates operational disruption; revoking after departure creates security exposure. Confirm the exact revocation time in writing before executing any steps.

Prerequisites

Before initiating offboarding, confirm the following requirements are satisfied.

HR confirmation: Written confirmation from HR that the staff member is departing, including:

  • Final working day (last day with system access)
  • Departure type (resignation, contract end, redundancy, termination for cause)
  • Notice period status (working notice, garden leave, immediate departure)
  • Any restrictions on system access during notice period

Manager notification: Line manager has confirmed:

  • Data handover requirements (what needs transferring, to whom)
  • Shared resource reassignment (mailboxes, calendars, file ownership)
  • Knowledge transfer completion status
  • Device return arrangements

Access inventory: Compile a complete list of the departing user’s access:

  • Directory accounts (Active Directory, Entra ID, Google Workspace)
  • Application accounts (SaaS platforms, business systems)
  • Privileged access (admin rights, service accounts they manage)
  • Group memberships and role assignments
  • Shared mailboxes and distribution lists
  • Delegated access to other users’ resources
  • Physical access (building cards, keys)

Timing agreement: Written confirmation of:

  • Exact date and time for access revocation
  • Whether staged revocation applies (email access retained during handover)
  • Who authorises emergency access extension if required

Access Revocation Sequence

Access revocation follows a priority sequence designed to close the highest-risk access paths first. The sequence reflects that identity provider access controls downstream application access, and that privileged access poses greater risk than standard user access.

+------------------------------------------------------------------+
| ACCESS REVOCATION PRIORITY |
+------------------------------------------------------------------+
| |
| PRIORITY 1: AUTHENTICATION (within 15 minutes of departure) |
| +------------------------------------------------------------+ |
| | - Disable identity provider account (Entra ID, Google, | |
| | Keycloak) | |
| | - Revoke all active sessions and tokens | |
| | - Disable MFA devices | |
| | - Remove from conditional access exceptions | |
| +------------------------------------------------------------+ |
| | |
| v |
| PRIORITY 2: PRIVILEGED ACCESS (within 1 hour) |
| +------------------------------------------------------------+ |
| | - Remove admin role assignments | |
| | - Rotate credentials for any service accounts they managed | |
| | - Remove from privileged access groups | |
| | - Disable PAM vault access | |
| +------------------------------------------------------------+ |
| | |
| v |
| PRIORITY 3: DATA ACCESS (within 4 hours) |
| +------------------------------------------------------------+ |
| | - Remove file share permissions | |
| | - Remove SharePoint/Drive access | |
| | - Transfer owned files to manager | |
| | - Remove database access | |
| +------------------------------------------------------------+ |
| | |
| v |
| PRIORITY 4: APPLICATION ACCESS (within 24 hours) |
| +------------------------------------------------------------+ |
| | - Remove from SaaS application assignments | |
| | - Disable accounts in non-SSO applications | |
| | - Remove API access and revoke personal access tokens | |
| | - Update application-specific group memberships | |
| +------------------------------------------------------------+ |
| | |
| v |
| PRIORITY 5: COMMUNICATION ACCESS (within 24 hours) |
| +------------------------------------------------------------+ |
| | - Remove from distribution lists | |
| | - Reassign shared mailboxes | |
| | - Remove from Teams/Slack channels | |
| | - Update external contact lists | |
| +------------------------------------------------------------+ |
| | |
| v |
| PRIORITY 6: PHYSICAL ACCESS (within 48 hours) |
| +------------------------------------------------------------+ |
| | - Disable building access cards | |
| | - Collect physical keys | |
| | - Remove from visitor pre-approval lists | |
| | - Update emergency contact lists | |
| +------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+

Figure 1: Access revocation priority sequence showing risk-based ordering

Procedure

Phase 1: Identity provider account actions

Identity provider account actions block authentication to all connected systems. Execute these actions at the agreed revocation time.

  1. Sign in to the identity provider admin console with an account holding User Administrator or equivalent permissions.

    For Microsoft Entra ID:

https://entra.microsoft.com > Users > All users

For Google Workspace:

https://admin.google.com > Directory > Users

For Keycloak:

https://keycloak.example.org/admin > Users
  1. Locate the departing user’s account and open the account properties.

  2. Block sign-in before disabling the account. This prevents new authentications while allowing session revocation to complete.

    Microsoft Entra ID:

User properties > Settings > Block sign in: Yes > Save

Google Workspace:

User details > Security > Sign out user (forces immediate sign-out)
Then: Suspend user

Keycloak:

User details > Enabled: OFF > Save
  1. Revoke all active sessions. Users with existing sessions can continue accessing resources until tokens expire (typically 1 hour) unless sessions are explicitly revoked.

    Microsoft Entra ID (PowerShell):

Terminal window
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "User.ReadWrite.All"
# Revoke all sessions for the user
Revoke-MgUserSignInSession -UserId "j.smith@example.org"
# Expected output:
# Value
# -----
# True

Google Workspace (Admin console):

User details > Security > Sign out user

This forces sign-out from all devices and sessions.

Keycloak (Admin console):

User details > Sessions > Sign out all sessions
  1. Remove or disable MFA devices to prevent the user from completing authentication if the account is inadvertently re-enabled.

    Microsoft Entra ID:

User > Authentication methods > Delete all registered methods

Document which MFA methods were registered before deletion for audit purposes.

  1. Remove the user from any conditional access exclusion groups. Users sometimes get added to exclusion groups for troubleshooting; these must be cleared.

    Microsoft Entra ID:

Entra ID > Protection > Conditional Access > [Each policy]
Check Exclude section for user or groups containing user
  1. Document the completed actions with timestamps:
User: j.smith@example.org
Account blocked: 2024-11-15 17:00 UTC
Sessions revoked: 2024-11-15 17:02 UTC
MFA removed: 2024-11-15 17:03 UTC
Exclusions cleared: 2024-11-15 17:05 UTC
Completed by: admin@example.org

Phase 2: Privileged access removal

Privileged access requires immediate attention regardless of the user’s role. Even standard users may have accumulated administrative permissions through project work, temporary assignments, or permission creep.

  1. Review the user’s role assignments in the identity provider.

    Microsoft Entra ID (PowerShell):

Terminal window
# Get all directory role assignments for the user
Get-MgUserMemberOf -UserId "j.smith@example.org" |
Where-Object {$_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.directoryRole'} |
Select-Object -ExpandProperty AdditionalProperties |
Select-Object displayName
# Example output:
# displayName
# -----------
# Global Reader
# User Administrator
# Application Administrator
  1. Remove all administrative role assignments.

    Microsoft Entra ID:

Entra ID > Roles and administrators > [Role name] > Assignments
Select user > Remove

Repeat for each role identified in step 1.

  1. Check for Privileged Identity Management (PIM) eligible assignments that allow the user to activate admin rights.

    Microsoft Entra ID:

Entra ID > Identity Governance > Privileged Identity Management >
My roles > Review eligible assignments for the user

Remove all eligible assignments even if not currently activated.

  1. Identify service accounts or credentials the user managed. Query your password manager or PAM system for entries owned by or shared with the departing user.

    Example query (varies by system):

Owner = "j.smith@example.org" OR SharedWith contains "j.smith@example.org"

For each identified credential:

  • Rotate the password or key immediately
  • Transfer ownership to the user’s manager or a designated administrator
  • Document the rotation with timestamp
  1. Remove the user from privileged access groups. Common group patterns include:
IT-Admins
Server-Administrators
Database-Admins
Security-Team
Cloud-Administrators

Microsoft Entra ID (PowerShell):

Terminal window
# Remove user from a specific group
Remove-MgGroupMember -GroupId "[group-object-id]" -DirectoryObjectId "[user-object-id]"
  1. If using a PAM solution (CyberArk, HashiCorp Vault, Delinea), remove the user’s access to the vault.

    HashiCorp Vault:

Terminal window
# Revoke all tokens for the user
vault token revoke -mode=path auth/ldap/login/j.smith
# Remove user from Vault policies
vault write auth/ldap/users/j.smith policies=""
  1. Document privileged access removal:
User: j.smith@example.org
Roles removed: Global Reader, User Administrator, Application Administrator
PIM assignments removed: Exchange Administrator (eligible)
Service accounts rotated: svc-backup (password), api-integration (key)
Privileged groups removed: IT-Admins, Cloud-Administrators
PAM access revoked: Vault auth revoked
Completed: 2024-11-15 17:30 UTC
Completed by: admin@example.org

Phase 3: Data handling

Data handling ensures organisational data remains accessible while respecting retention requirements and the departing user’s privacy rights regarding personal data.

+-------------------------------------------------------------+
| DATA HANDLING DECISION TREE |
+-------------------------------------------------------------+
| |
| +-------------------+ |
| | Identify data | |
| | owned by user | |
| +--------+----------+ |
| | |
| v |
| +--------+----------+ |
| | Is data | |
| | organisational | |
| | or personal? | |
| +--------+----------+ |
| | |
| +----------------+----------------+ |
| | | |
| v v |
| +--------+--------+ +--------+--------+ |
| | ORGANISATIONAL | | PERSONAL | |
| | (work files, | | (private photos,| |
| | emails, docs) | | personal docs) | |
| +--------+--------+ +--------+--------+ |
| | | |
| v v |
| +--------+--------+ +--------+--------+ |
| | Transfer to | | Allow user to | |
| | manager or | | export before | |
| | designated | | departure | |
| | successor | | (with approval) | |
| +--------+--------+ +--------+--------+ |
| | | |
| v v |
| +--------+--------+ +--------+--------+ |
| | Retain per | | Delete after | |
| | retention | | user confirms | |
| | schedule | | export complete | |
| +-----------------+ +-----------------+ |
| |
+-------------------------------------------------------------+

Figure 2: Data handling decision tree for departing user content

  1. Generate an inventory of data owned by the departing user.

    Microsoft 365 (SharePoint/OneDrive):

Terminal window
# Connect to SharePoint Online
Connect-SPOService -Url https://example-admin.sharepoint.com
# Get OneDrive site for user
$onedrive = Get-SPOSite -IncludePersonalSite $true -Filter "Owner -eq 'j.smith@example.org'"
# Get storage used
$onedrive | Select-Object Url, StorageUsageCurrent
# Example output:
# Url StorageUsageCurrent
# --- -------------------
# https://example-my.sharepoint.com/personal/j_smith 4521 MB

Google Workspace:

Admin console > Reports > User reports > Accounts
Filter by user > Review Drive storage usage
  1. Coordinate with the line manager to identify:

    • Which files require immediate transfer (active projects)
    • Which files should be archived (completed work)
    • Which files can be deleted (duplicates, drafts, personal items)

    Document these decisions in writing.

  2. Transfer ownership of critical files to the designated successor.

    Microsoft OneDrive (PowerShell):

Terminal window
# Transfer OneDrive ownership (must be done before account deletion)
Set-SPOUser -Site $onedrive.Url -LoginName "manager@example.org" -IsSiteCollectionAdmin $true

Google Drive:

Admin console > Apps > Google Workspace > Drive and Docs >
Transfer ownership > Select user > Transfer to new owner
  1. Handle email data according to organisational policy and legal requirements.

    Email retention options:

    OptionUse whenImplementation
    Litigation holdLegal matter pendingApply hold before any deletion
    Archive to shared mailboxOngoing business needConvert to shared, delegate to manager
    Export to PST/MBOXLong-term retentionExport, store in records system
    Delete after retentionNo business needDelete after retention period

    Microsoft 365 shared mailbox conversion:

Terminal window
# Convert to shared mailbox (preserves content, releases licence)
Set-Mailbox -Identity "j.smith@example.org" -Type Shared
# Grant manager access
Add-MailboxPermission -Identity "j.smith@example.org" -User "manager@example.org" -AccessRights FullAccess
# Optional: Set up forwarding during transition
Set-Mailbox -Identity "j.smith@example.org" -ForwardingAddress "manager@example.org"
  1. Configure automatic replies to inform external contacts.
Subject: [Name] has left [Organisation]
Thank you for your email. [Name] is no longer with [Organisation].
For matters related to [project/area], please contact [successor name]
at [successor email].
For general enquiries, please contact [department email].

Set this auto-reply for 30 days minimum, 90 days for senior roles with extensive external contacts.

  1. Remove the user from shared resources and transfer ownership where needed.

    SharePoint sites:

Terminal window
# Get sites where user has permissions
Get-SPOSite -Limit All | ForEach-Object {
$perms = Get-SPOUser -Site $_.Url -LoginName "j.smith@example.org" -ErrorAction SilentlyContinue
if ($perms) { Write-Output $_.Url }
}
# Remove from each identified site
Remove-SPOUser -Site "[site-url]" -LoginName "j.smith@example.org"

Teams ownership:

Teams admin center > Teams > [Team name] > Members
If user is owner: Add new owner before removing user
Remove user from team
  1. Document all data handling actions:
User: j.smith@example.org
OneDrive: 4.5 GB transferred to manager@example.org
Email: Converted to shared mailbox, manager granted access
Auto-reply: Configured for 90 days
SharePoint: Removed from 12 sites
Teams: Ownership transferred for 3 teams, removed from 8 teams
Completed: 2024-11-15 19:00 UTC

Phase 4: Application access removal

Application access removal addresses systems that do not use single sign-on or that maintain local accounts alongside federated authentication.

  1. Generate a list of applications with user access from your identity governance system or application inventory.

    Microsoft Entra ID:

Entra ID > Enterprise applications > Users and groups
Filter by user to see assigned applications

If no central inventory exists, check common applications manually:

  • HR system (BambooHR, Workday, Sage People)
  • Finance system (Xero, Sage, NetSuite)
  • CRM (Salesforce, HubSpot, Dynamics)
  • Project management (Asana, Monday, Jira)
  • Grants management (FlexiGrant, Blackbaud)
  • Programme systems (Primero, CommCare, DHIS2)
  1. Remove application assignments from the identity provider. This prevents SSO access.

    Microsoft Entra ID (PowerShell):

Terminal window
# Get application assignment
$assignment = Get-MgUserAppRoleAssignment -UserId "j.smith@example.org" |
Where-Object {$_.ResourceDisplayName -eq "Salesforce"}
# Remove assignment
Remove-MgUserAppRoleAssignment -UserId "j.smith@example.org" -AppRoleAssignmentId $assignment.Id
  1. For applications with local accounts (not federated), disable or remove the account directly in each application.

    Salesforce:

Setup > Users > Find user > Edit > Active: unchecked

Jira/Confluence (Atlassian):

Administration > User management > Find user > Deactivate

Do not delete accounts in applications where audit trails must be preserved. Deactivation maintains history while preventing access.

  1. Revoke personal access tokens and API keys.

    GitHub:

Organisation settings > People > Find user > Convert to outside collaborator or Remove

Note: Personal access tokens in repositories must be rotated if the user had commit access.

GitLab:

Admin Area > Users > Find user > Block user
  1. Check for OAuth application consents granted by the user that could allow third-party applications continued access.

    Microsoft Entra ID:

Entra ID > Users > [User] > Applications > Review consented apps

Revoke consents for applications that should not retain access to organisational data.

  1. Remove the user from external platforms where they represented the organisation:

    • Social media management tools (Hootsuite, Buffer)
    • Advertising platforms (Google Ads, Meta Business)
    • Developer portals (AWS, Azure, GCP consoles)
    • Domain registrar accounts

    Transfer ownership before removing access where the user was the sole administrator.

  2. Document application access removal:

User: j.smith@example.org
SSO applications removed: 14 (via Entra ID assignment removal)
Local accounts deactivated: Salesforce, DHIS2, Primero
API tokens revoked: GitHub (2 tokens), Jira API key
OAuth consents revoked: 3 third-party applications
External platforms: Removed from Google Ads, transferred Buffer ownership
Completed: 2024-11-15 20:00 UTC

Phase 5: Device collection and processing

Device collection recovers organisational assets and ensures data on devices is handled appropriately.

  1. Generate a list of devices assigned to the departing user from your MDM or asset management system.

    Microsoft Intune:

Intune admin center > Devices > All devices
Filter: Primary user = j.smith@example.org

Jamf:

Computers > Search > Username = j.smith
Mobile Devices > Search > Username = j.smith

Record device serial numbers, types, and assignment dates.

  1. Coordinate device return logistics with the user and their manager:

    • Return date and time
    • Return location (office, courier, field office)
    • Accessories to return (chargers, cases, peripherals)
    • For remote workers: Prepaid shipping materials
  2. When devices are returned, verify against the inventory:

Device inventory for j.smith@example.org:
[ ] MacBook Pro 14" - Serial: C02XYZ123456
[ ] iPhone 14 - Serial: DNQXYZ789012
[ ] USB security key - Yubico 5 NFC
[ ] Power adapters and cables
[ ] Laptop bag
  1. Process returned devices according to their disposition:

    Devices to be reassigned:

    • Remove from user’s MDM assignment
    • Factory reset through MDM before physical reset
    • Verify reset completed successfully
    • Update asset inventory with new status

    Microsoft Intune remote wipe:

Devices > [Device] > Overview > Wipe
Select: Retain enrollment state and user account: No
Select: Wipe device, but keep enrollment and associated user account: No (full wipe)

Jamf remote wipe:

Computers > [Device] > Management > Wipe Computer
  1. For devices containing sensitive data that will be decommissioned, execute secure data destruction:

    For SSDs and flash storage:

    • Use manufacturer secure erase (ATA Secure Erase)
    • Or physical destruction for highly sensitive data

    For HDDs:

    • NIST SP 800-88 compliant wipe (minimum 1 pass)
    • Or physical destruction

    Document destruction with certificate of destruction including serial numbers.

  2. Update asset management records:

Device: MacBook Pro 14" - C02XYZ123456
Previous assignee: j.smith@example.org
Returned: 2024-11-15
Action: Wiped, reassigned to new-user@example.org
Updated by: it-admin@example.org
  1. Recover software licences where licences are tied to the user rather than the device:

    • Named user licences (Adobe Creative Cloud, Microsoft 365)
    • Development tool licences (JetBrains, Visual Studio)
    • Specialist software licences

    Remove assignments in the relevant admin portal and update licence tracking.

Phase 6: Audit log preservation and documentation

Audit log preservation maintains records required for compliance, potential disputes, and security investigations. This step executes regardless of departure circumstances.

  1. Verify that sign-in and activity logs covering the user’s tenure are preserved.

    Microsoft Entra ID sign-in logs: Default retention is 30 days. For longer retention:

Entra ID > Monitoring > Diagnostic settings
Verify SignInLogs are exported to Log Analytics or storage account

Query to extract user’s sign-in history:

SigninLogs
| where UserPrincipalName == "j.smith@example.org"
| where TimeGenerated > ago(365d)
| project TimeGenerated, AppDisplayName, ResultType, IPAddress, Location
  1. Export activity logs from applications where the user had significant access.

    Microsoft 365 Unified Audit Log:

Terminal window
# Search audit log for user activity
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) `
-UserIds "j.smith@example.org" -ResultSize 5000 |
Export-Csv -Path "j.smith_audit_log.csv" -NoTypeInformation

Google Workspace Admin Audit:

Admin console > Reports > Audit and investigation > User log events
Filter by user email
Export to CSV
  1. Preserve access review records showing what access the user had at departure.

    Export from identity governance system:

- Group memberships at departure date
- Application assignments at departure date
- Role assignments at departure date
- Access certification history
  1. Document the complete offboarding record:
OFFBOARDING RECORD
==================
User: Jane Smith (j.smith@example.org)
Employee ID: EMP-2019-0456
Department: Programme Operations
Manager: m.jones@example.org
Departure Details:
- Last working day: 2024-11-15
- Departure type: Resignation
- Notice period: 4 weeks (worked in full)
Access Revocation:
- Identity provider disabled: 2024-11-15 17:00 UTC
- Sessions revoked: 2024-11-15 17:02 UTC
- Privileged access removed: 2024-11-15 17:30 UTC
- Application access removed: 2024-11-15 20:00 UTC
Data Handling:
- OneDrive: Transferred to manager
- Email: Converted to shared mailbox
- Auto-reply: Active until 2025-02-15
Devices:
- MacBook Pro: Returned, wiped, reassigned
- iPhone: Returned, wiped, in stock
Licences Recovered:
- Microsoft 365 E3: Released
- Adobe Creative Cloud: Released
Completed by: it-admin@example.org
Completion date: 2024-11-15
Manager sign-off: m.jones@example.org (2024-11-16)
HR sign-off: hr@example.org (2024-11-16)
  1. Store the offboarding record according to retention policy. Employment records including access documentation typically require retention of 6 years in the UK (HMRC requirement) or as specified by HR policy.

Involuntary Departure Variations

Involuntary departures require modified procedures to address immediate security requirements and potential legal considerations.

Termination for cause

When termination follows misconduct, policy violation, or other disciplinary cause:

Timing adjustment: Revoke access simultaneously with or immediately before the termination meeting. Coordinate with HR on exact timing. The user should not have system access after being informed of termination.

Evidence preservation: If the termination involves potential fraud, data theft, or other serious misconduct:

  • Place litigation hold on the user’s mailbox and files before revocation
  • Do not wipe devices until cleared by legal
  • Preserve full audit logs
  • Follow Insider Threat Investigation procedures if investigation is ongoing

Device handling: Collect devices at the termination meeting where possible. If the user has devices at home, arrange immediate courier collection or supervised device wipe if courier collection is not feasible.

Redundancy

Redundancy situations require sensitivity while maintaining security:

Notice period: Users made redundant often work extended notice periods. Maintain access during this period but:

  • Review and remove any privileged access not required for notice period duties
  • Monitor for unusual data access patterns
  • Prepare for immediate revocation if behaviour changes

Staged offboarding: Consider a phased approach:

  • Week 1-3: Full access for handover
  • Week 4: Remove sensitive system access, retain email and files
  • Final day: Complete revocation

Immediate departure (garden leave)

When the user is paid through notice but not working:

Immediate revocation: Execute full access revocation on the garden leave start date.

Communication access: Consider retaining limited access to email (read-only, no send) if the user needs to monitor for personal messages during garden leave. Implement via:

  • Convert mailbox to shared
  • Grant read-only access to user’s personal device (conditional access policy)
  • Auto-forward incoming mail to personal address

Verification

Complete the following verification checks after all offboarding steps.

Authentication verification:

Terminal window
# Verify user cannot authenticate
# Attempt should fail with "Account is disabled"
# Microsoft Entra ID
Get-MgUser -UserId "j.smith@example.org" | Select-Object AccountEnabled
# Expected: AccountEnabled = False
# Test sign-in (from test environment)
# Expected result: Sign-in blocked

Application access verification: Test access to 3-5 critical applications from a test account or by checking application user lists:

Application: Salesforce
User status: Inactive
Last access: 2024-11-15 16:45
Application: SharePoint
User status: Not found in site permissions

Device verification:

Device: MacBook Pro C02XYZ123456
MDM status: Wiped
Current assignment: None (in stock)
Device: iPhone DNQXYZ789012
MDM status: Wiped
Current assignment: None (in stock)

Email verification:

  • Send test email to departed user’s address
  • Verify auto-reply received
  • Verify forwarding works (if configured)
  • Verify manager can access shared mailbox

Documentation verification:

  • Offboarding record complete with all timestamps
  • Manager sign-off obtained
  • HR sign-off obtained
  • Audit logs exported and stored

Troubleshooting

SymptomCauseResolution
User reports continued access after revocationSession tokens not revoked; cached credentialsForce session revocation via PowerShell; wait for token expiry (typically 1 hour); verify conditional access forces re-authentication
Cannot find all user’s application accessNo central inventory; applications not integrated with IdPCheck with department heads; search application admin consoles manually; add to inventory for future
Shared mailbox shows no contentMailbox not converted; litigation hold preventing accessVerify conversion completed; check hold status; contact Microsoft support if content missing
Device shows as enrolled but user claims returnedDevice in transit; MDM sync delayWait 24 hours; check with courier; verify device serial matches
Manager cannot access departed user’s filesPermissions not transferred; files in personal OneDriveTransfer ownership explicitly; for OneDrive, ensure manager is site collection admin
External contacts complain of bounced emailsMailbox deleted instead of converted; forwarding misconfiguredIf mailbox exists, verify configuration; if deleted within retention, recover; if beyond retention, configure new forwarding
Application blocks account deletion citing active sessionsApplication session management independent of IdPSign in to application admin; force session termination; then disable account
Audit log export failsLog retention expired; insufficient permissionsCheck retention settings; request elevated permissions; for expired logs, document the gap
Licence not released after removalLicence assignment cached; subscription requires manual actionWait 24-48 hours; check vendor admin portal; open support ticket if persists
User’s calendar appointments remain visible to othersCalendar sharing persists; appointments not removedRemove calendar delegation explicitly; for persistent appointments, delete or transfer ownership
Cannot wipe device remotelyDevice offline; MDM agent removed; device not enrolledWait for device to come online; if agent removed, arrange physical return; verify device was enrolled
User retained access to external serviceService not federated; password not uniqueIdentify service; reset password directly in service; add to federation scope

Post-departure access discovery

If you discover access that was missed during offboarding, revoke immediately and document the gap. Review the offboarding checklist to prevent recurrence. Consider implementing automated access reviews that flag accounts inactive for extended periods.

See also