Teams often assume manual coordination is reliable enough for routine identity changes, but it breaks down as volume grows. Common mistakes include updating one platform but not the other, staging actions for later, and missing role changes or departures. Those gaps slow access provisioning and revocation, create inconsistent records, and increase the chance that former users retain access longer than intended.
Where manual coordination breaks down in onboarding and offboarding
Manual HR and IT handoffs fail because they depend on people spotting every status change and executing each step in the right order. That works poorly when there are multiple systems, delayed approvals, and time pressure. The result is usually not a single dramatic failure, but a stream of partial updates: one account closed, another left open, a role changed in HR but not in access control, or a leaver still active in downstream tools.
In practice, the main issue is consistency. onboarding and offboarding are identity lifecycle events, so they need the same source of truth and the same timing discipline across systems. When teams rely on spreadsheets, email threads, or ad hoc tickets, they create gaps between authoritative HR data and live access state, which is exactly where stale access and orphaned accounts tend to appear.
Manual processes also struggle with exceptions. Contractors, movers, temporary assignments, rehires, and urgent departures often break the “standard case” assumption. The more the process depends on tribal knowledge, the more likely it is that someone forgets to remove old-role access, delays revocation until “later,” or assumes another team already handled the change. A Joiner-Mover-Leaver (JML) Guide helps show why these edge cases are part of the core process, not exceptions to ignore.
Why identity drift and delayed revocation create real exposure
The biggest failure mode is identity drift, where HR records, directory data, application entitlements, and actual access rights slowly diverge. A user can leave a team, move roles, or exit the company while old permissions remain active in one or more systems. That drift increases the chance of excessive privilege, stale access, and inconsistent audit records, especially when the process is done by hand across many platforms.
offboarding is particularly sensitive because access revocation has to be complete, timely, and traceable. If a departure is staged for later, or if one system is updated without the others, former users can retain access longer than intended. In a mature process, revocation should cover accounts, entitlements, tokens, and any related access paths that still authenticate the former user. The Workforce Identity Security Guide is useful here because it ties offboarding to the broader problem of account recovery, session risk, and identity lifecycle control.
Onboarding has the mirror-image problem. If access is granted before the person is properly owned, provisioned, and approved, teams can create overbroad birthright access or temporary exceptions that never get cleaned up. Manual workflows also make it easy to update HR while forgetting to grant the right system access, which slows productivity and encourages shadow workarounds.
What good onboarding and offboarding should look like instead
Good practice is to treat HR as an authoritative trigger, not a separate administrative queue. The access outcome should be tied to a defined lifecycle event, with a clear owner for provisioning, mover changes, and leaver revocation. That usually means automating the routine path and reserving manual review for true exceptions, such as sensitive roles, unusual access, or urgent termination cases.
Teams should also standardise what “done” means. For onboarding, that means the person has the minimum access needed for the role, no more. For offboarding, it means the account is disabled or removed, shared access is handled, and any lingering credentials or sessions are accounted for. The IAM and IGA Basics guide is a helpful reference for the underlying provisioning, access review, and governance model that makes this measurable rather than informal.
For teams managing high volumes, the key operational question is whether the process can scale without relying on memory, spreadsheets, or delayed callbacks. If the answer is no, the process will eventually fall behind the business. The practical fix is to design for consistency first, then speed, because an access process that is fast but incomplete is usually worse than one that is slightly slower but reliable.
Risk and Threat Considerations
Manual onboarding and offboarding create a window where access can outlive employment status, role changes, or business need. That is not just an administrative defect, it is an exposure path that can preserve privilege after the organisation believes it has removed it. In higher-turnover environments, the same gap can accumulate across many accounts and systems, creating broad stale-access risk.
Failure mechanism: Human handoffs depend on perfect execution across multiple teams, so any missed update, delayed ticket, or partial system change can leave active access behind after the lifecycle event has already occurred.
Impact: Former users may retain access, audit records become unreliable, and revocation work becomes reactive instead of controlled. In the worst case, a departed user or an attacker abusing an old account can still reach systems that should have been closed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers credential lifecycle control during onboarding and offboarding. |
| AC-2 — Account Management | Directly addresses provisioning, modification, disabling, and removal of user accounts. | |
| AC-6 — Least Privilege | Manual coordination often leaves users with excessive or lingering access. | |
| Recommendation — Automate credential issuance, rotation, and revocation when employment status changes. Tie account creation, role change, and deprovisioning to authoritative HR events. Review role-based entitlements so only current job access remains active. | ||
| CIS Controls v8 | CIS-5 — Account Management | Prescribes disciplined account lifecycle handling, including removal of inactive access. |
| Recommendation — Centralise account lifecycle actions and disable access promptly at offboarding. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions Management | Maps to controlling permissions as people join, move, or leave. |
| Recommendation — Manage permission changes through a controlled lifecycle rather than manual follow-up. | ||
Practitioner Guidance
What to prioritise: Focus first on leaver revocation and mover access changes, because those are the cases where stale privilege is most likely to become material. Onboarding failures usually hurt productivity, but offboarding failures can preserve access that should already be gone.
What to verify: Teams should be able to prove that HR status changes trigger a complete access update across the systems that matter, not just the directory or the ticketing queue. If you cannot show who owns the lifecycle step, where the authoritative record lives, and how revocation is confirmed, the process is not trustworthy.
Common mistake: Treating manual coordination as acceptable because “the number of cases is small.” That assumption often fails as soon as hiring spikes, reorganisations, or terminations increase the pace of change.
Practitioner takeaway: The goal is not to make every identity change fully hands-on, it is to make the routine path deterministic and auditable, so exceptions are the only things that need human judgment.
Related resources from NHI Mgmt Group
- What do teams get wrong when they rely on manual DNS recovery?
- What do teams get wrong when they rely on manual review alone?
- What do security teams get wrong when they rely on manual privilege reviews at enterprise scale?
- What do teams get wrong when they rely on manual vulnerability management in DevSecOps?