Employee Offboarding Procedure

Overview

When an employee leaves, access must be revoked across every system before or on their last day. An incomplete offboard leaves credentials and sessions active. This document is the authoritative cross-system checklist.

Owner: Rory
Triggered by: HR notification, manager request, or Rory directly

For contractor offboarding, follow the same procedure — contractors have the same access footprint as staff.

---

Timing

Scenario	When to Execute
Voluntary resignation (planned)	Last day of employment, during or after final shift
Involuntary termination	Immediately — before the employee is notified if possible
Security incident (suspected insider threat)	Immediately — coordinate with Arctic Wolf
Contract end (known date)	On contract end date

If there is any doubt about intent (involuntary, acrimonious departure, active incident), execute all steps immediately and without warning.

---

Step 1 — Entra ID (Do First)

Entra is the identity root. Blocking here cascades to everything that relies on Entra SSO.

# Block sign-in (immediate effect — all new auth attempts fail)
Update-MgUser -UserId "user@ciriusgroup.com" -AccountEnabled $false

# Revoke all active sessions (kills current browser sessions, tokens)
Revoke-MgUserSignInSession -UserId "user@ciriusgroup.com"

Or via portal: Entra ID → Users → [user] → Block sign-in → Yes, then Revoke sessions.

After blocking:

• Remove from all security groups (Twingate groups will drop automatically — see §4)
• Remove Microsoft 365 license (free up the seat)
• Do not delete the account yet — hold for 30 days (see §10)

For DDE tenant (ciriusdde.com): repeat if the user had a DDE account.

---

Step 2 — OneLogin

Once Entra is blocked, the SCIM connector will automatically suspend the OneLogin account within minutes. Verify it happened:

OneLogin Admin → Users → [user] → Status should show: Suspended

If the SCIM sync hasn't run yet and you need immediate suspension: OneLogin Admin → Users → [user] → More Actions → Suspend User

A suspended OneLogin account cannot authenticate any SAML app (Cloudflare Access, Keeper, Zendesk, KnowBe4).

---

Step 3 — Keeper

The user's Keeper vault is tied to their Entra SSO login. Once Entra is blocked, they can't log in to Keeper via SSO.

Additional steps in Keeper Admin Console:

1. Admin Console → Users → [user] → Force Logout — kills any active Keeper session
2. Admin Console → Users → [user] → Remove from all shared folders — revoke access to shared credentials (shared folders: Break-Glass, Infrastructure — Shared, etc.)
3. If the user was a Keeper admin, remove their admin role

Check what shared folders they had access to and note them. If they had access to shared credentials (not just viewing their own vault), rotate those credentials — they may have memorized or copied them.

---

Step 4 — Twingate

Twingate access is controlled by Entra group membership. When you removed the user from Entra groups in §1, Twingate group sync removes them from:

• AllStaff → loses access to all standard resources
• PrivilegedUsers → loses access to privileged resources (if applicable)
• ContractorAccess → loses contractor resource access (if applicable)

Verify in Twingate Admin Console: Twingate → Users → [user] → Groups should be empty or the user should be marked inactive

If Twingate is not syncing from Entra groups, manually remove the user: Twingate → Users → [user] → Remove from all groups

---

Step 5 — GitHub

Remove the user from the GitHub org if they were a member:

gh api --method DELETE /orgs/Cirius-Group-Inc/members/<github-username>

Or via portal: GitHub → Cirius-Group-Inc → People → [user] → Remove from organization

Check if the user had any personal forks of org repos — these remain even after removal but are not a concern unless they contain sensitive data.

If the user was a repository admin for any repo, check and reassign those permissions.

---

Step 6 — Zendesk (If Applicable)

If the user was a Zendesk agent:

1. Zendesk Admin → People → Team members → [user] → Downgrade to end user or Suspend agent
2. Reassign any open tickets the agent owned to another agent or queue
3. If the user had any API tokens: Admin → API → Tokens → revoke their token

If the user only accessed Zendesk as an end user (submitted tickets), no action needed.

---

Step 7 — KnowBe4

KnowBe4 Admin → Users → [user] → Archive user

Archiving removes them from active training campaigns but retains their completion history for compliance records.

---

Step 8 — Arctic Wolf

Notify Arctic Wolf that the user has been offboarded. They may have:

• The user's email in CMDB records
• Detection rules that reference the user's account
• User behavior baselines that need to be cleared

Contact: Arctic Wolf customer portal or 24/7 support line (in Keeper → Vendor Accounts).

Provide: user's email, last day, reason (voluntary / involuntary — they handle each differently).

---

Step 9 — Shared Credentials Rotation

Review whether the departing employee had access to any shared credentials:

Credential Type	Where to Check	Action
Shared Keeper folders they were in	Keeper Admin → [user] → Folder access	Rotate any passwords they could have copied
Service account passwords they knew	Ask their manager	Rotate
Any physical emergency kits they had access to	Physical security officer	Verify seal/access log
Panorama / firewall admin passwords (if they were infrastructure)	Break-glass in Keeper	Rotate if they had access

Rotation is not always required — a user with read-only access to a shared folder that contains only vendor contact info doesn't require rotation. Use judgment based on what they could actually have exfiltrated.

---

Step 10 — Mailbox Handling

Do not delete the M365 mailbox immediately. Convert it to a shared mailbox:

Set-Mailbox -Identity "user@ciriusgroup.com" -Type Shared

Then:

• Set an auto-reply: "This employee is no longer with Cirius Group. For assistance, contact [manager or team email]."
• Grant Full Access to their manager or a designated delegate
• Retain the shared mailbox for 30 days minimum; 1 year if the role handled customer communications (HIPAA-adjacent mailboxes)

---

Step 11 — 30-Day Hold and Deletion

After 30 days from the last day:

1. Confirm no outstanding items require the account (pending HR/legal holds, active litigation, data access requests)
2. Export any necessary data from their OneDrive if not already done
3. Entra ID → Users → [user] → Delete user

Deleted Entra accounts are soft-deleted and recoverable for 30 days before permanent deletion. This gives a 60-day total window from offboarding to permanent erasure.

---

Completion Checklist

After completing all steps, document the offboarding:

Step	System	Completed	Notes
1	Entra — block sign-in + revoke sessions
1	Entra — remove from groups + remove license
1	Entra DDE — block (if applicable)
2	OneLogin — verify suspended
3	Keeper — force logout + remove from shared folders
4	Twingate — verify removed from groups
5	GitHub — removed from org
6	Zendesk — agent suspended (if applicable)
7	KnowBe4 — archived
8	Arctic Wolf — notified
9	Shared credentials — rotated where needed
10	Mailbox — converted to shared + auto-reply set
30d	Entra — account deleted

Keep a copy of this completed checklist for audit evidence.

---

Related Documents

• Entra Identity Operations — detailed Entra account management
• Keeper Credential Guide — shared folder structure and admin steps
• GitHub Org Management — GitHub access details
• Key Rotation Schedule — when credential rotation is required
• Incident Response — if offboarding is triggered by a security incident

---

Document History

Date	Change	Author
May 2026	Initial draft — cross-system offboarding checklist: Entra, OneLogin, Keeper, Twingate, GitHub, Zendesk, KnowBe4, Arctic Wolf, shared credentials, mailbox handling, 30-day hold.	Rory