The Cybersecurity Risks of Former Employees

The Cybersecurity Risks of Former Employees

An employee leaves the company on Friday.

HR finishes the paperwork. The laptop comes back. IT disables the Microsoft 365 account.

Everything looks finished.

Three weeks later, somebody discovers that the former employee still has a separate project-management login, a personal access token connected to company repositories, access to a vendor portal, and files that had synchronized to a personal computer.

Nobody intentionally left the access open.

It simply wasn't part of the checklist.

Former employees can create cybersecurity risk when identities, accounts, sessions, credentials, devices, files, or integrations remain usable after the legitimate business need ends. The issue is usually not malicious intent. The issue is that businesses underestimate how many different forms of access one person accumulates.

A good offboarding process should know what to disable, revoke, transfer, recover, preserve, rotate, and verify.

Most Former Employees Are Not Cybersecurity Threats

This distinction matters.

Most departures are routine.

People resign. Contracts end. Employees retire. Internships finish. Companies reorganize.

Removing access is not an accusation.

Yesterday the person had a legitimate business reason to use company systems.

Today that authorization may no longer exist.

That's the security change.

The purpose of offboarding is to remove access because the business relationship changed—not because the company assumes malicious intent.

Former-Employee Access Risk vs. Insider Threat

These terms should not be treated as interchangeable.

Former-Employee Access Risk

Access or company information remains available after the person no longer needs it.

Examples:

• Account never disabled

• SaaS login forgotten

• Token remains valid

• Personal computer still synchronizes files

• Shared password remains unchanged

This can happen completely accidentally.

Insider Threat

CISA uses insider-threat terminology more broadly for risks involving people with authorized or previously authorized access, including accidental, negligent, compromised, and intentional activity.

That is a broader security concept.

Do not label somebody an insider threat simply because they left the company.

A routine employee departure is an access-lifecycle event.

Offboarding Is an Identity Lifecycle Process

Offboarding is often treated like this:

Return laptop

↓

Disable email

↓

Done

That's too narrow for modern business environments.

A person may accumulate access to:

• Microsoft 365

• Google Workspace

• Okta

• Entra ID

• VPN

• Slack

• CRM

• Accounting

• Project management

• Help desk

• Cloud infrastructure

• Git repositories

• Password manager

• Vendor portals

• Customer systems

• API tokens

• SSH keys

• AI tools

• Local files

• Shared folders

Offboarding is an identity-and-access lifecycle process—not simply an HR checklist or laptop-return process.

NIST CSF 2.0's Identity Management, Authentication, and Access Control category says identities and credentials should be organizationally managed and access should be limited to authorized users, services, and hardware. Its implementation examples specifically include managing and revoking identity tokens, keys, certificates, and other credentials.

Joiner, Mover, Leaver

A useful identity-management model is:

Joiner

Someone begins working with the organization.

Accounts and appropriate access are provisioned.

Mover

The person's role changes.

New access may be granted.

Old access should be reviewed and removed when it is no longer appropriate.

Leaver

Employment or the contractual relationship ends.

Access should be removed according to organizational policy and the effective separation timing.

CISA and NSA's identity-governance guidance describes these Join, Move, and Leave lifecycle events for employees and contractors.

This is why good offboarding actually starts during onboarding.

If nobody documented what access was granted, revoking it later becomes guesswork.

Risk 1 — The Main Identity Is Disabled, but Other Accounts Survive

Suppose IT disables an employee in Microsoft Entra ID.

Good.

But the person also has separate credentials for:

• Dropbox

• CRM

• Adobe

• Vendor portal

• Webinar platform

• Marketing software

• Scheduling system

Those accounts might not depend on the central identity at all.

Central identity improves control.

It does not automatically give IT visibility into every independently created account.

SSO Helps—but It Is Not Magic

SSO, or Single Sign-On, allows applications to authenticate users through a centralized identity provider.

That can make offboarding much cleaner.

Disable the central identity and applications relying on that identity can stop accepting new authentication.

But:

• Not every application uses SSO.

• Some users may have local passwords.

• Existing sessions can behave differently.

• API tokens may remain.

• Service identities may be independent.

• Some apps have incomplete provisioning support.

SSO can simplify offboarding. It does not eliminate the offboarding checklist.

SimplyRem's current Security practice publishes identity work around Okta, Entra ID, JumpCloud, SSO, MFA, Conditional Access, least privilege, joiner-mover-leaver automation, and privileged access management.

What Is SCIM?

SCIM stands for System for Cross-domain Identity Management.

It is commonly used to automate provisioning and deprovisioning between identity platforms and compatible applications.

Conceptually:

Employee leaves

↓

Identity platform changes lifecycle status

↓

SCIM provisioning process runs

↓

Supported SaaS application deactivates downstream access

This reduces reliance on somebody remembering 20 separate admin consoles.

But do not assume SCIM always works perfectly.

Okta's current documentation notes that downstream deprovisioning depends on the application integration supporting and enabling that behavior, and some applications still require manual action.

Automation needs verification.

Risk 2 — Active Sessions Remain

Here's where offboarding gets messy.

Disabling an account and terminating every existing session are related—but not necessarily identical—actions.

A user may already be signed in through:

• Browser

• Outlook

• Teams

• Mobile app

• Tablet

• SaaS client

Microsoft's current Entra documentation explicitly distinguishes disabling a user from revoking refresh tokens and explains that application-issued session cookies may follow the application's own lifecycle and authorization behavior.

That is why:

“We blocked sign-in”

is not always the complete session-management answer.

What Is a Refresh Token?

At a high level, a signed-in application may hold a token that lets it obtain new access without requiring the user to type the password repeatedly.

That is normal application behavior.

During offboarding, the relevant platform may support actions such as:

• Disable identity

• Revoke sessions

• Revoke refresh tokens

• Remove application access

The exact behavior varies by platform.

Do not assume changing a password instantly invalidates every session in every application.

