What breaks when offboarding only covers the primary sign-in path?

When offboarding stops at the primary sign-in path, where does access stay alive?

The break is not usually at the login screen. It is in every downstream system that still trusts an application-specific account, API key, token, certificate, or local entitlement after the central directory account is disabled. Offboarding only works when the leaver’s access is removed from each authorization point, not just the front door.

That is why this question is really about access topology, not just account deletion. A user can be fully removed from SSO and still retain entry through SaaS admin consoles, embedded credentials, delegated app roles, or direct system-to-system access that was provisioned outside the primary identity path.

In practice, the central directory often acts as one control plane among several. When teams assume it is the only control plane, they miss the applications that authenticate independently, cache sessions, or maintain long-lived grants. IAM and IGA Basics is useful here because the failure is rarely about authentication alone, it is about whether every entitlement and access path is governed through the same lifecycle.

Which access paths are most likely to be missed?

The most common blind spots are anything that was created outside the main joiner-mover-leaver flow. That includes direct vendor logins, app-local usernames, service or shared accounts, privileged break-glass access, and machine or automation credentials that were never tied back to the human user in the first place.

Secondary sign-in paths also include federation exceptions and delegated admin roles. If a SaaS platform, support tool, or internal application can still authorize a user after directory deprovisioning, the offboarding process has only removed one reference to the person, not the person’s actual ability to act.

This is why lifecycle governance matters as much as authentication. The Joiner-Mover-Leaver (JML) Guide maps the operational gap well: deprovisioning has to revoke stale roles, tokens, and keys, not just disable the primary login. For a lifecycle view of the problem, the NHI Lifecycle Management Guide shows why inventory and offboarding are inseparable.

Where the estate includes machine or application credentials, the issue becomes broader than a user exit. Tokens, keys, certificates, and service accounts can survive long after the employee leaves, and they can continue to authorize actions without any interactive login. The Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs is relevant because those credentials need their own offboarding path.

What fails operationally when the directory is treated as the whole answer?

The immediate failure is residual access, but the deeper failure is incomplete visibility. Teams may close the human account, mark the ticket complete, and never verify whether downstream authorization was revoked. That leaves a mismatch between the record of offboarding and the actual ability to access data, administer systems, or invoke APIs.

At scale, this creates entitlement drift. The more SaaS tools, integrations, and local application stores exist, the more likely it is that one or more permissions survive because they were granted manually, inherited indirectly, or owned by a team other than the directory administrators. The Workforce Identity Security Guide is helpful for understanding why federation and account recovery paths must be included in offboarding, not assumed to be covered automatically.

The same pattern appears in privileged environments and shared tooling. If a leaver ever had admin rights, API access, or ownership of automation assets, deprovisioning the primary account does not remove the trust already embedded elsewhere. That is where clean lifecycle ownership matters, because the break is often not a technical error, it is an incomplete operating model.

Risk and Threat Considerations

Residual access after offboarding creates a straightforward security exposure: a former user can still reach systems, data, or administrative functions even after the company believes access has ended. The risk grows when downstream applications authorize independently, because the stale path can persist unnoticed and may be reused by the former employee or abused by an attacker who obtains the orphaned credentials.

Failure mechanism: The offboarding process removes the primary directory account but does not revoke application-local accounts, tokens, API keys, certificates, delegated roles, or shared credentials that still authenticate elsewhere.

Impact: Unauthorized access can continue after employment ends, which raises the likelihood of data exposure, privilege abuse, account takeover, and delayed detection of a control failure.

Practitioner Guidance

What to verify: Treat offboarding as complete only when you can evidence that each high-risk application, integration, and privileged path has been checked or centrally removed. If a platform has its own user store, admin console, token model, or service account model, verify that the leaver is gone there too.

Decision rule: If the application can authorize independently of the directory, do not rely on directory disablement as the final step. Revoke local entitlements, reset or rotate exposed credentials, and confirm that any delegated or shared access has been re-owned or removed.

Practitioner takeaway: The real test of offboarding is whether the person can still do anything, not whether the main login has been disabled.

Related resources from NHI Mgmt Group

• What breaks when organisations assume MFA covers every Office 365 sign-in path?
• What breaks when offboarding is only checked in the primary directory?
• What breaks when offboarding only disables the primary account?
• What breaks when brute force protections do not cover every sign-in path?