Why 'Movers' Are the Hardest Part of JML (And How to Fix It)

Summary: Most JML projects focus on onboarding and offboarding. But the real risk and operational drag? It's in the middle-when people change roles, teams, and projects. Here's why movers are tough to govern in SaaS-heavy environments, why SCIM-only tools consistently fail, and what effective automation looks like for lean IT teams.

JML 101: Why Movers Matter More Than You Think

Joiner-Mover-Leaver (JML) is the industry standard for identity lifecycle management: provision, adjust, and remove access throughout a user's employment.

In theory, it's simple:

• Joiner: Grant correct access from day one.
• Mover: Update access when roles or context change.
• Leaver: Cleanly revoke access when someone leaves.

In practice, the "mover" stage breaks down:

• People move roles, teams, locations, and projects far more than they leave.
• Each move touches dozens of systems, roles, and granular permissions.
• Legacy IGA and "modern" SCIM-only tools simply aren't built for this pace of change.

One training resource on identity lifecycle management directly states that in real organizations, people change roles more often than they leave; promotions, lateral moves, temporary projects, and department transfers are where most access maintenance work happens^{1destcert.com}

Joiners: Noisy but Predictable

Joiners are noticeable. HR opens a ticket. A start date is set. Lack of access is obvious.

Most teams settle on a "good enough" process:

• Birthright access from HRIS to IdP sync
• SCIM-based user provisioning for core apps
• Standard onboarding checklist

Gaps may remain, but the process is repeatable.

Leavers: Critical but Checklist-Friendly

Leavers are high-stakes but procedural:

• HR marks a termination in the HRIS
• IdP disables account
• Someone (hopefully) runs an offboarding checklist

While partial offboarding and orphaned accounts persist, the trigger is clear and only happens once per person.

Movers: Where Risk Quietly Compounds

Movers are different:

• Role changes often happen gradually (shadowing, dual roles, temp projects).
• Old access is rarely removed.
• Many changes bypass HR (project participation, temp responsibilities, side tasks).

A survey by Ivanti found 45% of respondents say unnecessary access rights aren't removed when employees change roles^{2infosecurity-magazine.com} This isn't just a compliance issue; it's how entitlement creep becomes routine.

The result: the "mover" stage quietly drives the broadest attack surface and the most chaotic audit findings.

The Root Causes of the Mover Problem

1. Role Creep and Entitlement Sprawl

At onboarding, you can estimate what someone needs. After role changes, you rarely know what access they've already accumulated.

Common patterns:

• Add-only: New permissions for new roles, nothing removed.
• Layered groups: Users collect group memberships across roles.
• Project leftovers: Temporary access to repos or dashboards never expires.

Industry analysis shows access sprawl and entitlement creep occur when users accumulate permissions over time, mainly due to weak deprovisioning and poor role hygiene, especially during role changes^{3idmworks.com}

This is what movers cause: frequent, messy changes difficult to clean up.

2. Coverage Gaps-The SCIM Wall and the Long-Tail SaaS

Typical "modern" identity lifecycle diagrams:

• Okta or Entra as IdP
• SCIM-based provisioning for a handful of core SaaS apps
• Group/role mapping to HR

What these don't show:

• The 40-80 long-tail SaaS apps and internal tools managed by tickets and spreadsheets
• Apps where SCIM requires 5-10× more expensive enterprise plans (the SCIM tax)
• OT/ICS, on-prem, and custom systems-no modern API at all

Internal and external analyses agree: only around 20-40% of applications in most organizations are automated. The rest-legacy, on-prem, niche SaaS, OT/ICS-remain fully manual, concentrating both the operational work and risk

From Iden's own data:

Roughly 60% of SaaS apps don't support SCIM natively. For popular tools (Notion, Slack, Figma), SCIM sits behind pricey enterprise tiers, so most companies either pay the SCIM tax or rely on manual processes

Movers amplify these gaps: by definition, they touch more systems than joiners or leavers-often in the least automated parts of the stack.

3. New Species of Identities and Project-Based Work

Movers include more than FTEs changing titles:

• Contractors jumping teams/clients
• External partners with scoped, time-boxed access
• Bots, CI jobs, and AI agents being repurposed

Modern governance guidance notes that non-human identities-service accounts, bots, pipelines, virtual agents-now account for major access risk and must be governed like human identities^{4articles.idenhq.com}.

Yet most JML flows assume "human + HR record," leaving these identities outside mover processes.

4. Static Checks in a World of Continuous Change

Traditional governance leans on:

• Annual/quarterly access reviews
• Static RBAC models managed by tickets
• HR-driven events as triggers

But role changes and drift happen continuously.

Recent commentary from identity security vendors is unambiguous: JML manages only the beginning and end of the lifecycle, but "everything that matters in cloud security happens in the middle," where real-time identity intelligence and immediate access changes matter more than scheduled lifecycle events^5trustle.com

For movers, that "middle" is the lifecycle.

Why SCIM-Only and SSO-Only Approaches Break at Movers

Traditional SSO and SCIM addressed yesterday's access problem-safe onboarding to a few apps. Movers in a SaaS sprawl are a new threat.

Joiner vs. Mover vs. Leaver in a Typical Stack

The worst-automated stage is also the most frequent and complex.

SCIM's Design Limits for Movers

SCIM works for:

• Creating and deleting accounts
• Adjusting basic attributes and group membership

SCIM fails with:

• Fine-grained permissions (specific Slack channels, repo/project access)
• Complex, context-driven access (temporary access, SoD-aware entitlements)

Experts point out: SCIM provisions identity data but wasn't intended to model all app-level entitlements^{6pages.scmagazine.com}.

These fine-grained entitlements are exactly where mover risk hides.

The Coverage Reality for SSO/SCIM-Only Stacks

Feedback from practitioners:

• Okta and Entra work if you have 100% SAML/SCIM coverage-but that's rare^7reddit.com.
• Teams discover SCIM "fails half the SaaS apps" or requires enterprise tiers they can't justify.
• Custom scripts and orchestration fill gaps for high-risk apps only.

One study found 71% of organizations cite incompatibility with non-standard legacy apps as a key barrier to modernizing identity systems^{3idmworks.com}

When movers touch these legacy or non-SCIM apps, the process devolves into:

• Jira tickets
• Slack requests
• Admins manually updating access

That's not governance, it's wishful thinking.

Meanwhile, Attackers Target Identities First

Industry data estimates 80% of cyberattacks involve identity-based techniques. The number of human and machine identities is projected to grow more than 200% in a single year^{3idmworks.com}

If identities are main attack vectors:

• Movers with permission sprawl are prime targets
• Static SCIM syncs and annual reviews are inadequate
• Continuous, fine-grained control is essential-especially where SCIM/SSO don't reach

Designing Mover Automation That Actually Works

What does successful mover automation look like for a SaaS-heavy company with a lean IT team?

1. Anchor Movers to Source-of-Truth Events

Start with what you control:

• HRIS: Role, department, location, manager
• Directory/IdP: Groups, org units, dynamic rules
• ITSM: Formal change requests

Make every key HR attribute change (role, department, cost center, employment type) generate an access delta event. This becomes the single driver for mover workflows across all apps-not just ones with SCIM.

2. Model Access as Roles + Fine-Grained Entitlements

Classic RBAC: "Sales Rep" gets rights A, "Support Engineer" gets rights B.

For movers, add:

• Role bundles: Defined entitlements for each function (e.g., Sales gets Salesforce + finance dashboards)
• Fine-grained overlays: Temporary, project-based or resource-specific access

Mover logic should:

• Recalculate from scratch on role change-remove all entitlements not in the new role bundle, unless marked as exceptions
• Use time-bounded overlays for dual-role transitions

This actively prevents entitlement creep.

3. Use Agentic Workflows, Not Humans, for Provisioning

Agentic workflows = AI-driven, autonomous workflows that:

• Monitor authoritative systems for mover triggers
• Calculate required adds/removals
• Execute changes-across all systems-via plug-and-play connectors or bots

You want:

1. HR changes "Support Engineer -> Customer Success Manager."
2. Policy calculates adds/removals, evaluates exceptions.
3. Agentic workflow updates Salesforce, Slack, support tools, and knowledge bases-across SCIM and non-SCIM apps.
4. All changes logged in immutable audit logs.

Iden data: customers cut manual access tickets by ~80% within 60 days after automating lifecycle and access workflows. For movers, that means fewer tickets, fewer exceptions.

4. Bake Movers into Continuous Governance

Don't depend only on HR data.

Effective mover automation also uses:

• Usage signals: Remove unused permissions
• Risk signals: Flag sudden spikes or SoD conflicts
• Context: Account for manager, cost center, or project changes

Current best practice: event-driven reviews for hires, transfers, promotions, terminations-not just annual recertifications^{8censinet.com}. Movers need this event-driven, context-rich clean-up.