Google Workspace Has Similar Lifecycle Distinctions

Google Workspace administrators can suspend a user without deleting the user's data. Google states that a suspended user loses access to Workspace services while organizational data remains available for administrative handling.

Permanent deletion is a different lifecycle action, and Google provides separate processes for transferring Drive ownership before account removal.

That distinction matters:

Remove access first when required. Handle data and account deletion deliberately.

Risk 3 — SaaS Accounts Nobody Knew About

This is one of the biggest practical offboarding gaps.

Employees might independently adopt:

• Canva

• Notion

• Dropbox

• AI assistants

• E-signature tools

• Scheduling software

• Marketing platforms

• Project-management tools

• Webinar services

• CRM add-ons

Some use company cards.

Some are free.

Some begin as a two-week experiment and quietly become part of the workflow.

IT cannot revoke what it does not know exists.

SimplyRem's current cloud-sprawl guidance makes this exact governance problem visible: unmanaged SaaS, former-employee accounts, unknown ownership, and shadow IT make technology harder to secure and retire.

Free SaaS Still Matters

No invoice does not mean no security risk.

A free application may contain:

• Customer information

• Documents

• Work email

• Company notes

• Cloud-storage permissions

• OAuth access

Free software can still contain expensive data.

Risk 4 — OAuth Applications

Employees may authorize third-party applications to access services such as:

• Google Workspace

• Microsoft 365

• Slack

• GitHub

• Salesforce

through OAuth.

Google Workspace administrators can review third-party applications that have accessed organizational data and the OAuth scopes those applications requested.

Offboarding and periodic access reviews should include connected applications where relevant.

Risk 5 — API Tokens and Personal Access Tokens

For technical employees, interactive login is only part of the access picture.

They may have created:

• GitHub personal access tokens

• API tokens

• CI/CD credentials

• Cloud access keys

• Integration secrets

A token may continue supporting:

• Deployment

• Integration

• Automation

• Monitoring

• Scheduled jobs

even after normal interactive access is removed.

Do not revoke everything blindly.

That can break production.

First identify what the token does. Then replace or revoke it safely.

AWS's current IAM guidance likewise recommends identifying and removing or deactivating credentials that former users no longer require.

Risk 6 — SSH Keys

Developers and administrators may have personal SSH keys authorized on:

• Servers

• Git repositories

• Network devices

• Cloud systems

Offboarding should review where those user-specific keys remain trusted.

Better architecture favors:

• Individual identities

• Centralized access

• Key inventory

• Lifecycle management

• Auditability

rather than mystery keys in configuration files nobody remembers.

Risk 7 — Shared Passwords

Shared passwords make clean offboarding harder.

Examples include:

• Vendor portal

• Wi-Fi administration

• Social-media login

• Shared SaaS account

• Old server administrator account

If five people know one credential, you cannot revoke only one person.

If a former employee knew a sensitive shared password, the credential may need controlled rotation.

NIST's current CSF implementation examples recommend unique identifiers and discourage credential sharing as part of identity management.

Password Managers Help—but Don't Solve Everything

If the company uses a password manager, remove the departed user's access to appropriate:

• Vaults

• Collections

• Groups

• Shared credentials

But remember:

Removing somebody from a vault does not erase a password they already knew.

For sensitive shared secrets, evaluate rotation based on exposure and business risk.

Risk 8 — Privileged Access

Former administrators deserve additional review because their legitimate job required broader access.

They may have held roles such as:

• Global administrator

• Domain administrator

• Cloud administrator

• GitHub organization owner

• Network administrator

• Billing administrator

• SaaS super-admin

Normal-user offboarding and privileged-user offboarding should not be identical.

If the employee had both:

Standard user identity

and

Separate administrative identity

both need lifecycle handling.

Cloud Infrastructure Access

AWS, Azure, Google Cloud, and other infrastructure platforms can contain:

• Human identities

• Roles

• Groups

• Access keys

• Service principals

• Service accounts

• API credentials

Do not confuse a former employee's personal access with a legitimate non-human service identity.

Google Cloud explicitly recommends that service accounts be treated as organizational resources rather than as employee identities and warns that blindly deleting service identities can break workloads.

That is a useful principle across cloud platforms.

Risk 9 — Company Data on Personal Devices

Remote and BYOD environments complicate offboarding.

Employees may have had:

• Synced cloud folders

• Email

• Chat

• Screenshots

• Source code

• Downloaded documents

Technical revocation cannot necessarily pull back every copy that already left the managed environment.

That is why prevention matters:

• Data classification

• Least privilege

• Managed applications

• Device-management architecture

• Company-data boundaries

• Appropriate policies

For personal devices, use organization-approved controls and appropriate HR/legal guidance.

Do not assume the company can—or should—wipe an entire personal phone or laptop.

Company-Owned Devices

When a company laptop or phone comes back, review:

• Physical possession

• Encryption

• Management status

• Local business data

• Security agent

• User assignment

• Reimage/wipe process

• Reassignment or retirement

SimplyRem's current mixed Windows/Mac management guidance includes identity disablement, session revocation, application access removal, device recovery, approved data preservation, device erasure, reassignment, and inventory updates.

Returning the laptop matters.

It is not the whole offboarding process.

What If the Device Does Not Come Back?

Follow the organization's approved equipment and security process.

Technically, this may involve:

• Disabling organizational access

• Revoking sessions

• Using approved MDM controls

• Protecting company information

Do not turn the security process into an improvised property-recovery process.

Risk 10 — Email Access and Forwarding

Email offboarding should consider more than the primary password.

Review as appropriate:

• Account sign-in

• Active mobile clients

• Forwarding

• Mailbox delegation

• Shared mailbox permissions

• Send-as rights

• Application access

• Mailing groups

Do not immediately delete the mailbox before the business determines what records or communications need preservation.

Transfer the Mailbox; Don't Impersonate the Person

A business may need continued access to legitimate operational records.

Use supported:

• Delegation

• Retention

