How Privilege Creep Compounds in Two Directions | The Mover's Journey

Your access review flags something unusual:

Michael has access to 52 applications with admin or owner roles in 14 of them.

For context, the median for his current role—"Director of Engineering"—is 24 apps with admin access in 2–3 tools maximum.

You pull his access history. Not because you suspect anything malicious. Just curiosity about how someone ends up with double the expected footprint and 5x the elevated permissions.

Then you see it:

2 years ago: Joined as "Senior Software Engineer"

12 apps, standard user in all

18 months ago: Moved to "Engineering Manager"

23 apps, admin in 3 apps
Kept all 12 original apps, no downgrades

1 year ago: Shifted to "Product Engineering Lead"

34 apps, admin in 7 apps
Kept all previous apps and admin rights

6 months ago: Promoted to "Director of Engineering"

43 apps, admin in 12 apps
Kept all previous apps and elevated permissions

Today: 52 apps, admin in 14 apps and counting

Four role changes in two years. Each time, new access was added. Each time, new admin rights were granted. Each time, old access and old privileges were retained.

He accumulated access from every role he has held AND elevated permissions from every level he's passed through, creating a privilege footprint that spans:

Three teams
Two departments
Four different job functions
Five different privilege levels

This isn't privilege creep from slow drift. This is privilege creep from compounding accumulation in two directions at once.

Michael is a mover. And movers are the single biggest driver of privilege creep in every organization.

This article breaks down:

