What do teams get wrong about offboarding when they rely on spreadsheets and email chains?

Why This Matters for Security Teams

offboarding looks simple on paper, but spreadsheets and email chains hide the exact failure mode that attackers exploit: no single system of record, no enforced sequence, and no dependable proof that every access path was removed. When the process is split across HR, IT, security, and application owners, one missed reply can leave accounts alive long after a departure is supposed to be complete.

That matters because identity sprawl is now normal across SaaS, cloud consoles, and third-party apps, and the delay between “employee left” and “access removed” is enough for abuse. NHI Management Group’s 2025 State of NHIs and Secrets in Cybersecurity report, attributed to Entro Security, found that 91% of former employee tokens remain active after offboarding, which shows how easily cleanup breaks when it depends on manual coordination. Current guidance from the NIST Cybersecurity Framework 2.0 also points toward repeatable, accountable access management rather than informal handoffs.

In practice, many security teams discover the gap only after a former user is still able to reach a sensitive app, rather than through a clean and verifiable offboarding review.

How It Works in Practice

Reliable offboarding starts with an authoritative trigger, usually from HR or a workforce identity source, and then moves through a controlled sequence: disable interactive login, revoke active sessions, remove group memberships, rotate shared credentials where needed, and confirm that privileged and third-party access has been closed. A spreadsheet can track tasks, but it cannot enforce order, validate completion, or prove that every dependent system has been reached.

The better pattern is to treat offboarding as an identity workflow with checkpoints. Each control should answer a specific question: has the account been disabled, have tokens been revoked, have SSH keys and API keys been rotated, has SSO been disconnected, and have delegated roles been removed? For environments with many SaaS tools, automation is not optional in practice because manual cleanup does not scale and is too easy to skip when the person leaving used several identities or shared credentials.

• Use one authoritative trigger for termination or contractor end dates.
• Disable the primary identity first, then revoke sessions and tokens.
• Rotate any shared secrets the person could have known or used.
• Require evidence of completion for each application owner.
• Review privileged access separately from standard user access.

This is why the NHI Lifecycle Management Guide is useful here: lifecycle control is only real when provisioning and deprovisioning are both governed, and the same principle applies to human accounts that leave behind tied access, tokens, or delegated trust. Teams that need a broader view should also compare the failure patterns in the Top 10 NHI Issues, because the same manual handoff problems often appear in secrets cleanup and privileged service accounts. These controls tend to break down when ownership is split across many business units because no single team can prove the full dependency chain.

Common Variations and Edge Cases

Tighter offboarding often increases coordination overhead, requiring organisations to balance speed against completeness. That tradeoff becomes sharper when the departed person had admin rights, used personal API tokens, or worked across contractors, subsidiaries, and external partners.

There is no universal standard for every edge case, but current guidance suggests treating high-risk departures differently from routine exits. Executive accounts, developers with deploy rights, and users with federated SaaS access usually need manual verification even if the bulk of the process is automated. Shared mailboxes, group-owned secrets, and service credentials are also common blind spots because no single person feels accountable for them after the exit.

One practical rule is to separate “employment ended” from “access fully removed.” That distinction matters when a user is deleted in one directory but still exists in downstream SaaS, when email forwarding remains active, or when a token was copied into a ticket and never rotated. It is also where spreadsheet-led processes fail most often: they record the request, but they do not force downstream confirmation. Teams that handle contractors and short-term staff should be especially careful, because these accounts often bypass the same controls as permanent employees and are least likely to be reviewed after the fact.

Security teams that want a stronger baseline should use offboarding evidence as part of access review, not as an end-of-process checkbox, and should assume that manual closure is incomplete until every dependent system has been checked.

Related resources from NHI Mgmt Group

• What do security teams get wrong about workforce risk programmes that rely on spreadsheets and annual training?
• What do security teams get wrong about AI oversight when they rely only on policy documents?
• What do security teams get wrong about dependency security when they rely on package popularity or maintainer reputation?
• What do teams get wrong about mobile API security when they rely only on static analysis?