• Migration

• Transfer

• Shared mailbox

• Automatic reply

processes.

Do not casually continue sending email while pretending to be the former employee.

Risk 11 — File Ownership

Important business files may live in:

• OneDrive

• SharePoint

• Google Drive

• Dropbox

• Box

Before deletion ask:

• Who owns the files?

• Who needs them?

• Are they stored in a personal workspace?

• Do external sharing links remain active?

• Does ownership need transfer?

Google's current Workspace guidance specifically recommends transferring Drive ownership when a departing employee owns organizational files that need to remain available.

Risk 12 — Git and Source Code

For technical users, review:

• GitHub/GitLab/Bitbucket membership

• Teams

• Repository permissions

• PATs

• SSH keys

• Deploy keys

• CI/CD

• Package registries

• Secrets

GitHub currently states that removing an organization member removes repository access through that membership, but the former member can still retain local repository copies.

That is an important distinction.

Access revocation controls future system access.

It does not magically erase every file that was legitimately copied before departure.

CI/CD and Automation

A former developer may have created automation that uses credentials connected to their identity.

Examples:

• Deployment pipeline

• Backup script

• Monitoring job

• Scheduled integration

• Infrastructure automation

Before revoking a credential, identify dependencies.

Then replace personal credentials with properly managed service identities where appropriate.

Service Accounts

A service account is an identity intended for an application, service, or automation rather than normal interactive human use.

The problem is not that service accounts exist.

The problem is when nobody knows:

• Purpose

• Owner

• Credential location

• Permissions

• Dependencies

• Rotation process

Do not automatically disable a legitimate production service account merely because the employee who originally created it left.

Transfer ownership.

Risk 13 — VPN and Remote Access

Do not assume disabling email removes every remote-access path.

Review as appropriate:

• VPN identity

• VPN certificate

• Zero-trust access

• Remote desktop gateways

• Remote-support tools

• SSH

If certificates are involved, include them in the lifecycle review.

Risk 14 — Vendor and Partner Portals

Some of the most important access may sit completely outside your central identity system.

Examples:

• ISP portal

• Domain registrar

• Software vendor

• Hardware vendor

• Shipping account

• Insurance portal

• Payment platform

This is why an application and vendor inventory matters.

Domain and DNS Access Deserve Special Attention

A former web developer or marketing employee should not remain the only person who controls the company's:

• Domain

• DNS

• Hosting

• Certificates

SimplyRem's current IT-documentation guidance recommends organizational ownership, backup administration, recovery paths, and documentation for domains, DNS, cloud infrastructure, critical systems, and administrator access.

Infrastructure should survive the departure of one person.

Risk 15 — Customer Systems

Employees sometimes receive access to third-party systems belonging to customers or partners:

• Customer cloud tenant

• Customer VPN

• Partner portal

• Customer Git repository

• External support system

Those accounts need lifecycle handling too.

Offboarding should not stop at systems owned by your company.

Physical Access Still Matters

Coordinate with facilities or physical security where relevant for:

• Badge

• Office access

• Server-room access

• Keys

• Alarm access

Keep this coordinated with the broader departure process.

Risk 16 — MFA Methods

Review registered authentication methods according to platform capabilities:

• Authenticator app

• Phone number

• Security key

• Passkey

• Recovery method

Returning a physical security key does not necessarily remove its registration.

Likewise, removing registration does not replace physical asset recovery.

Handle both.

Risk 17 — Forgotten Groups, Channels, and Delegation

Review:

• Security groups

• Distribution lists

• Shared channels

• Slack workspaces

• Teams

• Project spaces

• Shared calendars

• Executive delegation

• Booking systems

These are easy places for access to outlive the relationship.

Risk 18 — AI Tools

Employees increasingly use:

• AI assistants

• Coding AI

• Meeting transcription

• AI search

• Writing tools

Review:

• Account ownership

• Company data

• Connected cloud storage

• API keys

• Integrations

SimplyRem's current private-AI guidance also treats offboarding as part of the identity model and recommends reviewing active sessions, groups, API tokens, AI application access, and cached material.

Do not assume every AI provider handles data the same way.

Shadow IT Makes Offboarding Harder

Shadow IT means systems used without normal IT/security visibility.

Useful SaaS discovery sources may include:

• SSO application catalog

• OAuth grants

• Procurement

• Expense data

• Password manager

• Department interviews

If nobody knows which systems the employee used, that's an inventory problem before it's an offboarding problem.

Contractors Need Offboarding Too

Apply lifecycle discipline to:

• Contractors

• Consultants

• Agencies

• Interns

• Temporary workers

• Vendors

CISA's JML model explicitly includes contractors in identity-lifecycle governance.

Contract expiration should be treated as an access-lifecycle event.

What About a Vendor's Employee?

Suppose your MSP, developer, accountant, or other vendor gives one of its employees access to your environment.

How do you learn when that person leaves the vendor?

Useful controls may include:

• Named accounts

• Time-limited access

• Periodic review

• Vendor notification process

• Explicit ownership

Do not let vendor access disappear into a generic shared login.

Planned Departure vs. Immediate Departure

Planned Departure

Where timing allows, you may be able to:

• Transfer knowledge

• Move files

• Change resource owners

• Document applications

• Move customer relationships

• Replace personal credentials

before access is removed.

Immediate or Higher-Risk Departure

HR, management, IT, security, and sometimes legal teams may need to coordinate access changes according to organizational policy.

There is no universal choreography appropriate to every termination.

HR and IT Need the Same Clock

One of the simplest offboarding failures looks like this:

HR knows Friday is the employee's last day

↓

IT finds out Monday

↓

Access remained active all weekend

The process needs an approved way to communicate:

• Effective separation time

• Employee/contractor identity

• Role

• Devices

• Systems

• Ownership-transfer needs

without unnecessarily exposing sensitive HR details.

Least Privilege Makes Offboarding Easier

Least privilege means users should have the access required for their work and no more than appropriate.