What Privilege Creep Actually Means (It's Both Dimensions)

Most security teams treat access expansion and permission elevation as separate problems. They're not. They're two dimensions of the same failure mode.

Privilege creep is what happens when users simultaneously:

Gain access to more systems (horizontal expansion)
Gain higher permissions within those systems (vertical escalation)

Both compound over time. Both accelerate during role changes. Both go undetected until audits surface the damage.

The Two Dimensions of Privilege Creep

Horizontal Expansion: Access Sprawl

This is what happens when users keep gaining access to more systems without losing old ones.

Jessica's horizontal expansion:

Started with 12 apps
Added Backend team tools: +8 apps
Added management tools: +7 apps
Added Product team tools: +12 apps
Added Director-level tools: +9 apps
Total: 48 apps before organic growth

Characteristic: User accumulates more applications than their current role requires, spanning teams and functions they no longer work with.

Vertical Escalation: Permission Inflation

This is what happens when users gain increasingly powerful roles inside the systems they access:

User → Admin
Viewer → Editor → Owner
Standard User → Super Admin
Read-only → Read/Write/Delete
Contributor → Workspace Owner

Jessica's vertical escalation:

Started as standard user in all 12 apps
Engineering Manager: became admin in 3 management tools
Product Lead: became admin in 4 more product tools
Director: became admin in 5 additional strategic tools
Plus retained IC-level admin rights from early emergency access grants

Characteristic: User's level of control within applications becomes excessive, usually through temporary elevations, emergency access, or promotions that add but never subtract privileges.

Why Both Dimensions Matter

When you only track one dimension, you miss the compounding effect:

Horizontal expansion alone:

"Jessica has access to 52 apps"
Seems concerning but not catastrophic
Could be cross-functional role justification

Vertical escalation alone:

"Jessica is an admin in 14 apps"
Seems high but maybe she's senior enough
Could be legitimate for Director level

Both dimensions together:

"Jessica has access to 52 apps with admin rights in 14 of them, spanning systems from three teams she no longer works with and four role levels she's moved past"
Now it's clear: this is uncontrolled accumulation

From an attacker's perspective, this is the perfect target:

Traditional attacks require two techniques:

Lateral movement: Pivot from system to system to expand reach
Privilege escalation: Exploit vulnerabilities to gain admin rights

Movers with two-dimensional privilege creep eliminate both requirements. Compromise Jessica's account once, and the attacker inherits:

Pre-staged lateral movement (already has access to multiple teams' systems)
Pre-staged privilege escalation (already has admin rights in those systems)
No exploitation needed—just legitimate credentials with excessive reach and control

The danger multiplies when both dimensions escalate simultaneously:

Broader attack surface (more entry points)
Deeper control in each entry point (more powerful actions)
Cross-team privilege chains (can pivot between systems using legitimate admin access)
Elevated permissions in obsolete systems (admin in tools she shouldn't access at all)

Privilege creep isn't horizontal OR vertical. It's horizontal AND vertical, compounding with every move.

Why Movers Are the #1 Privilege Creep Vector

Most identity governance focuses on joiners and leavers. Onboarding gets new hires set up. Offboarding removes access when people leave.

But movers—employees who change roles, teams, or departments while staying at the company—create the largest privilege accumulation blind spot.

The Two-Dimensional Accumulation Math

Joiners start with 8–15 apps (role baseline), standard user in most

Horizontal risk: Low (starting fresh)
Vertical risk: Low (starting at appropriate level)
Removal opportunity: None (no prior access or privileges to clean up)

Leavers exit with whatever they've accumulated

Horizontal risk: None (they're leaving)
Vertical risk: None (they're leaving)
Removal opportunity: High (full deprovisioning)

Movers keep old access + old privileges + gain new access + gain new privileges

Horizontal risk: Extreme (additive by default across teams)
Vertical risk: Extreme (permissions stack across role levels)
Removal opportunity: Low (cleanup rarely happens in either dimension)

Movers don't reset. They compound in both directions simultaneously.

The Organizational Scale

In a typical 500-person company:

Joiners: ~100 per year (20% turnover)

Leavers: ~100 per year (20% turnover)

Movers: ~125–150 per year (25–30% of workforce has internal role changes)

Movers outnumber joiners and leavers. And each move is a two-dimensional accumulation event.

Annual mover-driven privilege accumulation:

Horizontal dimension:

125 movers × 8 apps added per move = 1,000 new app grants
125 movers × 0 apps removed per move = 0 access cleanup
Net: 1,000 unnecessary access grants

Vertical dimension:

125 movers × 2 new admin roles per move = 250 new elevated permissions
125 movers × 0 admin downgrades per move = 0 privilege cleanup
Net: 250 unnecessary elevated permissions

Combined impact:

1,000 excess access grants
250 excess admin permissions
Creates 125 overprivileged accounts spanning multiple teams and permission levels

This doesn't count natural drift. This is purely role-change accumulation.

Why Movers Fly Under the Radar

Your identity governance is designed around two lifecycle events:

Hire → Provision access at appropriate level
Terminate → Revoke all access and privileges

Internal moves don't fit this model. They're not "new users" requiring full provisioning. They're not "departing users" requiring full revocation.

They're existing users who need adjustments. And "adjustments" always means:

Adding new access (horizontal)
Adding new privileges (vertical)

It almost never means:

Removing old access
Downgrading old privileges

JML workflows have a two-dimensional mover blind spot built into their design.

The Four Types of Moves That Guarantee Two-Dimensional Accumulation

Not all moves are equal. Some create more accumulation than others. But all of them follow the same pattern: add access, add privileges, keep everything.

Type 1: The Lateral Move (Same Level, Different Team)

Scenario: Jessica moves from the Backend Engineering team to the Platform Engineering team. Same level, same title, different team.

What should happen:

Horizontal:

Remove Backend team-specific access (repos, tools, systems)
Add Platform team-specific access

Vertical:

Transfer any team-level admin rights from Backend to Platform
Remove Backend-specific elevated permissions

What actually happens:

Horizontal:

Add Platform team access: +8 apps
Keep Backend team access: 12 apps retained

Vertical:

Add Platform team admin access: +2 admin roles
Keep Backend team admin rights: 1 admin role retained

Why cleanup doesn't happen:

Access level:

Backend team manager doesn't get notified of the move
Platform team manager only requests "what Jessica needs," not "what Jessica should lose"
IT provisions forward, not backward

Permission level:

Nobody tracks admin rights at the team level
Jessica might still collaborate with Backend occasionally
"Better to keep access and admin rights just in case"
Removing admin access feels like downgrading someone who's at the same level

Privilege accumulation:

+8 apps (horizontal)
+2 admin roles while keeping old admin role (vertical)
Old team access and privileges never removed

Compound factor: If Jessica makes 3 lateral moves in two years:

She retains access from all three teams (horizontal sprawl)
She retains elevated permissions in all three team tools (vertical sprawl)
She works on one team but has admin rights across three

Type 2: The Promotion (Vertical Move Within Same Team)

Scenario: Jessica gets promoted from "Senior Engineer" to "Engineering Manager." Same team, higher responsibility.

What should happen:

Horizontal:

Remove some IC-specific access (project-specific dev tools)
Add management-specific access (HRIS, performance tools)

Vertical:

Remove IC-level admin rights (deployment tools, infrastructure console)
Add management-level admin rights (performance systems, budget tools)
Downgrade from admin to standard user in hands-on dev tools she still needs

What actually happens:

Horizontal:

Add management access: +6 apps
Keep all IC access: 15 apps retained

Vertical:

Add management admin rights: +3 admin roles
Keep all IC admin rights: 2 admin roles retained (even though she's no longer hands-on)

Why cleanup doesn't happen:

Access level:

Managers often want to "stay technical"
Nobody questions whether daily access to dev tools makes sense
Removing access feels like downgrading someone who just got promoted

Permission level:

"She might need to jump into code occasionally"
"Technical managers should keep admin access to dev tools"
Nobody enforces privilege reduction after promotion
Downgrading admin rights feels punitive during a promotion

Privilege accumulation:

+6 apps (horizontal)
+3 new admin roles while keeping old admin rights (vertical)
IC-level access and privileges retained despite role change

Compound factor: Promote someone 3 times (IC → Manager → Senior Manager → Director):

They accumulate tools from all four levels (horizontal)
They accumulate admin privileges from all four levels (vertical)
A Director with IC-level hands-on admin access

Type 3: The Cross-Functional Move (Different Department)

Scenario: Jessica moves from Engineering to Product Engineering, bridging technical and product responsibilities.

What should happen:

Horizontal:

Remove pure engineering tools (infrastructure, deployment systems)
Add product tools (roadmapping, analytics, customer feedback)
Retain shared tools (communication, documentation)

Vertical:

Remove engineering admin rights (AWS Console admin, infrastructure tools)
Add product admin rights (analytics platforms, customer tools)
Downgrade to standard user in engineering tools if retained for reference

What actually happens:

Horizontal:

Add Product team access: +12 apps
Keep all Engineering access: 18 apps retained

Vertical:

Add Product team admin rights: +4 admin roles
Keep all Engineering admin rights: 5 admin roles retained

Why cleanup doesn't happen:

Access level:

Engineering manager doesn't coordinate with Product manager
Jessica's role is hybrid, so "she might need both"
HRIS shows her in Product, but Engineering systems still list her as active
Nobody knows which apps belong to which department

Permission level:

"She's cross-functional, she needs admin access to both domains"
Product manager doesn't know what engineering admin rights she has
Engineering manager doesn't see product admin rights
Nobody has visibility into her combined privilege footprint

Privilege accumulation:

+12 apps (horizontal)
+4 new admin roles while keeping engineering admin rights (vertical)
Cross-functional roles create maximum two-dimensional accumulation

Compound factor: Move between 3 different functions (Engineering → Product → Operations):

Accumulate tools from all three domains (horizontal)
Accumulate admin privileges across all three functions (vertical)
One person with owner/admin access spanning incompatible domains

Type 4: The Project-Driven Temporary Move

Scenario: Jessica gets temporarily assigned to a special project while maintaining her primary role. Not a formal move, but temporary dual responsibility.

What should happen:

Horizontal:

Add project-specific access with expiration date
Remove project access when assignment ends

Vertical:

Grant project-specific elevated permissions with expiration
Downgrade to standard user or remove entirely when project closes

What actually happens:

Horizontal:

Add project access: +8 apps
No expiration date set
Project ends, access remains

Vertical:

Add project admin/owner access: +2 elevated roles
No privilege downgrade scheduled
Project closes, admin rights remain

Why cleanup doesn't happen:

Access level:

Temporary assignments don't trigger JML workflows
Project closures don't trigger access reviews
Nobody owns cleanup after project completion

Permission level:

"Temporary" admin access has no enforced time limit
Project team dissolved, nobody responsible for revoking elevated permissions
Jessica returns to primary role with project admin access still active

Privilege accumulation:

+8 apps (horizontal)
+2 admin roles become permanent (vertical)
Project access and privileges become permanent

Compound factor: If Jessica gets assigned to 4 special projects over two years:

Accumulates tools from all four projects (horizontal)
Accumulates elevated permissions from all four projects (vertical)
Never loses access or admin rights from any completed project

The Mover Timeline: How Two-Dimensional Accumulation Compounds

Let's map Jessica's actual journey through four role changes, tracking both dimensions of privilege creep.

Starting Point: Senior Software Engineer

Initial access:

12 apps
Standard user in all 12
Slack, email, GitHub, Jira, Figma, Notion, Datadog, PagerDuty, Sentry, CircleCI, AWS Console, Confluence

Privilege footprint:

✅ Clean horizontal baseline (12 apps appropriate for role)
✅ Clean vertical baseline (standard user everywhere)

Move 1 (Month 6): Backend Team → Platform Team (Lateral Move)

Access changes:

Added:

+8 apps: Kubernetes Dashboard, Terraform Cloud, Vault, Consul, Grafana, ArgoCD, Helm, Backstage
+2 admin roles: Terraform Cloud admin (for infrastructure changes), Kubernetes Dashboard admin (for cluster management)

Retained:

12 Backend apps (all tools)
1 admin role from Backend team (CircleCI admin from previous emergency access)

Should have removed:

5 Backend-specific apps
1 Backend admin role

Current state:

Horizontal: 20 apps (should have 15)
Vertical: 3 admin roles (should have 2)
Accumulation: +5 excess apps, +1 excess admin role

Why nobody noticed:

Access dimension:

Jessica still Slack-messages the Backend team
She occasionally reviews Backend PRs
"She might need to reference old systems"

Permission dimension:

CircleCI admin access was from an emergency fix months ago
Nobody tracked that temporary elevation
"She might need to help Backend team occasionally"

Move 2 (Month 12): Platform Engineer → Engineering Manager (Promotion)

Access changes:

Added:

+7 apps: Lattice, BambooHR, Workday, Expensify, Carta, Greenhouse, 15Five
+3 admin roles: Lattice admin (performance management), BambooHR admin (team management), Greenhouse admin (recruiting)

Retained:

20 apps (all IC engineering tools)
3 admin roles from IC level (CircleCI, Terraform, Kubernetes)

Should have removed:

3 hands-on dev tools (or downgraded to standard user)
2 IC-level admin roles (Terraform, Kubernetes)

Current state:

Horizontal: 27 apps (should have 18)
Vertical: 6 admin roles (should have 3)
Accumulation: +9 excess apps, +3 excess admin roles

Why nobody noticed:

Access dimension:

"I want to stay technical"
"I still review code occasionally"
Nobody challenged whether daily dev tool access makes sense for a manager

Permission dimension:

"Technical managers need infrastructure admin access"
Removing admin rights during promotion feels punitive
Nobody enforced privilege downgrade policy (because no policy exists)

Move 3 (Month 18): Engineering Manager → Product Engineering Lead (Cross-Functional)

Access changes:

Added:

+12 apps: Productboard, Amplitude, Mixpanel, Pendo, Heap, Intercom, Typeform, Dovetail, Calendly, UserTesting, Hotjar, Looker
+4 admin roles: Amplitude admin (analytics), Mixpanel admin (product insights), Intercom admin (customer communication), Looker admin (data access)

Retained:

27 apps (all engineering and management tools)
6 admin roles from previous roles

Should have removed:

8 pure-engineering tools (or downgraded several to standard user)
3 engineering-specific admin roles

Current state:

Horizontal: 39 apps (should have 22)
Vertical: 10 admin roles (should have 4)
Accumulation: +17 excess apps, +6 excess admin roles

Why nobody noticed:

Access dimension:

"It's a hybrid role, I need both engineering and product tools"
Product manager didn't know what engineering access she already had
Engineering manager didn't coordinate cleanup with product team

Permission dimension:

"Cross-functional leaders need admin access across both domains"
Product manager didn't see engineering admin rights
Engineering manager didn't see product admin rights
Nobody had visibility into combined privilege footprint

Move 4 (Month 24): Product Engineering Lead → Director of Engineering (Promotion)

Access changes:

Added:

+9 apps: Salesforce, ChartMogul, NetSuite, Slack Enterprise Grid Admin, Zoom Admin, Google Workspace Admin, Okta Admin, OneLogin, JumpCloud
+5 admin roles: Slack Enterprise admin, Google Workspace admin, Okta admin, OneLogin admin, Salesforce admin

Retained:

39 apps (everything accumulated so far)
10 admin roles from all previous levels

Should have removed:

15 IC and product hands-on tools
7 hands-on admin roles (IC-level, product-level operational admin)

Current state:

Horizontal: 48 apps (should have 24)
Vertical: 15 admin roles (should have 3)
Accumulation: +24 excess apps, +12 excess admin roles

Why nobody noticed:

Access dimension:

Each previous move seemed justified individually
Nobody looked at the aggregate footprint
Access reviews hadn't happened yet (company growing fast)

Permission dimension:

Each admin elevation seemed necessary at the time
Nobody tracks privilege accumulation across role changes
Admin rights from four different levels never reconciled
Total privilege was invisible across multiple provisioning events

Today: 4 Role Changes Later

Current privilege footprint:

Horizontal: 52 apps (additional organic growth)
Vertical: 14 admin roles (one revoked during audit, others added)

Role-appropriate footprint:

Horizontal: 24 apps
Vertical: 2–3 admin roles (strategic oversight tools only)

Total accumulation:

Excess apps: 28 apps (117% over baseline)
Excess admin roles: 11–12 admin roles (400% over baseline)

Privilege composition:

Horizontal dimension:

Backend team tools (no longer relevant): 8 apps
IC development tools (no longer hands-on): 7 apps
Platform team tools (moved away 18 months ago): 6 apps
Product tools (moved to broader leadership): 4 apps
Redundant admin tools: 3 apps

Vertical dimension:

IC-level admin rights (CircleCI, Terraform, Kubernetes): 3 roles
Team-level admin rights (Backend, Platform): 2 roles
Manager-level admin rights (Lattice, BambooHR, Greenhouse): 3 roles
Product-level admin rights (Amplitude, Mixpanel, Intercom, Looker): 4 roles
Director-level admin rights (appropriate): 2 roles

Total removed during 4 role changes:

Apps removed: 0
Admin roles downgraded: 0

Why Two-Dimensional Cleanup Never Happens

The core problem isn't that organizations don't care about cleanup. It's that the JML process is structurally designed to add in both dimensions, never subtract.

Reason 1: Provisioning Workflows Are Forward-Looking Only

When IT receives a mover request:

The ticket says: "Jessica Chen is moving from Product Engineering Lead to Director of Engineering. Please provision appropriate access."

The ticket doesn't say: "Jessica Chen is moving from Product Engineering Lead to Director of Engineering. Please:

Remove access from her old role
Downgrade elevated permissions in tools she should no longer admin
Provision access for her new role
Grant appropriate admin rights for Director level only"

The provisioning mindset is additive in both dimensions. "What does she need?" not "What should she lose and what should be downgraded?"

Reason 2: Managers Only See Their Own Team's Needs

When Jessica moves to a new team, her new manager knows:

✅ What tools their team uses
✅ What admin rights their team's senior members typically need

❌ What tools Jessica already has access to
❌ What admin rights Jessica already holds
❌ What tools and privileges the old team used
❌ Which apps and admin roles Jessica should lose

The new manager requests the apps and admin rights they know about. They can't request removal or downgrade of things they don't know exist.

Reason 3: Old Managers Aren't Notified of Departures

When Jessica leaves the Platform team:

Access dimension:

Platform team manager doesn't get formal notification
No deprovisioning ticket created
Platform team's app owners don't know Jessica left

Permission dimension:

Nobody notified that Jessica's admin rights should be revoked
Platform team admin access remains active
Jessica still appears in admin lists for Platform tools

Moves are invisible to the old team. Without notification, neither access nor privilege cleanup can happen.

Reason 4: "Hybrid Roles" and "Technical Leaders" Justify Everything

Every mover has plausible reasons to retain old access AND old privileges:

Horizontal justifications:

"She might still collaborate with the old team"
"She's cross-functional, she needs visibility into multiple domains"
"She might need to reference old systems"

Vertical justifications:

"She's a technical leader, she should maintain hands-on admin access"
"She might need to jump in during emergencies"
"Senior people need elevated access across the board"
"Better to keep admin rights than have her blocked"

Hybrid roles blur boundaries. Technical seniority conflates with privilege need. And blurry boundaries mean retention by default in both dimensions.

Reason 5: Removal Feels Like Punishment, Downgrade Feels Like Demotion

Removing someone's access or downgrading their admin rights during a promotion or positive move feels punitive:

Horizontal removal: "You just got promoted to Director, but we're taking away access to engineering tools."

Vertical downgrade: "You just got promoted to Director, but we're revoking your admin rights in development tools."

Nobody wants to dampen a promotion with access restrictions or privilege downgrades. So cleanup gets deprioritized or skipped entirely in both dimensions.

Reason 6: HRIS and IDP Don't Sync on Privilege Changes

When Jessica's title changes in HRIS:

HRIS updates: "Jessica Chen - Director of Engineering"

IDP sees: Nothing (HRIS sync doesn't trigger on title changes, only hire/termination)

App-level permissions: Unchanged

Admin roles: Unchanged

Title changes in HRIS don't cascade to access changes OR privilege adjustments in IDP or SaaS apps. The systems aren't designed to sync on movers in either dimension.

Reason 7: Nobody Tracks Privilege Across Systems

Even organizations that attempt access governance rarely track privilege elevation across apps.

What they track:

Who has access to which systems (horizontal)

What they don't track:

Who has admin/owner roles in which systems (vertical)
How many elevated permissions each person holds
Whether admin rights align with current role
When privileges were granted and why

Without cross-system privilege visibility, vertical accumulation is invisible until an audit surfaces it.

The Detection Signals for Two-Dimensional Privilege Creep

Mover-driven privilege creep has distinct patterns in both dimensions. If you monitor for these signals, you can catch accumulation early.

Signal 1: Access Spike With Permission Elevation

What to measure: Users whose access count AND admin role count increase simultaneously

When Jessica moved from Platform to Product Engineering:

Access jumped from 20 → 32 apps (+60%) [horizontal]
Admin roles increased from 3 → 7 (+133%) [vertical]
No offboarding event in HRIS
No access or privilege reduction preceded the increase

Alert threshold: Flag any user whose:

Access increases by 20%+ within 30 days AND
Admin role count increases by 1+ within the same period
Without a corresponding role title change justifying that much new privilege

Signal 2: Multi-Team Access With Cross-Team Admin Rights

What to measure: Users with active access AND elevated permissions across multiple teams they no longer work with

By Month 18, Jessica had:

Horizontal dimension:

Backend Engineering team tools
Platform Engineering team tools
Product Engineering team tools
Leadership/Admin tools

Vertical dimension:

Admin rights in Backend tools (CircleCI)
Admin rights in Platform tools (Terraform, Kubernetes)
Admin rights in Product tools (Amplitude, Mixpanel, Intercom, Looker)
Admin rights in leadership tools (Lattice, BambooHR, Greenhouse)

She should only have access to one primary team's tools plus leadership tools, with admin rights only in 2–3 strategic oversight systems.

Alert threshold: Flag users with:

Active access to 3+ distinct team-specific tool sets AND
Admin roles spanning 3+ different team domains

Signal 3: Role-Privilege Mismatch

What to measure: Users whose app footprint AND permission levels don't align with current role

Jessica is a "Director of Engineering" with:

Horizontal mismatches:

IC development tools (GitHub, CircleCI, AWS Console)
Hands-on monitoring tools (Datadog, Sentry, PagerDuty)
Product analytics tools (Amplitude, Mixpanel, Heap)

Vertical mismatches:

Admin rights in IC tools (CircleCI, Terraform, Kubernetes)
Admin rights in team-specific tools (no longer manages those teams)
Owner access in project tools (projects completed months ago)

Directors typically have strategic oversight tools with limited elevated permissions, not hands-on operational admin access.

Alert threshold: Flag when user's combined access and privilege pattern has:

<60% overlap with peer baseline for access (horizontal)
3x or more admin roles than peers in same position (vertical)

Signal 4: Promotion Without Privilege Adjustment

What to measure: Users who get promoted but retain all lower-level access AND all lower-level admin rights

When Jessica promoted from Engineer → Manager → Director:

Each promotion added:

New tools for higher-level functions (horizontal expansion)
New admin roles for higher-level oversight (vertical expansion)

No promotion triggered:

Removal of IC tools (horizontal)
Downgrade of IC admin access (vertical)
Removal of hands-on operational tools
Revocation of team-level admin rights from old teams

Alert threshold: When role level increases (IC → Manager → Director) without ANY corresponding:

Access reduction (horizontal)
Privilege downgrade (vertical)
Flag for immediate two-dimensional review

Signal 5: Old Team Activity With Persistent Admin Access

What to measure: Users who are still active in former teams' systems AND still hold admin rights in those systems

Jessica moved from Backend to Platform 18 months ago. But she's still:

Horizontal activity:

In Backend Slack channels
Active in Backend GitHub repos
Has access to Backend-specific AWS accounts

Vertical activity:

Using CircleCI admin access to approve Backend deployments
Still listed as admin in Backend team tools
Can modify Backend team configurations

Alert threshold: Users with:

Login activity in former team's systems 90+ days after move (horizontal) AND
Admin-level actions in those systems (vertical)
Especially concerning if admin rights were used recently in old team tools

Signal 6: Dormant Privilege Across Obsolete Access

What to measure: Elevated permissions in systems that are no longer being used

After moving to Director role, Jessica hasn't logged into:

CircleCI (8 months) — but still has admin
Terraform Cloud (6 months) — but still has admin
Vault (10 months) — but still has admin
Several product analytics tools (4+ months) — but still has admin/owner

These were relevant in her old roles. They're not relevant now. But the admin rights persist even though usage stopped.

Alert threshold: Users with:

5+ apps unused for 90+ days (horizontal) AND
2+ admin roles in those unused apps (vertical)
Especially where those apps correlate with previous role

Signal 7: Admin Role Sprawl

What to measure: Users who hold admin rights across too many unrelated systems

Jessica has admin roles in:

3 development/infrastructure tools
4 product/analytics tools
3 HR/people management tools
2 communication/admin platforms
2 identity/access management tools

Unless someone is in IT or Security, having admin rights across 5+ unrelated categories signals uncontrolled privilege accumulation.

Alert threshold: Flag when non-IT/Security users have:

Admin roles in 5+ tools spanning 3+ functional categories
Owner access in systems outside their department
Super-user privileges in tools from former roles

The Compound Effect: Multiple Moves, Maximum Accumulation

The real danger isn't a single move. It's serial movers who change roles multiple times, accumulating in both dimensions with every transition.

The Serial Mover Profile

Characteristics:

3+ role changes in 2 years
High performer (gets promoted/moved frequently)
Cross-functional (works across multiple domains)
Long tenure (stays at company through multiple transformations)

Two-dimensional accumulation pattern:

Horizontal:

Each move adds 6–12 apps
Each move removes 0 apps
After 4 moves: 25–40 excess apps

Vertical:

Each move adds 2–4 admin roles
Each move downgrades 0 admin roles
After 4 moves: 8–12 excess admin roles

Why they're extreme risk:

Horizontal risk:

Broadest access footprint in the org
Span multiple teams, functions, and departments
Carry access from obsolete roles

Vertical risk:

Most elevated permissions in the org
Admin rights accumulated from multiple privilege levels
Often have owner/super-user rights from previous leadership positions

Combined risk:

Compromising this account grants attacker:
- Entry to systems across entire org (horizontal)
- Elevated control within those systems (vertical)
- Ability to pivot between teams with legitimate admin access
- Maximum blast radius for any security incident

Example: The 3-Year Serial Mover

Year 1:

Q1: Joins as IC

12 apps, standard user (0 admin roles)

Q3: Moves to different team

20 apps (+8), 1 admin role from emergency access

Year 2:

Q1: Promoted to manager

27 apps (+7), 4 admin roles (+3 management tools, kept IC admin)

Q3: Moves to cross-functional role

39 apps (+12), 8 admin roles (+4 product tools, kept all previous)

Year 3:

Q1: Promoted to senior manager

47 apps (+8), 12 admin roles (+4 strategic tools, kept all previous)

Q3: Moves to different department

58 apps (+11), 16 admin roles (+4 new department tools, kept all previous)

Total role changes: 6

Total privilege accumulation:

Horizontal:

Apps removed: 0
Final count: 58 apps
Should have: 22 apps
Excess: 36 apps (164% over baseline)

Vertical:

Admin roles downgraded: 0
Final count: 16 admin roles
Should have: 2–3 admin roles
Excess: 13–14 admin roles (500% over baseline)

Each move compounded the previous accumulation. By Year 3, the employee has:

Access footprint spanning 6 different roles across 4 teams and 2 departments (horizontal)
Admin privileges from 6 different role levels and functions (vertical)
More combined privilege than anyone except IT and Security

The Cost of Two-Dimensional Privilege Creep

Movers don't just accumulate access and permissions. They accumulate the highest-risk combination: broad access WITH elevated control.

Security Impact

Mover-driven privilege creep pre-stages both dimensions of attack techniques:

Traditional attacks require two phases:

Lateral movement: Attacker moves from system to system to expand access
Privilege escalation: Attacker exploits vulnerabilities to gain admin rights

Movers with two-dimensional privilege creep eliminate both phases. Attackers don't need to move or escalate—they just need one compromised credential.

Horizontal dimension = Pre-staged lateral movement:

Jessica already has access to Backend, Platform, Product, and Leadership systems
Attacker doesn't need to pivot between systems
Attacker inherits legitimate access to multiple teams' environments
Every system Jessica can access is immediately available to the attacker

Vertical dimension = Pre-staged privilege escalation:

Jessica already has admin rights in 14 different applications
Attacker doesn't need to exploit elevation vulnerabilities
Attacker inherits legitimate elevated permissions across multiple domains
Every admin action Jessica can perform is immediately available to the attacker

Combined = Maximum blast radius from day one:

Compromising a serial mover's credentials grants:

Immediate access to systems across entire org (horizontal)
Immediate elevated control within those systems (vertical)
No need for lateral movement (already pre-positioned everywhere)
No need for privilege escalation (already pre-elevated)
Legitimate-looking actions that bypass monitoring
Maximum damage potential with minimal attacker effort

Elevated privilege accumulation:

Movers who get promoted accumulate admin rights from each level
IC tools + Manager tools + Director tools = overprivileged across all domains
Each move up grants more powerful permissions while retaining old ones
Results in accounts with IC hands-on admin + strategic admin + cross-functional admin

Cross-functional privilege chains:

Engineering → Product → Operations moves create admin access to all three domains
Attackers can pivot between incompatible systems using legitimate elevated access
Movers become highest-value targets because compromise grants maximum reach and control

Compliance Impact

Audit findings now hit both dimensions:

Horizontal findings:

"Why does this Director have access to 40 tools?"
"Why does this employee have access to 3 different teams' systems?"

Vertical findings:

"Why does this Director have IC-level admin access?"
"Why does this Product Manager have admin rights in Engineering infrastructure?"
"Why does this person have admin access to tools they haven't used in 6 months?"

SOX/SOC 2/ISO violations compound:

Horizontal violations:

Excessive access breadth (one person spans incompatible functions)

Vertical violations:

Segregation of duties failures (admin rights across incompatible domains)
Excessive privilege (role doesn't justify admin access)
Elevated permissions with no business justification

Combined violations:

Access to systems they shouldn't touch (horizontal) WITH admin rights in those systems (vertical)
Creates maximum compliance exposure

Operational Impact

Offboarding complexity multiplies:

Movers who eventually leave have:
- 2–3x more access to revoke (horizontal)
- 5–10x more admin roles to downgrade/remove (vertical)
Offboarding takes longer, requires coordination across more teams
Much higher chance of missing systems or admin rights during deprovisioning

License waste compounds:

Each unnecessary app = wasted license (horizontal)
Each unnecessary admin seat = premium license waste (vertical)
Example: 25 employees with:
- 20 excess apps each = 500 wasted licenses
- 4 excess admin seats each = 100 wasted premium licenses
- At $15/month average + $30/month admin premium = $120K annual waste

Access review overwhelm:

Quarterly reviews become unmanageable when users have:
- 40–50 apps to validate (horizontal)
- 10–15 admin roles to justify (vertical)
Reviewers can't make informed decisions about appropriateness in either dimension
Reviews take exponentially longer
Approvals become rubber-stamps because cognitive load is too high

Fixing Mover Workflows: The Two-Dimensional Prevention Framework

You can't stop privilege creep without fixing how movers are handled in both dimensions. Here's the redesign:

1. Mover-Specific JML Workflows With Privilege Adjustment

Standard JML has two paths: Joiner, Leaver.

You need a third: Mover with Privilege Reconciliation.

Mover workflow should:

Horizontal dimension:

Trigger on role change in HRIS
Map old role access vs new role access
Remove old role-specific access FIRST
Add new role-specific access SECOND
Require approval for any retained access

Vertical dimension:

Map old role privilege levels vs new role privilege levels
Downgrade admin rights in old role systems FIRST
Grant appropriate admin rights for new role SECOND
Require VP approval for any retained elevated permissions across roles
Default to standard user unless admin is explicitly justified

Implementation:

HRIS sync triggers on title/department/manager changes, surfacing:

"Jessica is moving from Platform to Product"
"Current access: [list] with admin in: [list]"
"New role needs: [list] with admin justified in: [list]"
"Recommended removals: [access list]"
"Recommended downgrades: [admin role list]"

Default action: Remove everything except core tools, downgrade all admin to standard user

New manager must explicitly approve:

Retained access from old role
Retained admin rights from old role

2. Pre-Move Privilege Audit (Both Dimensions)

Before someone moves, run a two-dimensional privilege audit:

Questions to answer:

Horizontal:

What access does this person currently have?
Which apps are tied to their old role/team?
Which apps will they need in their new role?

Vertical:

What admin roles does this person currently hold?
Which admin rights are tied to their old role/team?
Which elevated permissions will they need in their new role?

Both dimensions:

Which apps should be removed?
Which apps should be retained?
Which admin roles should be downgraded to standard user?
Which admin roles should be removed entirely?
Which new admin roles are justified?

Output:

Removal list (old team tools) [horizontal]
Downgrade list (admin → standard user in retained tools) [vertical]
Revocation list (admin roles tied to old team) [vertical]
Addition list (new team tools) [horizontal]
Elevation list (new admin roles with justification) [vertical]
Retention list (approved by both old and new managers for access AND privileges)

This audit should happen BEFORE the move, not after.

3. Old Manager Two-Dimensional Sign-Off

When someone leaves a team, the old manager should be notified about BOTH dimensions:

Notification should include:

"Jessica Chen is leaving your team on [date]"
"Current access includes: [list of team-specific tools]"
"Current elevated permissions: [list of admin roles]"
"Recommended access removals: [auto-generated list]"
"Recommended privilege downgrades: [auto-generated list]"
"Please approve cleanup in both dimensions"

Two-dimensional sign-off required:

Old manager confirms:

"Yes, remove Jessica from these team tools" [horizontal]
"Yes, downgrade/revoke these admin roles" [vertical]

New manager confirms:

"These are the only old team tools she should retain" [horizontal]
"These are the only old admin rights she should keep" [vertical]
"Here's why each retained privilege is justified"

Four-way approval prevents accumulation in both dimensions.

4. Privilege Budgets That Prevent Both Types of Bloat

Set ceilings for BOTH dimensions per role level:

Horizontal budgets (access):

IC roles: 15 apps max
Manager roles: 25 apps max
Director roles: 35 apps max

Vertical budgets (admin roles):

IC roles: 1–2 admin roles max (project-specific)
Manager roles: 2–3 admin roles max (team management)
Director roles: 3–4 admin roles max (strategic oversight)

When someone moves and would exceed EITHER budget:

System flags the overage and forces:

Removal of old apps before adding new ones [horizontal]
Downgrade of old admin roles before granting new ones [vertical]
Requires VP approval to exceed budget in either dimension

Implementation:

Two-dimensional budget check during mover provisioning:

"Adding 10 new apps would bring Jessica to 42 apps. Director ceiling is 35. Please remove 7 apps."

"Adding 3 new admin roles would bring Jessica to 9 admin roles. Director ceiling is 4. Please downgrade/remove 5 admin roles."

5. Automatic Post-Move Privilege Cleanup

After someone moves, monitor their usage patterns in BOTH dimensions:

30 days post-move:

Horizontal:

Identify apps with zero logins
Flag for removal review

Vertical:

Identify admin roles with zero admin actions
Flag for downgrade review

60 days post-move:

Horizontal:

Auto-revoke apps with zero usage
Notify user and manager

Vertical:

Auto-downgrade admin roles with zero admin activity
Notify user and manager

90 days post-move:

Full two-dimensional re-validation:

Compare actual access usage vs provisioned access
Compare actual admin usage vs elevated permissions
Remove/downgrade unused privileges in both dimensions

This catches access and privileges that seemed necessary but turned out not to be.

6. Mover-Specific Two-Dimensional Access Reviews

Standard access reviews happen quarterly. Movers should get a two-dimensional review immediately after any role change:

Trigger: 30 days after internal move

Review scope:

Horizontal:

All access (not just new additions)
Focus on old team/role tools
Compare to role baseline

Vertical:

All admin roles (not just new grants)
Focus on old team/role elevated permissions
Compare to privilege baseline for new role

Review questions:

Horizontal:

Does this access still align with their current role?
Are they using this access?
Should this be removed?

Vertical:

Does this admin role still align with their current responsibilities?
Are they performing admin actions with this privilege?
Should this be downgraded to standard user?

Don't wait 90 days. Review movers immediately in both dimensions.

7. Cross-System Privilege Visibility Dashboard

Build a dashboard that shows BOTH dimensions:

Per-user view:

Horizontal:

Current team: Product
Access to other teams:
- Backend Engineering: 8 apps
- Platform Engineering: 6 apps
- Frontend Engineering: 3 apps
Total cross-team access: 17 apps

Vertical:

Admin roles in current team tools: 3
Admin roles in other teams' tools: 5
Total admin roles: 8
Admin roles used in last 90 days: 2

Combined view:

Recommendation: Review and remove old team access + downgrade unused admin roles

Per-team view:

Horizontal:

Current team size: 12 people
Active team members with access: 12
Former team members with access: 8 (⚠️ flag)

Vertical:

Current team admins: 3 (appropriate)
Former team members with admin: 5 (⚠️ flag)

Combined view:

Recommendation: Review former members, revoke access AND admin rights

This makes two-dimensional privilege sprawl visible and actionable.

The Two-Dimensional Accumulation Equation

Here's the math that determines whether movers create privilege creep:

Horizontal Accumulation: (Apps Added Per Move) - (Apps Removed Per Move) × (Number of Moves)

Vertical Accumulation: (Admin Roles Added Per Move) - (Admin Roles Downgraded Per Move) × (Number of Moves)

Current state (most orgs):

Horizontal:

Apps added per move: 8–12
Apps removed per move: 0
Number of moves over 2 years: 3–4
Total accumulation: 24–48 excess apps

Vertical:

Admin roles added per move: 2–4
Admin roles downgraded per move: 0
Number of moves over 2 years: 3–4
Total accumulation: 6–16 excess admin roles

Target state (with two-dimensional governance):

Horizontal:

Apps added per move: 8–12
Apps removed per move: 6–10
Number of moves over 2 years: 3–4
Total accumulation: 6–8 excess apps

Vertical:

Admin roles added per move: 2–4
Admin roles downgraded per move: 2–3
Number of moves over 2 years: 3–4
Total accumulation: 0–4 excess admin roles

The difference between uncontrolled privilege creep and manageable governance is whether you remove access AND downgrade privileges during every move.

What Jessica's Journey Reveals

Jessica's story isn't about a security failure. It's about a governance gap in two dimensions.

Every access grant was approved. Every admin elevation was justified. Every role change was legitimate. Every move made sense at the time.

But the JML process treated each move as a two-dimensional additive event, not a privilege reconciliation event.

The result:

An employee with 2x the access they need (horizontal)
An employee with 5x the admin rights they need (vertical)
Spanning roles they no longer hold
Spanning teams they no longer work with
With elevated permissions in tools they no longer use
Creating maximum security and compliance exposure

The questions for your organization:

Horizontal dimension:

How many employees have moved roles in the past 2 years?
How many had access cleanup during those moves?
What's the average access count for movers vs static employees?
How many movers have cross-team access from old roles?

Vertical dimension:

How many employees gained admin rights during moves?
How many had admin downgrades during those moves?
What's the average admin role count for movers vs static employees?
How many movers have admin access in systems they no longer actively manage?

Both dimensions:

What's the correlation between access accumulation and privilege accumulation?
How many movers have both broad access AND elevated permissions?
What's the blast radius of your most privileged serial movers?

If you can't answer these questions, two-dimensional privilege creep is accumulating invisibly.

The Core Lesson: Movers Don't Reset, They Compound—In Both Directions

The most important insight about mover-driven privilege creep:

Movers accumulate faster than any other cohort because they never reset in either dimension.

Joiners:

Start fresh (baseline access)
Start appropriately (standard user)

Leavers:

Exit completely (full cleanup)
All privileges revoked

Movers:

Keep all old access AND all old admin rights
Add new access AND new admin rights
Compound horizontally AND vertically with every transition

Without mover-specific workflows that:

Subtract access before adding (horizontal)
Downgrade privileges before elevating (vertical)
Reconcile both dimensions during every role change

...every internal transition becomes a two-dimensional accumulation event.

Fix how you handle movers in both dimensions, and you eliminate the single biggest driver of privilege creep.

Ignore movers, and you'll spend the next decade doing quarterly cleanup projects that never solve the root cause.

Because next quarter, more people will move. And the two-dimensional accumulation will continue—broader access across more systems, deeper control within those systems, compounding with every role change until your most valuable employees become your highest-risk accounts.

‍