How Universal Coverage + Fine-Grained Control Fix the Mover Problem

Capability Checklist for Mover Automation

A modern governance layer must:

• Connect to every relevant app-SCIM, API, or neither
• Control permissions at the level you actually grant them (project, channel, repo)
• Drive real-time, policy-based decisions for changing access
• Keep immutable audit logs of all access state changes

Iden delivers on these requirements:

• Universal connector tech for any app-SCIM, API, or neither-covering the 80% of apps most tools leave manual
• Coverage for 175+ apps out of the box, with new connectors delivered in 48 hours if needed
• Granular permission management down to channel/repo/project level (beyond basic SCIM)
• Full lifecycle automation for human and non-human identities, immutable audit logs, policy-driven workflows

Movers in a Universal Coverage World: Real Scenarios

Scenario 1: Engineer -> Security Engineer

Today:

• Engineer accumulates GitHub repos, staging/prod access, Slack channels
• Moves to Security Engineering
• New access added; little or nothing removed

With policy-driven universal automation:

1. HR changes to "Security Engineer"
2. Policy engine removes unneeded repos, restricts prod access, keeps temporary overlays for knowledge transfer
3. Universal connectors apply changes across all tools-even non-SCIM-using agentic workflows
4. Audit log records what changed and why

Scenario 2: Support Rep -> Customer Success Manager

Today:

• Support Rep builds up access to support, debug tools, broad channel rights
• Slowly gets customer-facing tools; old access remains

With universal mover automation:

• HR triggers the mover workflow
• Support entitlements are removed, CS ones granted
• Overlapping access is retained or permissioned appropriately; temporary overlaps are auto-revoked

Key takeaway: Movers become boring. It's just another policy event-not a week of tickets.

Comparison: SCIM-Only vs Universal + Fine-Grained

Conclusion: Make Movers Boring Again

Ignore movers, and you'll keep wrestling with:

• Access sprawl, over-privileged accounts
• Audit pain
• Ticket chaos every reorg, promotion, or project

Here's how to escape:

1. Admit movers are the core problem. More frequent and complex than joiners or leavers.
2. Stop relying on SCIM alone. It's just plumbing, not governance intelligence.
3. Target universal coverage. Bring every app under lifecycle automation.
4. Model roles + fine-grained entitlements. Use bundles and overlays, not just groups.
5. Let agentic workflows handle grunt work. Humans build policies; the platform handles volume.
6. Make movers a trigger for continuous governance. Every mover event is an opportunity to remove stale permissions and reinforce least privilege.

If you already have SSO and some automation, you don't need another architecture deck-you need coverage and depth. Whether with Iden or another platform, set your standard: complete coverage, with mover events handled as the norm, not an exception.

Frequently Asked Questions

How is the "mover" stage different from joiners and leavers from a risk perspective?

Joiners/leavers are discrete, checklist-driven events. Movers happen often and informally-project shifts, manager switches, team changes. Each move adds access but rarely removes old rights, fueling role creep and entitlement sprawl. One compromised mover can have wider access than any typical joiner or leaver.

Can't I just tighten my RBAC model to fix movers?

Better RBAC helps, but it's not enough. You also need:

• Event-driven automation triggered by HRIS/IdP changes
• Connectors covering every app-not just those with SCIM
• Fine-grained permission management (channels, repos, projects)

Without universal coverage and automation, movers are still a mountain of manual work.

How does universal app coverage change mover workflows?

With universal coverage, movers shift from one-off fire drills to standard automation:

• HR or manager triggers a role change
• Policies recalculate access
• Connectors apply changes across all apps
• Audit logs track every change

IT shifts from "manual provisioning layer" to policy design-enabling true continuous governance.

Do I need a big rebuild to start automating movers?

No. The lean approach:

1. Identify 5-10 apps where mover pain is worst
2. Define role bundles and key policies
3. Connect via a governance platform with universal connectors
4. Switch on event-driven mover workflows
5. Refine edge cases and expand

This gets real results quickly-no massive redesign needed.

How do movers affect audits and compliance (SOC 2, ISO 27001, HIPAA, etc.)?

Auditors want proof:

• Who had access to what, when
• How access changes as people move roles
• How SoD violations are prevented and detected

If mover changes are ticket- or admin-driven, audit cycles take weeks. With automated workflows and immutable logs:

• Every add/remove is time-stamped and traceable
• Role changes trigger access updates automatically
• SoD checks and exception handling show up in one dashboard

No more uncertainty-just instant answers for audit and compliance teams.