NIST CSF 2.0 specifically includes least privilege and separation of duties in PR.AA-05.

Why does that matter when somebody leaves?

Because an employee who accumulated seven years of old permissions creates a much larger cleanup project.

Don't Ignore the “Mover” Problem

An employee moves from Finance to Operations.

They receive Operations access.

Nobody removes Finance access.

Three years later they leave.

Now offboarding exposes years of privilege accumulation.

Identity governance should remove obsolete access throughout employment—not only at the end.

Periodic Access Reviews

Do not wait for resignation day to discover privileged access.

Based on risk, review things such as:

• High-impact SaaS

• Cloud platforms

• Privileged roles

• Customer systems

• External collaborators

There is no universal review frequency that fits every organization.

Transfer Data Ownership Before Permanent Deletion

A departing employee may own:

• Files

• Automations

• Forms

• Dashboards

• Calendars

• Reports

• Repositories

• Cloud resources

• Customer accounts

Transfer operational ownership before permanently deleting accounts where appropriate.

This is why:

Disable or suspend

and

delete

are different lifecycle decisions.

Google Workspace, for example, separates account suspension from deletion and provides explicit data-transfer procedures.

Don't Keep Disabled Accounts Forever Either

The opposite problem exists too.

Years of disabled identities can accumulate indefinitely.

Define archive, retention, and deletion processes based on:

• Business requirements

• Security

• Legal requirements

• Platform behavior

Do not invent retention periods from a generic blog post.

Shared-Secret Rotation

If the departing employee knew:

• Shared administrator password

• Vendor password

• Wi-Fi credential

• Application secret

evaluate whether rotation is required.

But be careful.

Changing an API key, database password, or service credential without understanding the dependency can break production.

Use controlled rotation:

Identify dependency

↓

Create or update replacement

↓

Update dependent systems

↓

Verify operation

↓

Retire old secret

Former Administrator Offboarding

High privilege simply requires a more complete checklist.

Review:

• Identity

• Privileged accounts

• Cloud

• Servers

• Network

• Password/secrets vault

• Repositories

• CI/CD

• Domain/DNS

• Security tools

• Tokens

• Keys

No drama.

Just completeness.

Developer Offboarding

Review:

• Git repositories

• Teams

• PATs

• SSH keys

• CI/CD

• Package registries

• Cloud

• Infrastructure-as-code

• Secrets

• Developer SaaS

Transfer ownership of:

• Code

• Pipelines

• Documentation

• Automation

Sales Offboarding

Review:

• CRM

• Email

• Sales tools

• Calling platform

• Contact databases

• Customer files

Transfer account and lead ownership appropriately.

Finance Offboarding

Review:

• Accounting system

• Expense platform

• Payment/banking roles

• Reporting

• Finance drives

Use a stricter role-specific review because the access is different.

Marketing Offboarding

Review:

• Website/CMS

• Social accounts

• Advertising

• Analytics

• Email marketing

• Design platforms

• Domain/DNS where applicable

Company-controlled ownership matters.

Remote Employees

Review:

• Laptop

• Phone/tablet

• VPN

• SaaS

• Synced company data

• Security keys

• Remote-support software

• Equipment return

Offboarding Is Not an Investigation

Use this as a policy mindset:

A routine employee departure is an access-lifecycle event, not automatically a security investigation.

Routine offboarding does not justify default surveillance of a person's private activities.

Organizational audit logs and security events may be reviewed according to company policy, legitimate security need, applicable law, and incident-response processes.

If suspicious activity is actually identified:

1. Preserve appropriate evidence.

2. Limit unauthorized access.

3. Follow the incident-response process.

4. Escalate appropriately.

5. Involve HR/legal/security where needed.

6. Investigate using authorized methods.

Before Departure

Where timing permits:

• Identify accounts

• Identify SaaS

• Identify privileged access

• Identify devices

• Identify customer/vendor systems

• Transfer data

• Transfer projects

• Transfer automations

• Transfer admin ownership

• Identify shared secrets

At Separation

According to approved timing:

• Disable primary identity

• Block new sign-ins

• Revoke sessions where supported

• Remove VPN/remote access

• Remove SaaS access

• Remove privileged roles

• Remove repository/cloud access

• Recover devices and security keys

• Address customer/vendor access

After Departure

Verify:

• Identity status

• Sessions

• SaaS

• Tokens

• Shared credentials

• File/data ownership

• Mailbox handling

• Device status

• Licenses

• Customer/vendor systems

• Documentation

Offboarding is not complete until somebody verifies the result.

Verification Is Usually the Missing Step

A checklist says:

Remove Salesforce.

Verification asks:

Does the administration console now show that the user no longer has access?

That's the difference.

Do not attempt unauthorized login simulations.

Verify through:

• Administrative status

• Provisioning logs

• Identity records

• Approved security testing

Automate What Makes Sense

A mature flow might be:

Authorized HR departure event

↓

Identity system

↓

SCIM / provisioning

↓

Supported applications

↓

Access removed

The benefit is consistency.

The risk is assuming the automation can never fail.

Possible failures include:

• SCIM error

• Application outage

• Local account

• Misconfiguration

• Unsupported application

Automation should therefore have:

• Logs

• Failure alerts

• Exceptions

• Verification

Good SaaS Inventory Makes Offboarding Easier

If the company already knows:

• Which applications exist

• Who owns them

• How users receive access

• Whether SSO/SCIM is configured

offboarding becomes much easier.

Good SaaS governance and good offboarding support each other.

Good IT Documentation Makes Offboarding Easier

Document:

• Identity platform

• Critical applications

• Administrators

• Cloud environments

• Vendor portals

• Device-management systems

• Approved secrets-management location

• Offboarding procedures

SimplyRem's current IT-documentation guidance explicitly recommends documenting how employees receive and lose access and who controls critical systems.

Document where the secret is managed—not the secret itself.

License Recovery Comes Later

Offboarding may free:

• Microsoft 365 seat

• SaaS subscription

• Adobe license

• Phone license

• Security product license

But license removal and access revocation are not necessarily the same operation.

And do not remove a license before required data-transfer workflows if the platform requires the license to complete them.

Understand the product first.

Zero Trust and Offboarding

Zero Trust does not mean:

“Trust nobody.”

The relevant principle is that access should depend on current identity, authorization, device, and policy—not simply on the fact that somebody once worked for the business.

When employment status changes, access should change too.

The Bottom Line

Most former employees are not cybersecurity threats.

Forgotten access is.

The company should know:

• Which identities existed

• Which SaaS applications were used

• Which devices were assigned

• Which privileged roles were held

• Which tokens and keys existed

• Which business data was owned

• Which shared credentials were known

• Which customer or vendor systems were accessible

Then the offboarding process should know how to:

Disable. Revoke. Transfer. Recover. Rotate. Verify.

Former-Employee-Risk-vs.-Insider-Threat Cards

Former Employee Access Risk

What it means

Access or business information remains available after the legitimate need ends.

Can be accidental?

Yes.

Examples

Forgotten account, active SaaS login, old token, synchronized files, shared password.

Insider Threat

What it means

A broader risk category involving people with legitimate or previously legitimate organizational access.

May involve

Accidental, negligent, compromised, or intentional activity.

Important

Leaving the company does not automatically make someone an insider threat.

Joiner / Mover / Leaver Cards

Joiner

Person starts.

Access is granted according to role.

Mover

Role changes.

New access is granted and obsolete access should be reviewed.

Leaver

Business relationship ends.

Access should be removed according to approved timing and policy.

Primary-Identity Card

Primary Identity

Examples

Entra ID, Google Workspace/Cloud Identity, Okta, JumpCloud.

Review

• Account status

• New sign-in

• Sessions

• Groups

• Applications

• MFA

• Devices

• Privileged roles

SSO Card

Single Sign-On

Benefit

Centralizes authentication for connected applications.

Offboarding advantage

Disabling the main identity can cut off new authentication to many connected applications.

Limit

Independent accounts, local passwords, sessions, tokens, and unsupported applications may remain.

Rule

SSO simplifies offboarding. It does not replace verification.

SCIM Card

SCIM

A standard commonly used for automated provisioning and deprovisioning.

Potential flow

Identity lifecycle change → SCIM → supported SaaS account deactivated.

Limit

Not every app supports SCIM and not every integration has deprovisioning enabled.

Active-Session Card

Active Sessions

Risk

The user may already be authenticated on a browser, desktop client, or mobile device.

Review

• User disablement

• Session revocation

• Refresh-token behavior

• Application-specific sessions

Important

Blocking new sign-in and terminating existing sessions can be different actions.

SaaS-Access Card

Forgotten SaaS Account

What happens

Primary identity is disabled but an independently managed SaaS login remains active.

Review

• Account

• SSO

• Local password

• Sessions

• Ownership

• Data

• License

OAuth-App Card

OAuth Application

What it is

An application authorized to access company services or data on the user's behalf.

Review

• Application

• Requested scopes

• Current access

• Business need

No monthly invoice is required for OAuth access to matter.

API-Token / PAT Card

API Token / Personal Access Token

Possible uses

• Automation

• Git operations

• Deployment

• Integration

• API access

Offboarding rule

Identify dependencies before revocation.

Preferred outcome

Replace personal credentials with properly owned service identities where appropriate.

SSH-Key Card

SSH Key

Potential locations

• Servers

• Git platforms

• Network appliances

• Cloud systems

Review

Which personal keys remain authorized?

Goal

Named identities, known ownership, managed lifecycle, auditability.

Shared-Credential Card

Shared Credential

Problem

You cannot revoke one person's access without changing the credential.

Possible examples

• Shared admin password

• Vendor portal

• Shared SaaS login

• Wi-Fi administration

Action

Evaluate controlled rotation.

Password-Manager Card

Password Manager

Review:

• User access

• Groups

• Shared vaults

• Emergency access

• Sensitive shared credentials

Removing vault access does not erase passwords already known.

Privileged-Access Card

Privileged Access

Review separately:

• Global admin

• Domain admin

• Cloud admin

• GitHub owner

• Network admin

• Security admin

• Billing admin

• SaaS super-admin

High privilege requires a more complete offboarding review—not an assumption of bad intent.

Cloud-Access Card

Cloud Infrastructure

Review:

• Human identities

• Roles

• Groups

• Access keys

• Service principals

• Service accounts

• API credentials

Do not disable legitimate production service identities simply because one former employee originally created them.

BYOD Card

Personal Devices / BYOD

Review according to policy:

• Email

• Managed apps

• Work profile

• Certificates

• VPN

• Cloud sync

• Organizational data

Do not assume the company can wipe an entire personal device.

Use approved selective controls where technically and legally appropriate.

Company-Device Card

Company Device

Review:

• Returned?

• Encryption

• MDM/UEM

• Security agent

• Local data

• Old user profile

• Reimage/wipe

• Asset assignment

• Reassignment/retirement

Email / Forwarding Card

Email

Review:

• Sign-in

• Sessions

• Delegates

• Forwarding

• Shared mailbox rights

• Send-as permissions

• Groups

• Connected applications

Preserve business records appropriately before permanent deletion.

File-Ownership Card

File Ownership

Review:

• OneDrive

• SharePoint

• Google Drive

• Dropbox

• Box

Ask:

Who owns important content now?

Who should own it next?

Are external sharing links still appropriate?

Git / Source-Code Card

Git and Source Code

Review:

• Organization membership

• Teams

• Repositories

• PATs

• SSH keys

• Deploy keys

• Package registries

• Local copies

Removing platform access does not erase previously downloaded local repositories.

CI/CD / Service-Account Card

CI/CD and Service Accounts

Risk

Automation may depend on a personal credential.

Review

• Pipeline

