What do organisations get wrong about onboarding and offboarding cloud access?

A common mistake is focusing on initial access while neglecting what happens when roles change or people leave. If permissions are not reviewed and revoked promptly, former employees or contractors can retain SaaS access longer than intended. That creates unnecessary exposure, especially when access spans multiple cloud services and is not centrally tracked.

What organisations miss in the cloud access lifecycle

The core mistake is treating onboarding as the whole problem. Cloud access is a lifecycle issue: access is granted, used, changed, reviewed, and eventually removed. When organisations only design for the first step, they miss the points where SaaS and cloud permissions drift, linger, or become harder to trace across environments.

That gap matters because cloud access is often spread across multiple platforms, each with its own admin model, audit trail, and revocation path. A user can leave one business function but still retain access through inherited roles, direct grants, or a second SaaS tenant that never gets reconciled with HR or IT records.

As a result, onboarding controls can look mature while offboarding remains informal, delayed, or manual. The strongest control pattern is to treat provisioning and deprovisioning as one process, with ownership, review checkpoints, and a clear source of truth for who still has access.

For lifecycle depth, NHI Lifecycle Management Guide and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs explain how provisioning, recertification, and removal fit together rather than standing alone.

Where access revocation breaks down in practice

Most failures are operational, not conceptual. Access is granted through one system, but removal depends on another team, another ticket, or another review cycle, so the revocation step gets delayed until someone notices the account is still active.

That delay becomes more dangerous when access is not centrally visible. If organisations cannot enumerate all cloud services, app tokens, and delegated permissions tied to a user or contractor, they cannot reliably prove that offboarding is complete. In those environments, stale access is not an edge case, it is the default failure mode.

Another common error is assuming that role changes automatically solve departure risk. They do not. A transfer may remove one entitlement set while leaving direct SaaS grants, shared admin paths, or long-lived credentials untouched. The result is partial cleanup that looks like control, but still leaves reachable access behind.

Recent NHIMG research shows the scale of the issue, with The 2025 State of NHIs and Secrets in Cybersecurity reporting that 91% of former employee tokens remain active after offboarding. That figure is a useful reminder that offboarding failure is usually about persistence, not intent.

Risk and Threat Considerations

Stale cloud access creates an avoidable exposure window after employment ends or responsibilities change. The risk is not limited to a missed account disablement, because a retained SaaS grant, token, or delegated permission can still be used to read data, alter records, or pivot into connected services.

Failure mechanism: Offboarding breaks when access is distributed across clouds and SaaS tools without a complete inventory, so revocation depends on manual recall, separate teams, or incomplete system joins.

Impact: Former staff or contractors can keep access longer than intended, increasing the chance of unauthorized data exposure, account misuse, and harder-to-detect insider or post-departure abuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack surface, CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Lifecycle and Offboarding	Cloud access offboarding is a lifecycle problem with stale credentials and permissions.
	NHI-03 — Secrets and Credential Management	Lingering tokens and long-lived credentials are central to offboarding exposure.
Recommendation — Enforce timely revocation and lifecycle cleanup for every cloud access path. Rotate or revoke any credential that can survive a user departure.
CIS Controls v8	6 — Access Control Management	Least privilege and account revocation directly address stale cloud access.
	5 — Account Management	Cloud onboarding and offboarding depend on complete account lifecycle governance.
Recommendation — Review and remove access promptly when roles change or people leave. Maintain an authoritative account inventory and disable unused access quickly.
NIST Zero Trust (SP 800-207)	4 — Policy Enforcement Points	Cloud access should be continuously enforced, not assumed from initial onboarding.
Recommendation — Enforce access decisions at each cloud policy checkpoint.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Offboarding failures are access-control failures across cloud systems.
	GV.PO — Policy	Lifecycle ownership and offboarding rules need explicit policy to stay consistent.
Recommendation — Tie identity changes to immediate access removal across connected services. Define who owns access removal and when it must happen.
ISO/IEC 42001:2023	4.2 — Understanding the needs and expectations of interested parties	Cloud access governance needs clear accountability across business and IT stakeholders.
Recommendation — Assign clear accountability for access lifecycle decisions and exceptions.

Practitioner Guidance

What to prioritise: Start with the accounts and tokens that can reach production, customer data, or administrative consoles. Those are the paths where delayed revocation creates the highest blast radius, so they should be verified first during any offboarding event.

What to verify: Do not trust a completed HR event alone. Verify that each cloud and SaaS system has a documented removal path, that the user no longer has direct grants, and that any shared or inherited access has been re-evaluated rather than assumed to disappear automatically.

Practitioner takeaway: Organisations get this wrong when they measure onboarding completion but not offboarding completeness; the real control is whether access can be removed quickly, consistently, and across every cloud service the person touched.