Why Offboarding Is One of the Biggest Security Risks in Growing Companies

Quick answer

When someone leaves your company, every account they had access to should be revoked within 24 hours. Not "when IT gets to it." Not "when HR sends the email." 24 hours.

Most growing companies take weeks — and many never fully revoke at all. The result is a silent accumulation of orphaned accounts, forgotten access tokens, and former employees with live credentials to systems they shouldn't touch.

Offboarding is treated as an HR process. It is a security control. Until it's owned and operated as one, it's one of the easiest paths to a breach in your environment.

Why offboarding is a security problem, not an HR problem

The common pattern in growing companies: HR runs the leaving conversation, schedules the exit interview, processes the final payroll, and sends a one-line email to IT — usually after the person has already left. IT then deactivates the email account, sometimes that day, sometimes a few days later. That's "offboarding done."

Except it isn't.

A modern employee has access to far more than email. SSO-connected SaaS applications. Internal tools without SSO. Shared admin accounts. Personal API tokens generated for one-off integrations. MDM-managed devices. Code repositories. Customer support consoles. Cloud provider accounts. Payment processor access. The list is longer than HR knows about.

When the offboarding email arrives saying "please remove access for [name]", IT often does not have a definitive list of every place that person had access. Nobody does. The result is partial revocation by default.

What actually fails

The failure modes are consistent across the companies we assess:

Personal access tokens. Engineers generate API tokens for integrations, scripts, and one-off automations. These tokens are tied to their identity but live outside the SSO perimeter. When the person leaves, the email is deactivated, but the tokens keep working until they expire — sometimes months later, sometimes never.

SaaS tools outside SSO. Every growing company has a long tail of subscriptions that someone signed up for with a company email, sometimes with a corporate card. Notion, Figma, Loom, ChatGPT, the dozen analytics tools the marketing team uses. SSO catches the major ones. The tail doesn't get touched.

Shared admin accounts. A former employee knows the password to the "company" account for a tool that wasn't connected to SSO. The password should change when they leave. It rarely does.

Email forwarding rules. Sophisticated insider risk: before leaving, an employee sets up a forwarding rule sending copies of incoming email to a personal address. Deactivating the account doesn't always remove the forwarding rule.

Devices that never come back. Laptops "returned" to a drawer in the office, never wiped, eventually re-issued to a new hire with old data still on them. Or contractor devices that were never company property and walk out with company data on them.

The contractor case. Contractors get added with the urgency of "we need this now." They almost never get offboarded with the same urgency. Contractor accounts from 18 months ago are some of the most common findings we surface in initial assessments.

The 24-hour rule

A defensible offboarding standard is simple: every account, device, token, and access path is revoked within 24 hours of the person's last working day.

Some elements (like email forwarding) should be checked on the day. Some (like the long tail of SaaS subscriptions) need a documented review process. The principle is the same: the company knows what someone had access to, and there is a defined process for closing all of it.

If you cannot answer the question "what would happen if the person who left last month wanted to log in tomorrow?" with confidence, your offboarding is not working.

Why offboarding is hard

Offboarding is hard because it sits across functions and nobody owns the whole thing.

HR owns the relationship and the timing.

IT owns the account deactivation, but only for accounts IT knows about.

The team manager often has the best knowledge of which tools the person actually used, but is rarely involved in the technical revocation.

Security might own the policy, but doesn't usually run the operation.

Without a single owner and a documented process, offboarding falls back to whoever happens to remember.

What good looks like

A working offboarding process has three components.

Identity-driven revocation. Every business application connected to SSO. When the SSO account is disabled, access to those applications ends automatically. The wider your SSO footprint, the cleaner your offboarding.

A documented checklist for the long tail. Tools outside SSO are listed somewhere. When someone leaves, the checklist is worked through systematically. Shared accounts have their passwords changed. Personal API tokens are revoked. Forwarding rules are checked.

An owner and a timeline. One named person is responsible for offboarding being complete. There is a defined deadline (24 hours is the standard). There is evidence that it happened — a closing record, not just a Slack message.

When this works, offboarding becomes a five-minute confirmation instead of a recurring source of risk. It is one of the six components of a good IT setup at this stage.

The compliance angle

Every security framework that matters requires offboarding to be a documented, evidenced process.

ISO 27001 Annex A includes specific controls on the termination of access. SOC 2 reviews offboarding as part of the access control criteria. NIS2 expects organisations under its scope to have working processes for managing the lifecycle of access. PCI DSS requires immediate revocation of access for terminated personnel.

The phrase that comes up in every audit conversation: "show me the evidence that this person's access was fully revoked when they left."

If the answer is "I'll have to check," the auditor has already made a note.

The contractor problem is worse

Contractor offboarding is where most companies fail hardest.

Contractors get added with a sense of urgency. They are often given broad access "to get started quickly." Their engagement ends informally — sometimes just a final invoice paid. Nobody runs a leaving process because nobody owned the joining process either.

Months later, in an access review, an account belonging to "the contractor who helped with the migration last year" is still active, still has admin rights to something, and nobody knows who that contractor was reporting to.

Contractor accounts should be created with a defined end date wherever possible. They should be flagged in every quarterly access review. Their offboarding should be more rigorous than employee offboarding, not less — because the relationship was more loosely defined to begin with.

Common mistakes

• Treating offboarding as HR's responsibility. HR knows when. They don't know where access lives.
• Relying on a single offboarding email to IT. Without a documented process, partial revocation is the default outcome.
• Assuming SSO covers everything. It doesn't. The long tail is where the risk hides.
• Skipping the laptop wipe because "we trust them." Trust is not a security control.
• Never auditing past offboardings. Quarterly access reviews are the only way to catch what slipped through.

FAQ

How long should offboarding take? Critical access (email, SSO, devices) should be revoked within 24 hours of the last working day. Long-tail SaaS tools should be fully closed within 7 days. Evidence of complete revocation should exist within 30 days.

Should we offboard before or after the leaving conversation? Critical access should be revoked at the moment the leaving conversation ends — not after the person has packed up their desk. This is especially important for security-sensitive roles.

What about people who are leaving on good terms? Same rules. The risk is not the person's intent. The risk is what could happen to the account if it stays open: phishing, credential stuffing, account takeover.

How do we handle a contractor who might come back? Disable, don't delete. The account history is useful evidence. Re-enable when they return — under a new engagement, not the old one.

What evidence do we need to keep? A record showing the date access was revoked, who confirmed it, and which systems were checked. Most companies underestimate this until their first audit asks for it.

The bottom line

Bad offboarding is one of the easiest things to fix and one of the most consistently overlooked. The work is not exotic: a defined owner, a documented checklist, an SSO-first architecture, and a 24-hour standard.

The result is dramatic. The privileged surface drops. Audit findings disappear. The forgotten account that would eventually have been exploited gets closed before anyone notices it was open.

Most companies will tighten their offboarding only after a breach traces back to a former employee. The companies that take this seriously do it before.

Pick which kind you want to be.

"Trust is not a security control. The risk is not the person's intent — it's what could happen to the account if it stays open."