• Owner

• Token

• Service identity

• Permissions

• Rotation

• Dependency

Do not break production by blindly deleting credentials.

VPN / Remote-Access Card

Review:

• VPN

• Certificates

• Zero-trust access

• Remote desktop gateways

• Remote-support tools

• SSH

Disabling email does not necessarily remove network access.

Vendor / Partner-Portal Card

Review external portals such as:

• ISP

• Vendor support

• Shipping

• Insurance

• Software

• Hardware

• Payment services

These may exist outside SSO.

Domain / DNS Card

Review:

• Domain registrar

• DNS provider

• Hosting

• Certificates

• Organizational owner

• Administrators

• Recovery path

Company infrastructure should not depend on one person's personal account.

Customer-System-Access Card

Review:

• Customer tenant

• Customer VPN

• Partner portal

• Customer repository

• External help desk

Access supplied by another organization still needs offboarding.

MFA-Method Card

Review:

• Authenticator registrations

• Phone numbers

• Security keys

• Passkeys

• Recovery methods

Physical return and technical revocation are separate steps.

AI-Tool Card

Review:

• AI account

• Connected files

• Cloud storage

• API keys

• Integrations

• Company ownership

Verify provider-specific data behavior before making claims about retention or training.

Contractor-Offboarding Card

Apply lifecycle management to:

• Contractors

• Consultants

• Agencies

• Interns

• Temporary workers

• Vendor personnel

Contract expiration should trigger access review.

Planned-vs.-Immediate-Departure Cards

Planned Departure

Where timing permits:

• Transfer files

• Transfer knowledge

• Move customer relationships

• Identify SaaS

• Replace personal credentials

• Transfer administration

Immediate / Higher-Risk Departure

Coordinate access termination according to approved company policy among the appropriate HR, management, IT, security, and legal stakeholders.

There is no universal termination choreography.

Data-Ownership-Transfer Checklist

Review ownership of:

• Files

• Automations

• Dashboards

• Forms

• Reports

• Calendars

• Repositories

• Cloud resources

• Customer accounts

• Shared mailboxes

• Documentation

Shared-Secret-Rotation Card

Shared Secret Rotation

Examples

Password, API key, database credential, application secret.

Safe pattern

Identify → Replace → Update dependencies → Test → Retire old credential.

Do not rotate production secrets blindly.

Former-Administrator Checklist

Review:

• Primary identity

• Separate admin identity

• Identity provider roles

• Cloud

• Servers

• Network

• Endpoint management

• Security tools

• Backup

• Password vault

• Domains/DNS

• Source control

• CI/CD

• Tokens

• SSH keys

• Vendor portals

• Customer systems

Developer Checklist

Review:

• GitHub/GitLab/Bitbucket

• Teams

• Repositories

• PATs

• SSH keys

• Deploy keys

• CI/CD

• Package registries

• Cloud roles

• Infrastructure-as-code

• Secrets

• Developer SaaS

• Pipeline ownership

Sales / Finance / Marketing Role Cards

Sales

Review CRM, email, calling, sales tools, contact databases, customer files, and lead/account ownership.

Finance

Review accounting, expenses, financial reporting, payment/banking roles, and finance storage.

Marketing

Review CMS, social accounts, ads, analytics, email marketing, design tools, domain/DNS where applicable.

Windows / Mac Device-Offboarding Card

Recover

Company-owned device.

Preserve

Approved business data.

Remove

Old identity/access.

Verify

Encryption and management.

Reimage

According to policy.

Reassign or Retire

Update asset inventory.

Remote-Worker Checklist

Review:

• Laptop

• Phone/tablet

• VPN

• SaaS

• Synced files

• Security key

• Remote-support software

• Customer access

• Equipment return

• Device-management status

Before-Departure Checklist

Where timing permits:

• Identify identities

• Identify SaaS

• Identify admin access

• Identify devices

• Identify tokens and keys

• Identify customer/vendor systems

• Transfer files

• Transfer projects

• Transfer automations

• Transfer admin ownership

• Identify shared credentials

Separation-Time Checklist

According to approved timing:

• Disable primary identity

• Block new sign-in

• Revoke sessions where supported

• Remove VPN

• Remove SaaS access

• Remove privileged roles

• Remove cloud access

• Remove repository access

• Recover devices/keys

• Address external customer/vendor access

Post-Departure Verification Checklist

Verify:

• Identity disabled

• Sessions handled

• SaaS removed

• Tokens handled

• SSH keys handled

• Shared secrets reviewed

• Ownership transferred

• Email handled

• Files handled

• Devices updated

• Licenses reclaimed

• Customer/vendor access removed

• Documentation updated

Deprovisioning-Automation Flow

Authorized departure event

↓

Identity platform

↓

Provisioning / SCIM

↓

Supported applications

↓

Access removed

↓

Logs / failure alerts

↓

Manual exceptions

↓

Verification

SaaS / Inventory Connection Card

Good SaaS inventory answers:

• What applications exist?

• Who owns them?

• Who uses them?

• Are they connected to SSO?

• Is SCIM configured?

• Where is company data?

• How is access removed?

If the business already knows those answers, offboarding becomes much easier.

Healthy / Caution / High Risk Offboarding Cards

Healthy

• Central identity

• Named accounts

• SaaS inventory

• HR/IT coordination

• Session-revocation process

• Privileged-access review

• Device inventory

• Ownership transfer

• Contractor lifecycle

• Verification

• Documentation

Caution

• Many independent SaaS accounts

• Shared passwords

• Incomplete inventory

• IT learns about departures late

• No key/token inventory

• Manual offboarding from memory

• Former users occasionally discovered in applications

High Risk

• Former users remain administrators

• Organization cannot identify SaaS access

• Departed users remain in cloud systems

• Shared privileged credentials never change

• Company infrastructure is personally owned

• No offboarding checklist

• No verification

• Production automation depends on personal credentials

Illustrative only—not a formal security score.

