TL;DR
- Onboarding and offboarding are identity lifecycle processes, not isolated Service Desk tasks.
- Manual exceptions compound through hires, transfers, leaves, contractors, and departures.
- The mover stage is often riskier than the joiner or leaver stage because old access quietly persists.
- Mature firms assign ownership, define role baselines, and verify outcomes.
Every employee transition either reduces technology debt or adds to it.
“We have an onboarding checklist” sounds complete. The harder question is whether the checklist reflects how the person will actually work, who approves access, what changes when the role changes, and how the organization proves access was removed later.
Onboarding and offboarding are often treated as two administrative events. The real system includes joiners, movers, leavers, contractors, leaves of absence, acquisitions, and changes in authority. If those transitions rely on email threads and memory, growth converts them into technology debt.
What is employee-lifecycle technology debt?
Employee-lifecycle technology debt is the accumulated cost and risk created by inconsistent decisions about accounts, devices, applications, permissions, and ownership during workforce changes.
It shows up in small ways first: a missing license, a laptop that arrives late, an old group membership, or a shared mailbox nobody owns. Over time, those gaps become a second access model running alongside the official one.
The debt usually includes:
- Access copied from a colleague rather than assigned from a role.
- Applications discovered after the employee starts.
- Permissions added during transfers but never removed.
- Shared credentials used to avoid redesigning a workflow.
- Departed users retained because an integration might depend on them.
- Devices returned without verified data handling or reassignment.
Why is the “mover” stage usually overlooked?
Most firms have a starting process and an ending process. Fewer have a change process.
Promotions, transfers, temporary assignments, and reorganizations alter what people should see and what they should approve. Yet the operational habit is additive: grant the new access and leave the old access in place until someone complains.
That creates three problems:
- Access no longer reflects current responsibility.
- Separation of duties weakens quietly.
- Managers cannot explain why a person retains a permission.
Microsoft frames identity lifecycle management across joiner, mover, and leaver phases. Its lifecycle workflow capabilities can use employee attributes and dates to trigger tasks, preserve audit history, and automate defined actions. The important word is defined. Technology cannot resolve disagreement about who owns the process or what a role should receive.
Where do manual processes fail as headcount grows?
Volume is not the only problem. Variation is.
A firm can process 10 identical hires more reliably than three unusual ones. Growth adds offices, employment types, project teams, acquired systems, and exceptions. A generic checklist becomes longer, yet still misses the decisions that matter.
| Lifecycle stage | Immature pattern | Mature operating pattern |
|---|---|---|
| Joiner | Copy another employee | Assign a documented role baseline |
| Mover | Add new access only | Reconcile old and new responsibility |
| Leaver | Disable the primary account | Remove access across the full application map |
| Contractor | Create an ordinary user | Time-bound access with a named sponsor |
| Leave | Decide case by case | Apply a defined status and return process |
| Acquisition | Preserve everything indefinitely | Inventory, map, and rationalize access |
The difference is not bureaucracy. It is repeatability. Mature processes still allow exceptions, but exceptions have owners, reasons, and expiration dates.
Who should own onboarding and offboarding?
No single department owns the whole outcome.
Human resources knows employment status and timing. The manager knows the role. Operations knows the workflow. Technology teams know how access is implemented. Finance may own licenses and approval authority. Security defines control requirements.
The process needs one accountable coordinator even though several functions contribute.
A practical responsibility model assigns:
- HR: authoritative employment status and effective dates.
- Hiring manager: role, location, applications, and exceptions.
- Application owner: approval for sensitive or specialized access.
- Technology operator: account, device, license, and control execution.
- Security or compliance owner: policy requirements and review criteria.
- Process owner: completion, escalation, evidence, and improvement.
The Service Desk can execute the checklist. It should not have to invent the employee’s role, authority, or business requirements.
How do you reduce lifecycle debt without rebuilding everything?
The practical sequence is:
- Inventory the current process. Trace the last three hires, changes, and departures. Record actual steps, not intended policy.
- Define a small set of role baselines. Start with the highest-volume roles and locations.
- Identify authoritative data. Decide which system owns employment status, manager, department, location, and dates.
- Separate standard access from exceptions. Standard access should be predictable. Exceptions should require a reason, owner, and end date.
- Build verification into completion. Confirm the person can work on day one and confirm access is gone when it should be.
- Automate stable steps. Use workflow tooling only after approvals, data, and failure handling are clear.
- Review the process quarterly. New applications and organizational changes will otherwise make the checklist stale.
NIST Cybersecurity Framework 2.0 places stronger emphasis on governance and organizational context. Employee lifecycle work belongs in that governance conversation because it connects policy, responsibility, access, and evidence.
What most firms get wrong
- Starting with automation. Automated confusion produces faster inconsistency.
- Using job titles as complete role definitions. Two people with the same title may have different approval authority or project access.
- Ignoring non-Microsoft applications. Disabling one identity does not guarantee access is removed everywhere.
- Treating device return as offboarding completion. Accounts, tokens, shared data, and delegated permissions may remain.
- Allowing indefinite exceptions. Temporary access needs an expiration mechanism.
- Closing the ticket without validating the outcome. Completion should reflect usable access or confirmed removal, not merely task execution.
Map Your Operational Gaps →
Review the employee lifecycle as one operating system, from employment data through application access and recovery. Practical recommendations. No sales script.
Schedule a Technology Alignment Discussion
About the author
Sebastian Abbinanti is President of The Isidore Group. He advises growth-stage organizations on technology governance, Microsoft 365, cybersecurity, and operational maturity.
Frequently Asked Questions
What is joiner-mover-leaver identity management?
Joiner-mover-leaver identity management is a lifecycle model for granting, changing, and removing access as a person enters an organization, changes roles, or leaves. A mature model connects authoritative employment data, manager approvals, role standards, technical execution, and verification.
Why are role changes a security and operations risk?
Role changes often add new permissions without reconciling old ones. Over time, accumulated access stops reflecting current responsibility and can weaken separation of duties, create confusion, and expand the impact of an account compromise.
Should onboarding and offboarding be automated?
Stable, well-owned steps are strong candidates for automation. The firm should first define authoritative data, approvals, standard roles, exception handling, and recovery. Automation should execute a governed process rather than substitute for one.
How often should access be reviewed?
Review frequency should reflect the sensitivity and pace of change. Privileged and high-impact access deserves more frequent review. Role changes, departures, and temporary exceptions should also trigger event-based review rather than waiting for a calendar cycle.
Related reading: Identity Is the New Outage Domain · How Growing Firms Standardize Access Without Slowing Down