Employee-Offboarding Decision Path

Is the primary identity disabled according to approved timing?

No → Address primary identity.

↓

Are active sessions handled?

No → Review platform-specific revocation.

↓

Are all applications centrally managed?

No → Review independent SaaS.

↓

Was the person privileged?

Yes → Perform privileged-access review.

↓

Did they create tokens, keys, or integrations?

Yes → Identify dependencies, replace where necessary, then revoke.

↓

Did they use managed devices?

Yes → Follow device lifecycle process.

↓

Was BYOD used?

Yes → Remove organizational access/data using approved controls.

↓

Did they own files or automations?

Yes → Transfer ownership.

↓

Did they know shared credentials?

Yes → Evaluate rotation.

↓

Has offboarding been verified?

No → Verify.

Former-Administrator Decision Path

Identity

↓

Privileged Roles

↓

Cloud

↓

Servers

↓

Network

↓

Password / Secrets Vault

↓

Git / CI/CD

↓

Domains / DNS

↓

Security Tools

↓

Tokens / Keys

↓

Verify

20-Step Secure Offboarding Process

1. Receive authorized departure event.

2. Confirm effective access-removal timing.

3. Identify primary identity.

4. Identify privileged/admin identities.

5. Identify assigned devices.

6. Identify known SaaS.

7. Identify cloud/repository access.

8. Identify tokens and keys.

9. Identify customer/vendor access.

10. Transfer business data.

11. Transfer resource ownership.

12. Disable primary identity.

13. Revoke active sessions where supported.

14. Remove downstream application access.

15. Remove privileged roles.

16. Recover or manage devices.

17. Rotate relevant shared credentials safely.

18. Reclaim licenses when appropriate.

19. Update documentation and inventory.

20. Verify access removal.

Organizations may need a different sequence depending on policy, platform behavior, and business/legal requirements.

Offboarding Discovery Checklist

Ask:

• Which identity provider do we use?

• Which apps use SSO?

• Which apps use local accounts?

• Which apps support SCIM?

• Who owns the SaaS inventory?

• Who tells IT about departures?

• What devices are assigned?

• Is BYOD allowed?

• Who has privileged access?

• Where are shared secrets managed?

• How are API tokens tracked?

• How are cloud roles assigned?

• How are customer systems tracked?

• How do we transfer files?

• How do we verify completion?

Privileged-User Checklist

Review:

• Identity platform

• Cloud

• Network

• Servers

• Endpoint management

• Security platforms

• Source control

• CI/CD

• DNS/domain

• Password/secrets vault

• Backup

• Monitoring

• Vendor portals

• Customer systems

• API credentials

• SSH keys

Contractor Checklist

Review:

• Contract end date

• Account

• Expiration

• SaaS

• VPN

• Shared files

• Customer systems

• Privileged access

• Device

• Project ownership

• Tokens/keys

• Vendor-provided users

Post-Offboarding Audit Checklist

After an appropriate period according to company process, verify:

• Identity

• SaaS

• Privileged roles

• Groups

• Cloud

• Git

• Tokens

• Devices

• Customer/vendor systems

• Shared credentials

• Ownership transfers

• Deprovisioning exceptions

Do not use a generic blog article to invent a universal audit interval.

Common Offboarding Mistakes

Disable Email and Stop

Email is one identity surface, not the whole access estate.

Delete the Account Before Transferring Data

Access removal and permanent deletion should be treated separately.

Forget Active Sessions

A user may already be authenticated.

Forget SaaS

Independent accounts can survive central identity disablement.

Forget OAuth Apps

Connected applications may still have approved access.

Forget API Tokens

Machine credentials can survive human login removal.

Forget SSH Keys

Review technical access separately.

Forget Shared Credentials

One password used by many people cannot revoke one person individually.

Forget Privileged Accounts

Admin identities may be separate.

Forget Cloud Roles

Review AWS/Azure/GCP access explicitly.

Forget BYOD

Personal devices may still have company data or sessions.

Forget Customer Systems

Third-party access counts too.

Forget Contractors

Access lifecycle is not just for payroll employees.

Break Production by Revoking a Token Blindly

Find the dependency before changing credentials.

Let HR and IT Work From Different Timelines

Access should reflect the approved effective departure time.

Assume SSO Solves Everything

It doesn't cover every local account, token, or session.

Assume SCIM Always Works

Provisioning failures and unsupported apps exist.

Never Verify Completion

Automation and checklists can fail.

Keep Every Old Account Forever

Define archive/deletion policy.

Treat Every Departure Like a Security Incident

Routine offboarding is lifecycle management.

Offboarding Warning Cards

“We Disabled Their Email”

Concern

Other access may remain.

Review

Identity, SaaS, sessions, cloud, devices, tokens.

“Everything Uses SSO”

Concern

Independent accounts, existing sessions, and programmatic credentials may still exist.

“They Returned Their Laptop”

Concern

Device possession is one part of access lifecycle.

“We Removed Them From GitHub”

Concern

Review PATs, SSH keys, CI/CD, cloud connections, package registries, and local copies.

“They Were a Good Employee, So We Can Leave Access for a While”

Concern

Access should follow current business need—not assumptions about character.

“They Were Fired, So Rotate Every Secret Immediately”

Concern

Uncontrolled rotation can break production.

Use the organization's approved risk-based process.

Frequently Asked Questions

1. Are former employees really a cybersecurity risk?

They can create residual access risk, but most former employees are not malicious. The practical concern is that accounts, sessions, tokens, files, devices, SaaS applications, or privileged access may remain usable after the legitimate business need ends.

2. What should IT disable when an employee leaves?

IT should review more than one account. Depending on the environment, that can include the primary identity, SaaS applications, remote access, privileged roles, cloud accounts, repositories, tokens, devices, email, file sharing, customer systems, vendor portals, and authentication methods.

3. Is disabling email enough?

No. Email may be connected to the primary identity, but employees often accumulate separate SaaS logins, VPN access, cloud roles, repository access, OAuth applications, API tokens, and other credentials that require separate lifecycle handling.

4. How quickly should former employee access be removed?

Access should be removed according to the organization's approved effective separation timing and risk. HR, management, IT, security, and legal considerations can affect the exact process. CISA's identity-governance guidance says access should be promptly terminated when users leave through retirement, termination, or contract expiration.

5. What is joiner-mover-leaver identity management?

Joiner-mover-leaver is an identity-lifecycle model. Join covers new access, Move covers role changes, and Leave covers removal of access when employment or a contract ends. It helps organizations manage permissions throughout a person's relationship with the company instead of only at termination.

6. What is secure employee offboarding?

Secure offboarding is the controlled removal, transfer, preservation, and verification of access and company assets when a worker leaves. It may include identity, SaaS, sessions, devices, files, cloud roles, repositories, credentials, customer systems, and resource ownership.

7. Should active Microsoft 365 sessions be revoked?

They should be reviewed as part of offboarding. Microsoft's current Entra guidance distinguishes disabling the user from revoking refresh tokens and explains that some application-issued session cookies have their own lifecycle. Follow the current Microsoft process appropriate to the environment.

8. What happens to Google Workspace access when an employee leaves?

Administrators can suspend access without immediately deleting the account. Google states that suspended users lose access to Workspace services while organizational data remains available for administrative handling. Data ownership can be transferred before permanent deletion.

9. Does SSO automatically remove all SaaS access?

No. SSO can greatly simplify access removal, but some applications may use local accounts, independent tokens, existing sessions, or unsupported provisioning methods.

10. What is SCIM and how does it help offboarding?

SCIM is a standard commonly used to automate user provisioning and deprovisioning between identity platforms and SaaS applications. It can reduce manual work, but the application must support it and deprovisioning must be configured correctly.

11. What happens to SaaS accounts after an employee leaves?

They should be discovered, reviewed, and deprovisioned according to the application's supported process. Independently created SaaS accounts are a common offboarding blind spot, especially when they were purchased by a department or used free of charge.

12. What are OAuth-connected applications?

They are applications that a user has authorized to access selected data or services through OAuth. Google Workspace, for example, lets administrators review accessed third-party applications and their requested scopes.

13. What should happen to API tokens?

Identify their purpose before revoking them. Some tokens belong solely to the former employee; others may power production automation. Replace dependencies safely, verify the new credential, and then revoke obsolete access.

14. What should happen to SSH keys?

Review where the user's SSH keys remain authorized and remove access no longer required. Servers, source-control systems, cloud platforms, and network equipment may all use SSH keys independently.

15. Should shared passwords be changed when someone leaves?

Sometimes. If the person knew a sensitive shared credential and continued knowledge creates material risk, controlled rotation may be appropriate. Identify dependent applications first so the change does not break production.

16. What should happen to administrator accounts?

Privileged accounts deserve an additional review. Remove or transfer administrative roles, review separate administrator identities, tokens, cloud permissions, security tools, networking, repositories, DNS, and other elevated access.

17. What should happen to GitHub access?

Remove organization and repository access according to the company's GitHub architecture and review programmatic credentials separately. GitHub notes that removed members may retain local repository copies even after access to private organization repositories is removed.

18. What should happen to company files?

Transfer or preserve important business files before permanent account deletion when required. Review ownership, shared links, customer access, retention, and the authoritative business location for those files.

19. What should happen to a former employee's mailbox?

Remove the former employee's access but handle business data deliberately. Depending on platform, policy, and legal requirements, the company may use retention, delegation, migration, a shared mailbox, an automatic reply, or another supported process.

20. What should happen to company laptops and phones?

Recover and process them through the organization's device-lifecycle procedure. Review encryption, management, local data, user assignment, security agents, reimage/wipe status, inventory, and whether the device will be reassigned or retired.

21. What if the employee used a personal device for work?

Follow the company's BYOD policy and approved management architecture. Remove organizational accounts, managed applications, certificates, VPN access, and company data where technically and legally appropriate. Do not assume the company should erase the entire personal device.

22. How should contractors be offboarded?

Use the same identity-lifecycle discipline applied to employees, adjusted for their actual access. Track contract expiration, accounts, SaaS, remote access, customer systems, devices, files, privileged permissions, and project ownership.

23. Should an old user account be deleted or disabled?

It depends on platform behavior and business requirements. Immediate access removal may call for disablement or suspension, while permanent deletion may need to wait for data transfer, retention, ownership, or legal review.

24. How do you verify former employee access has actually been removed?

Use administrative and provisioning evidence rather than attempting unauthorized login. Review identity status, app assignments, deprovisioning logs, cloud roles, repository membership, tokens, device status, and other relevant systems.

25. Can SimplyRem help create or improve an employee offboarding process?

Yes. SimplyRem's current Security practice includes identity and access management, Okta, Entra ID, JumpCloud, SSO, MFA, Conditional Access, least privilege, joiner-mover-leaver automation, privileged access management, zero-trust architecture, endpoint/cloud security, security monitoring, and incident response.

Final SimplyRem CTA

Most former employees are not cybersecurity threats.

Forgotten access is.

Not sure whether your offboarding process actually removes access from Microsoft 365, Google Workspace, SaaS applications, cloud platforms, company devices, repositories, VPNs, and privileged accounts?

SimplyRem can review identity, SaaS, privileged access, endpoint management, cloud platforms, shared credentials, and lifecycle processes and help build a more consistent joiner-mover-leaver approach for employees and contractors. Its current Security practice publishes capabilities across Okta, Entra ID, JumpCloud, SSO, MFA, Conditional Access, least privilege, joiner-mover-leaver automation, privileged access management, zero trust, endpoint security, monitoring, and incident response.

The goal isn't to treat every departure like a breach.

It's to confidently answer a simple question:

When this person no longer needs access, where do we remove it—and how do we verify that it's actually gone?