The Pattern Everyone Misses

Your quarterly access review surfaces two employees who started on the same day, three years ago:

Jessica Chen
Title: Director of Engineering
Role changes: 4 in 3 years
Current access: 52 applications
Role baseline: 24 applications
Excess access: 28 apps (117% over baseline)

Sarah Martinez
Title: Marketing Manager
Role changes: 0 in 3 years
Current access: 38 applications
Role baseline: 15 applications
Excess access: 23 apps (153% over baseline)

Same start date. Same company. Same access governance policies.

One person moved through four different roles. The other stayed in the same position for three years.

Both ended up with massive access sprawl.

This is the part most IT teams don't understand about access creep:

It doesn't matter if people move or stay put. Access accumulates either way.

The difference isn't whether sprawl happens. The difference is how it happens and whether your identity system can see it.

Jessica's access sprawl is visible. Every role change shows up in HRIS. Every promotion triggers a notification. Every team transfer creates a paper trail.

Sarah's access sprawl is invisible. Nothing changes in HRIS. No triggering events. No notifications. Just slow, silent accumulation over three years.

If your identity governance only responds to HRIS events, you're catching 40% of access sprawl while missing the other 60%.

In this article, we'll break down:

• Why movers and static employees both accumulate access
• The two sources of access sprawl (scheduled vs event-based)
• Why traditional JML only solves half the problem
• How the invisible 60% compounds without detection
• What it takes to govern both sources of access expansion

Jessica vs Sarah: The Opening Comparison

Before diving deep into their journeys, let's establish what makes each pattern distinct.

Jessica: The Mover (Scheduled-Based Accumulation)

Journey summary:

• Month 0: Started as Senior Software Engineer (12 apps)
• Month 6: Backend → Platform team (20 apps)
• Month 12: Engineer → Manager (27 apps)
• Month 18: Engineering → Product (39 apps)
• Month 24: Product Lead → Director (48 apps)
• Month 36: 52 apps total

Pattern characteristics:

• Accumulation triggered by HRIS events (role changes, promotions)
• Each move adds 8-12 apps
• Each move removes 0 apps
• Visible in HRIS: title changes, manager changes, department changes
• JML workflows could detect these (but don't remove old access)

Why it's visible:

• HRIS records every transition
• Creates potential governance hooks
• Managers know employee moved
• Auditors can trace role history

The problem: Even though her accumulation is visible, cleanup still doesn't happen. JML workflows add access during role changes but never subtract. For the detailed analysis of Jessica's two-dimensional privilege creep (horizontal access + vertical admin rights), see our article "The Mover's Journey: How Privilege Creep Compounds in Two Directions."

Sarah: The Static Employee (Event-Based Accumulation)

Journey summary:

• Month 0: Started as Marketing Manager (15 apps)
• Month 6: Q2 product launch project (20 apps)
• Month 12: Sales enablement + website migration (26 apps)
• Month 18: CS campaign + conference planning (34 apps)
• Month 24: Tool migrations + emergency access (40 apps)
• Month 36: 38 apps total (adjusted for truly dormant removals)

Pattern characteristics:

• Accumulation triggered by informal work events (projects, collaboration, emergencies)
• Each project/event adds 3-6 apps
• Each project end removes 0 apps
• Invisible in HRIS: same title, same manager, same team for entire 3 years
• JML workflows have no hooks to detect this

Why it's invisible:

• HRIS sees nothing (no role changes)
• No triggering events
• Managers don't track project-based access
• Auditors see "stable role" and assume baseline

The problem: Her accumulation compounds completely undetected. No HRIS events = no governance opportunities. This is the 60% of access sprawl that traditional JML cannot see.

This article focuses on Sarah's pattern—the invisible accumulation that affects 100% of your workforce, not just the 25-30% who move roles.

The Two Sources of Access Sprawl

Jessica and Sarah's journeys reveal that access sprawl comes from two fundamentally different sources, each requiring different governance approaches.

Source 1: Scheduled-Based Changes (The HRIS Knows)

What they are:

• Promotions
• Role changes
• Department changes
• Team changes
• Manager changes
• Location changes

Characteristics:

• Formal lifecycle events
• HRIS records them
• Create notification triggers
• Have clear start dates
• JML workflows can detect them

Jessica's accumulation from Source 1:

• 4 HRIS-visible role changes over 3 years
• Each triggered provisioning workflows (add access)
• None triggered deprovisioning workflows (remove old access)
• Result: 36 apps added through scheduled changes

Why they're detectable:

• HRIS sync can identify title/department/manager changes
• Triggers can fire on these events
• Provisioning workflows activate
• New manager gets notified
• IT sees the role transition

The governance hook exists (even if organizations aren't using it properly). This is the 40% of access sprawl that traditional JML is designed to handle—though it rarely handles it well.

Source 2: Event-Based Changes (Invisible Endings)

What they are:

• Project access
• Cross-functional collaboration
• Temporary elevated access
• Urgent/emergency access
• Coverage/backup access
• Learning/exploration access
• Tool migrations
• Process changes
• Agency/contractor collaboration

Characteristics:

• Informal work activities
• HRIS doesn't record them
• No notification triggers
• Have clear start dates but unclear end dates
• JML workflows cannot detect them

Sarah's accumulation from Source 2:

• 5 projects over 3 years
• 3 cross-team collaboration initiatives
• 2 emergency access grants
• 3 tool migrations
• Result: 23 apps added through event-based changes

Why they're invisible:

• No HRIS changes
• Same title, same manager, same team
• Access granted through direct requests, not workflows
• No formal project closure process
• Nobody owns "end of project" deprovisioning

No governance hook exists. This is the 60% of access sprawl that JML has no mechanism to address.

The Fundamental Asymmetry

For Source 1 (Scheduled-Based):

• Start date: ✅ Known (HRIS records role change)
• End date: ✅ Known (old role ends when new role starts)
• Governance opportunity: ✅ Could trigger cleanup (but usually doesn't)

For Source 2 (Event-Based):

• Start date: ✅ Known (access request submitted)
• End date: ❌ Unknown (projects end quietly, emergencies resolve invisibly)
• Governance opportunity: ❌ No trigger to hook cleanup logic to

Traditional JML governance is built for Source 1. It has no mechanism for Source 2.

Sarah's Journey: The Static Employee Deep Dive

Let's map Sarah's three-year accumulation in detail. Unlike Jessica's visible role changes, Sarah's access sprawl happens entirely below the HRIS radar.

Month 0: Clean Baseline

Sarah Martinez - Marketing Manager

Access granted:

• 15 apps: Slack, Gmail, HubSpot, Google Analytics, Canva, Airtable, Notion, Zoom, LinkedIn Ads, Google Ads, Typeform, Mailchimp, Hootsuite, Asana, Figma

Role-appropriate baseline: ✅

HRIS record: Marketing Manager, reports to VP Marketing

Sarah starts with clean, justified access. Everything makes sense.

Month 6: Q2 Product Launch Project

The context:

Product team is launching a major new feature. Marketing needs to coordinate messaging, understand product positioning, and access analytics to measure launch impact.

The request:

Product Manager to Sarah's manager: "Hey, we need Sarah on the Q2 launch. Can she join our Productboard workspace and get access to our analytics stack? She'll need to see feature usage and user behavior to craft messaging."

Sarah's manager: "Absolutely, makes sense for the launch."

Access granted:

• Productboard (product roadmap visibility)
• Amplitude (product analytics)
• Mixpanel (user behavior tracking)
• Pendo (in-app user insights)
• Intercom (customer communication, to see support questions about new feature)

Project timeline:

• Duration: 3 months (April–June)
• Launch: June 15
• Sarah's involvement ends: June 30

Access removal timeline:

• Expected: Early July (post-launch cleanup)
• Actual: Never

Why cleanup doesn't happen:

No project closure workflow:

• Product launch "completes" but no formal project closure process
• No access review triggered by project end
• Product Manager moves to next project, doesn't think about access

No ownership transfer:

• Product Manager isn't Sarah's manager, can't remove her access
• Sarah's manager doesn't know project ended
• IT doesn't know Sarah was temporary on Product team

"Might need it later" justification:

• "Sarah might help with future product launches"
• "She should stay connected to product metrics"
• "Better to have access than request it again later"

No expiration date:

• Access request had no end date
• No reminder to review after 30/60/90 days
• Temporary becomes permanent by default

Current state:

• Total apps: 20 (was 15)
• Excess: +5 apps from completed project
• HRIS visibility: ❌ None (same title, same manager)

What the system sees: Nothing. Sarah is still "Marketing Manager" in HRIS. Her access footprint expanded 33%, but no system detected it.

Month 12: Sales Enablement Initiative + Website Migration

Context 1: Sales Enablement Initiative

Sales team is closing several enterprise deals but needs better marketing collateral and deal-specific content. Sales leadership asks for dedicated marketing support.

The request:

Sales Enablement Manager: "We need Sarah embedded with sales for Q4. Can we add her to Salesforce so she can see deal context and pipeline? Also add her to Gong so she can listen to customer calls and understand pain points."

Director of Sales to Sarah's manager: "This will really help us close these deals."

Access granted:

• Salesforce (CRM for deal visibility)
• Gong (call recording/analysis for customer insights)
• Seismic (sales content management)

Initiative timeline:

• Duration: 6 weeks (November–December)
• Initiative ends: December 20
• Access removal: Never

Context 2: Website Platform Migration

Marketing is migrating the company website from WordPress to Webflow. Sarah is coordinating content migration and managing the transition.

The request:

Web Development Agency: "Sarah will need admin access to both platforms during migration—WordPress to export content, Webflow to rebuild pages."

Access granted:

• Webflow (new website platform)
• Contentful (new CMS for blog content)
• Optimizely (A/B testing on new site)

Migration timeline:

• Duration: 4 months (September–December)
• Migration completes: December 31
• WordPress sunset planned: "Eventually"
• Access removal: Never (for either platform)

Why cleanup doesn't happen:

Sales initiative:

• Initiative was informal, not tracked as formal project
• Sales Enablement Manager isn't Sarah's manager
• No coordination between Sales and Marketing on access cleanup
• "Sarah might help with future enterprise deals"

Website migration:

• Migration "completes" but old platform access retained
• "Some content still references WordPress"
• "We might need to pull old assets"
• No forced sunset date for old platform
• IT doesn't track which system is now primary

Current state:

• Total apps: 26 (was 20)
• New from sales: +3 apps
• New from migration: +3 apps (Webflow, Contentful, Optimizely)
• Retained from migration: WordPress (old platform kept)
• HRIS visibility: ❌ None (same title, same manager)

The tool migration trap: Company migrated from WordPress to Webflow. Everyone got Webflow access. Nobody lost WordPress access. Result: 2x the tools. Every migration doubles access instead of replacing it.

Month 18: Customer Success Campaign + Conference Planning

Context 1: Customer Retention Campaign

Customer Success team notices rising churn in mid-market segment. They partner with Marketing to build targeted retention campaigns.

The request:

CS Operations Manager: "We need marketing support for retention messaging. Can Sarah get access to our customer health data and support systems so she understands churn triggers?"

Access granted:

• Zendesk (customer support tickets for pain point analysis)
• ChurnZero (customer health scoring)
• Gainsight (CS platform with usage data)
• Pendo (to see where customers struggle in-product)

Campaign timeline:

• Duration: 8 weeks (February–March)
• Campaign ends: March 31
• Access removal: Never

Context 2: Annual User Conference

Company is hosting first annual user conference. Sarah is coordinating with external event agency and managing speaker logistics.

The request:

Events Agency: "We'll need Sarah in our project management tools and communication channels to coordinate."

Access granted:

• Eventbrite (conference registration platform)
• Swoogo (event management system)
• Cvent (venue and logistics management)
• Slack Connect (external channel with agency)

Conference timeline:

• Duration: 4 months (January–April)
• Conference date: April 15
• Sarah's involvement ends: April 20
• Access removal: Never

Why cleanup doesn't happen:

CS campaign:

• Campaign completes, nobody notifies Sarah's manager
• CS Operations doesn't own Sarah's access
• "We might run another retention campaign"
• No expiration dates on any access grants

Conference:

• Event ends, agency relationship continues for "next year"
• Slack Connect channel stays active (costs nothing)
• Event platforms "might be useful for future events"
• No formal project closure = no access review

Current state:

• Total apps: 34 (was 26)
• New from CS campaign: +4 apps
• New from conference: +4 apps
• HRIS visibility: ❌ None (same title, same manager)

Projects Sarah has completed but still has access to:

1. Q2 Product Launch (Month 6): Productboard, Amplitude, Mixpanel, Pendo, Intercom
2. Sales Enablement (Month 12): Salesforce, Gong, Seismic
3. CS Retention Campaign (Month 18): Zendesk, ChurnZero, Gainsight
4. Annual Conference (Month 18): Eventbrite, Swoogo, Cvent

Total apps from completed projects still active: 15 apps

Access removed: 0 apps

Month 24: Tool Consolidation + SEO Emergency

Context 1: Marketing Automation Migration

Company decides to migrate from HubSpot to Marketo. IT provisions Marketo for entire marketing team.

The migration:

IT announcement: "We're migrating from HubSpot to Marketo over the next 4 months. Marketing team will have access to both during transition."

Migration plan says:

• Month 1-4: Parallel access to both systems
• Month 5: HubSpot sunset and access removal

What actually happens:

• Month 1-4: Both systems active
• Month 5: Migration declared "complete," HubSpot access... stays active
• Month 12: Sarah still has both HubSpot AND Marketo

Also during this period:

Project management migration: Asana → Monday.com (keeps both)
Documentation migration: Confluence → Notion (keeps both)

Access granted:

• Marketo (new marketing automation)
• Monday.com (new project management)
• Notion team workspace (new documentation)

Access retained:

• HubSpot (old marketing automation)
• Asana (old project management)
• Confluence (old documentation)

Context 2: SEO Emergency

Website organic traffic drops 40% overnight. Google penalty detected. Need immediate intervention.

The emergency:

8:47 AM Slack: "@sarah urgent - traffic collapsed, need you on this NOW"

Engineering Manager: "Giving Sarah emergency access to production CMS and search tools. Fix first, paperwork later."

Access granted (emergency approval, no expiration):

• Google Search Console (diagnose penalty)
• Google Tag Manager (check tracking issues)
• Screaming Frog (technical SEO audit)

Crisis timeline:

• Duration: 48 hours
• Issue resolved: 2 days
• Emergency declared over: Day 3
• Access removal: Never

Why cleanup doesn't happen:

Tool migrations:

• Each migration adds new tool
• "Old data still in previous system"
• No forced sunset dates
• IT doesn't track which tools are actively used
• Every migration doubles tools instead of replacing

Emergency access:

• Crisis overrode normal approval workflows
• No expiration date set during emergency
• After crisis resolved, nobody remembers to revoke
• "She might need it for future SEO work"
• Emergency access becomes baseline access

Current state:

• Total apps: 40 (was 34)
• New from migrations: +3 apps (Marketo, Monday, Notion)
• Retained from migrations: +3 apps (HubSpot, Asana, Confluence)
• New from emergency: +3 apps
• Should have after migrations: 34 apps (old tools removed)
• Actually have: 40 apps (old + new for every migration)
• HRIS visibility: ❌ None (same title, same manager)

Month 30-36: Organic Drift

Small additions over final 6 months:

• Hotjar (heatmap analysis for website optimization)
• VWO (A/B testing platform)
• SEMrush (SEO/competitive analysis)

Removal of truly dormant apps:

During month 33, IT runs automated cleanup of apps with zero login in 12+ months:

• Removed: 5 apps that Sarah had literally never used (provisioned by mistake, one-time logins, etc.)

Final state:

• Total apps: 38 apps (43 minus 5 truly dormant)
• Role baseline: 15 apps
• Excess: 23 apps (153% over baseline)
• HRIS visibility: ❌ None (same title "Marketing Manager" for entire 3 years)

Sarah's Accumulation Breakdown

After 3 years with ZERO role changes, Sarah accumulated 23 excess apps from:

Completed projects (15 apps):

• Q2 Product Launch (Month 6): 5 apps
• Sales Enablement (Month 12): 3 apps
• CS Retention Campaign (Month 18): 4 apps
• Annual Conference (Month 18): 3 apps

Tool migrations that doubled instead of replaced (3 apps):

• HubSpot retained after Marketo migration
• Asana retained after Monday migration
• Confluence retained after Notion migration

Emergency access never revoked (3 apps):

• Google Search Console
• Google Tag Manager
• Screaming Frog

Organic cross-team collaboration (2 apps):

• Various informal requests over 3 years

Total: 23 apps added, 0 apps removed (until automated 12-month dormancy cleanup caught 5 obvious ones)

Each addition made sense at the time. Each was approved. Each served a legitimate business purpose.

But zero were removed when projects ended, emergencies resolved, or migrations completed.

This is Source 2 accumulation: death by a thousand justified cuts, all invisible to HRIS.

Why Traditional JML Only Solves Half the Problem

Your identity governance workflows are designed around three lifecycle events:

Joiner → Provision access
Mover → Adjust access
Leaver → Revoke access

This model assumes access changes happen because of employment status changes. It assumes HRIS is the source of truth.

But Source 2 access sprawl happens inside stable employment. Sarah's title never changed. Her manager never changed. Her department never changed.

JML workflows see nothing.

The JML Blind Spots for Source 2

1. No triggering events

JML workflows fire on:

• Hire date → onboard
• Termination date → offboard
• Role change → adjust

Sarah's project assignments don't show up in HRIS. JML workflows never activate.

2. No ownership transfer

When Jessica moves teams:

• Old manager is (theoretically) notified
• New manager is assigned
• Ownership of access review transfers

When Sarah joins a project:

• No manager notification
• Project owner isn't her manager
• Nobody owns cleanup when project ends

3. No end-date tracking

HRIS knows:

• Jessica's role as "Engineering Manager" ended on March 15
• Her role as "Product Engineering Lead" began on March 16

HRIS doesn't know:

• Sarah's "Q2 Product Launch" project ended on June 30
• Her "Sales Enablement" initiative ended on December 20
• Her "CS Campaign" ended on March 31

Project end dates aren't in HRIS. JML workflows can't fire.

4. No removal logic for static employees

When JML processes a mover:

• It adds new role access (usually)
• It doesn't remove old role access (also usually)
• But at least there's a workflow that could be fixed

When JML processes static employees:

• Nothing happens (no event detected)
• No workflow exists at all

Sarah's 5 completed projects? JML has no logic to detect or clean them up because JML doesn't know projects exist.

The Math: Source 1 vs Source 2 Accumulation

In a 500-person company over 3 years:

Source 1: Scheduled-Based (The HRIS Knows)

• 25-30% of employees move roles annually (~125 movers/year)
• Each move adds 8 apps, removes 0
• Annual accumulation: 1,000 apps from role changes
• 3-year total: 3,000 excess apps from movers

Source 2: Event-Based (Invisible Endings)

• 100% of employees participate in projects/collaboration (500 employees)
• Average 3-4 projects per employee per year
• Each project adds 3 apps, removes 0
• Annual accumulation: 4,500 apps from projects/collaboration/emergencies
• 3-year total: 13,500 excess apps from event-based work

Combined: 16,500 excess access grants

• 18% from Source 1 (role changes, movers)
• 82% from Source 2 (projects/collaboration, everyone)

If your JML only governs Source 1, you're missing 82% of access sprawl.

Why Source 2 Is Actually More Dangerous

Source 1 accumulation (movers like Jessica):

• Creates a paper trail (HRIS events)
• Shows up in organizational records
• Triggers could fire (even if they don't)
• Auditors can trace role history
• Managers know employees moved
• Excess access is at least discoverable

Source 2 accumulation (static employees like Sarah):

• No paper trail at all
• Invisible in organizational records
• No possible triggers (no events to hook to)
• Auditors see "same role for 3 years" and assume baseline
• Managers don't track cross-team project work
• Excess access is fundamentally undetectable without usage monitoring

Source 2 is silent accumulation. It compounds completely undetected until an audit or security incident exposes it.

The Invisible 60%: How Event-Based Access Compounds Undetected

Let's examine the specific patterns within Source 2 that make static employee accumulation so difficult to govern.

Pattern 1: The Project Access Lifecycle Gap

How projects work:

• Clear start: Project kickoff meeting, team formed, access requested
• Unclear end: Project "wraps up," team disperses, nobody owns cleanup

Access lifecycle during projects:

Project start:

• Access request submitted: "Add Sarah to Productboard for Q2 launch"
• Manager approves: "Makes sense for the project"
• IT provisions access
• Access granted within 24 hours

Project middle:

• Sarah actively uses access
• Contributes to project deliverables
• Collaborates with project team

Project end:

• Project completes (sometimes gradually, no clear "done" moment)
• Team moves to next priorities
• Sarah stops using project tools
• Access remains active indefinitely

The gap: Projects have clear start triggers (access request) but no end triggers (project closure doesn't cascade to access removal).

Why cleanup doesn't happen:

• No project management system integration with IAM
• Project "completion" is subjective
• Project owners don't manage Sarah's access (her manager does)
• Sarah's manager doesn't track which projects ended
• No automated "project closed → review access" workflow

Pattern 2: Cross-Team Collaboration Sprawl

How collaboration access accumulates:

Sarah needs to work with Product team:

• Product Manager adds her to 3-5 product tools
• Collaboration lasts 6 weeks
• Collaboration ends informally
• Product Manager moves on
• Sarah retains access indefinitely

Sarah helps Sales with enterprise deal:

• Sales Manager adds her to 2-3 sales tools
• Deal closes (or doesn't)
• Engagement ends
• Sales Manager moves to next deal
• Sarah retains sales tools indefinitely

Characteristics:

• Each cross-team interaction adds 2-5 apps
• Marketing Manager collaborates with 3-4 teams per year
• After 3 years: 10-15 apps from informal collaboration
• None removed when collaboration ends

Why cleanup doesn't happen:

• Collaboration isn't tracked formally
• No clear "end date" for helping another team
• Other team's manager isn't Sarah's manager
• Sarah's manager doesn't know she helped Product/Sales/CS
• "She might collaborate with them again"

Pattern 3: Emergency Access Ratchet

The emergency pattern:

Normal state:

• Sarah doesn't have production CMS access
• Makes sense—she creates content, doesn't need backend

Emergency strikes:

• Website traffic drops 40%
• Google penalty detected
• All hands on deck: "Get marketing involved NOW"
• Emergency override: "Grant access immediately, figure out process later"

Crisis resolution:

• Sarah helps diagnose issue
• Team fixes problem
• Crisis declared over
• Access remains active

The one-way ratchet:

• Emergency access grants click privilege level UP
• Post-emergency never clicks privilege level DOWN
• Each crisis leaves permanent access residue
• After 4-5 emergencies over 3 years: 4-5 permanent emergency access grants

Why cleanup doesn't happen:

• Crisis overrides normal approval processes
• No expiration date set during emergency
• After resolution, everyone forgets about access grant
• "Better to keep it in case another emergency happens"
• Emergency access becomes baseline access

Pattern 4: The Tool Migration Double-Down

The migration pattern:

Company announces: "We're migrating from HubSpot to Marketo"

Everyone expects:

• Transition period with both tools
• Migration completes
• Old tool sunsets
• Net result: Same number of tools

What actually happens:

• Month 1-4: Everyone gets Marketo, keeps HubSpot
• Month 5: "Migration complete" declared
• Month 6-12: "Some data still in HubSpot," access stays active
• Month 12+: Both tools still licensed, both still accessed
• Net result: 2x the tools

The compounding problem:

• 3 tool migrations in 3 years
• HubSpot → Marketo (keeps both)
• Asana → Monday (keeps both)
• Confluence → Notion (keeps both)
• Result: 6 tools where there should be 3

Why cleanup doesn't happen:

• No forced sunset dates
• "We might need old data"
• "Some teams still using old tool"
• IT doesn't enforce migration completion
• Nobody wants to be responsible for removing access and breaking something

Pattern 5: Coverage and Backup Access

The coverage pattern:

Sarah's colleague goes on maternity leave:

• "Sarah, can you cover Lisa's accounts while she's out?"
• Sarah gets access to Lisa's tools
• Lisa returns after 4 months
• Coverage ends
• Sarah retains Lisa's tools

The backup pattern:

Sarah becomes backup admin for marketing automation:

• "We need redundancy in case primary admin is unavailable"
• Sarah gets admin access "for backup purposes"
• Used once in 18 months during vacation
• Backup access remains permanently

Why cleanup doesn't happen:

• Coverage is temporary by nature, but access isn't
• No defined end date for "backup" access
• Original user returns, nobody revokes backup access
• "Better to have redundancy"

Detection Signals: Finding Invisible Sprawl

Source 2 sprawl requires different detection signals than Source 1. You can't rely on HRIS events, so you need behavioral and usage-based signals.

Signal 1: Static Role with High App Count

What to measure: Employees with stable roles but access count significantly above baseline

Identify employees where:

• Same title for 18+ months (no role changes in HRIS)
• Access count > 150% of peer baseline
• No HRIS events to explain accumulation

Sarah's signal:

• Title: Marketing Manager (unchanged for 36 months)
• Access: 38 apps
• Peer baseline: 15 apps
• Variance: 153% over baseline
• HRIS events: 0

Alert threshold:

• Role unchanged for 12+ months
• Access count 1.5x or higher than peers
• No promotions, transfers, or department changes to justify expansion

Why this works:

• Catches accumulation that happens "within" stable employment
• Identifies static employees who've accumulated through projects/collaboration
• Highlights exactly who JML can't see

Signal 2: Cross-Functional Tool Clusters

What to measure: Apps owned by departments the employee doesn't work in

Map each employee's app portfolio by owning department:

• Employee department: Marketing
• Apps owned by Marketing: 15
• Apps owned by Product: 5
• Apps owned by Sales: 3
• Apps owned by Engineering: 2
• Apps owned by Customer Success: 4

Sarah's signal:

• Primary department: Marketing (15 apps appropriate)
• Cross-functional: 14 apps from 4 other departments
• Total cross-functional: 48% of her portfolio

Alert threshold:

• 5+ apps from outside employee's primary department
• 3+ different departments represented in app portfolio
• No formal cross-functional role to justify breadth

Why this works:

• Project-based access shows up as cross-departmental tools
• Collaboration-driven sprawl creates multi-department footprints
• Static employees shouldn't have broad cross-functional access unless their role explicitly requires it

Signal 3: Dormant Project Tools

What to measure: Apps with usage patterns indicating completed projects

Identify apps with:

• Burst of concentrated activity 6-12 months ago
• Zero or minimal usage in last 90 days
• App is owned by team employee doesn't primarily work with

Sarah's signal:

Productboard:

• Heavy usage April-June 2023 (Q2 launch)
• Zero usage July 2023-present
• Owned by Product team
• Sarah is Marketing

Amplitude, Mixpanel, Pendo:

• Active during Q2 launch period
• Minimal usage after project completion
• Product analytics tools for Marketing employee

Alert threshold:

• 3+ apps with 90+ days of dormancy
• Previous usage pattern suggests temporary need (project-based)
• Apps from teams employee doesn't work with

Why this works:

• Completed projects leave behind dormant tool access
• Usage patterns reveal when projects ended
• Dormancy signals access is no longer needed

Signal 4: Tool Migration Overlap

What to measure: Employees with access to both old and new versions of migrated tools

Identify situations where:

• Company announced tool migration (Old Tool → New Tool)
• Migration marked "complete" 6+ months ago
• Employee has access to BOTH old and new tools
• Actively using only one (usually new tool)

Sarah's signal:

Marketing automation:

• Old: HubSpot (migration away completed 12 months ago)
• New: Marketo
• Has access to both: Yes
• Using HubSpot: 2 logins in 12 months
• Using Marketo: Daily

Project management:

• Old: Asana
• New: Monday.com
• Has access to both: Yes
• Active usage: Monday.com only

Alert threshold:

• 2+ tool pairs with functional overlap
• Migration completed 6+ months ago
• Usage clearly shifted to new tool
• Old tool access never revoked

Why this works:

• Tool migrations should replace, not add
• Overlap signals incomplete migration cleanup
• Easy to identify (known migration projects)
• Clear action (revoke old tool)

Signal 5: Emergency Access Residue

What to measure: Access granted under emergency approval, never reviewed post-crisis

Flag access where:

• Request flagged as "urgent" or "emergency"
• Approval chain compressed or bypassed
• Granted with temporary justification
• Still active 60+ days later

Sarah's signal:

SEO crisis access (Month 24):

• Grant reason: "Emergency - site traffic collapsed"
• Approval: Verbal, documented retroactively
• Expected duration: "2-3 days"
• Still active: 12 months later
• Usage: Initial burst, then 1-2 logins per quarter

Alert threshold:

• Access granted with emergency flag
• 60+ days since grant date
• Zero indication of permanent business need
• Minimal usage after initial crisis period

Why this works:

• Emergency grants bypass normal justification
• Temporary urgency becomes permanent access
• Crisis ends but access remains
• Easy to flag (metadata: "emergency request")

Signal 6: App Count Trend Analysis

What to measure: Employee's app count over time, looking for steady upward trend

Track per employee:

• App count at hire date
• App count every quarter
• Direction: increasing, stable, or decreasing
• Rate of increase if growing

Sarah's signal:

Pattern: Steady upward trend with occasional bursts, no sustained decreases until automated cleanup

Alert threshold:

• App count increased 40%+ since hire
• No role changes to justify increase
• Trend is unidirectional (only up, never down)

Why this works:

• Visualizes accumulation over time
• Shows compounding nature of sprawl
• Identifies employees whose access only grows
• Highlights need for periodic cleanup

The Fix: Governance for Event-Based Access Sprawl

Source 2 requires fundamentally different governance than Source 1. You can't rely on HRIS triggers. You need time-based and usage-based controls.

Strategy 1: Time-Based Access With Expiration Defaults

Current state:

• Access request: "Add Sarah to Productboard for Q2 launch"
• Duration: Unspecified
• Expiration: Never
• Result: Permanent access

Target state:

• Access request: "Add Sarah to Productboard for Q2 launch"
• Duration: Required field (30/60/90 days or custom date)
• Expiration: Auto-set based on duration
• Reminder: System notifies 7 days before expiration
• Result: Access auto-revokes unless actively extended

Implementation:

Access request form:

User: Sarah Martinez

App: Productboard

Reason: Q2 Product Launch collaboration

Duration: [Required dropdown]

  - 30 days

  - 60 days

  - 90 days

  - Custom end date: [date picker]

Justification: [Why this access is needed]

Expiration workflow:

• Day 1: Access granted
• Day 83 (7 days before expiration): Email to user and manager
  
  • "Sarah's Productboard access expires in 7 days. Still needed?"
  • Options: [Extend 30 days] [Extend 90 days] [Let expire]
• Day 90: If no extension requested, auto-revoke access
• Extension requires new justification

Categories that should ALWAYS have expiration:

• Project-based access
• Cross-team collaboration
• Emergency/urgent access
• Learning/exploration access
• Coverage/backup access
• Contractor/agency collaboration

No "indefinite" option for temporary access. If access is truly permanent, it goes through normal provisioning. If it's temporary, it expires.

Strategy 2: Usage-Based Cleanup for Dormant Access

The graduated response model:

Monitor access usage continuously and take progressive action based on dormancy.

30 days of dormancy:

• Action: Flag for review
• Notification: "Sarah, you haven't used Productboard in 30 days. Still needed?"
• User response: [Yes, still need it] [No, remove it]
• If "Yes": Set 60-day reminder
• If "No": Remove immediately
• If no response: Proceed to 60-day action

60 days of dormancy:

• Action: Notify manager
• Notification: "Sarah hasn't used Productboard in 60 days. Should we remove access?"
• Manager response: [Keep] [Remove]
• If "Keep": Requires justification, sets 30-day review
• If "Remove": Access revoked
• If no response: Proceed to 90-day action

90 days of dormancy:

• Action: Auto-revoke access
• Notification: "Sarah's Productboard access has been removed due to 90 days of inactivity"
• Can request reactivation if needed later

What counts as "usage":

• Login alone: Not sufficient
• Meaningful actions: Required (view, edit, create, comment, etc.)
• Different thresholds per app type:
  
  • Daily-use tools (Slack, email): Login = usage
  • Periodic tools (analytics, reporting): Must have meaningful actions
  • Admin tools: Must have admin-level actions

Implementation:

• Integrate with app audit logs
• Track last meaningful action per user per app
• Automated workflow based on dormancy thresholds
• User-friendly notifications (not threatening)
• Simple approve/remove decisions for managers

Strategy 3: Project Closure Triggers

Link access to project lifecycle:

When projects close, trigger access review for all project participants.

Project start:

• Project created in PM tool (Jira, Asana, Monday, etc.)
• Team members added to project
• Access requests tagged with Project ID
• "Grant access for Project: Q2 Product Launch"

Project end:

• Project status changed to "Closed" or "Complete"
• Automatic trigger fires
• System identifies all access granted for this project
• Manager receives bulk review request

Manager review prompt:

Project Closed: Q2 Product Launch

Closed on: June 30, 2023

The following access was granted for this project:

Sarah Martinez:

  - Productboard (granted Apr 1)

  - Amplitude (granted Apr 1)

  - Mixpanel (granted Apr 1)

  - Pendo (granted Apr 5)

  - Intercom (granted Apr 8)

Recommended action: Remove all project-specific access

[Remove all] [Review individually] [Keep (requires justification)]

Implementation:

• Integrate IAM with project management tools
• Tag all access requests with project/initiative identifier
• Webhook triggers when project status changes
• Bulk review UI for project-related access
• Default action: Remove unless explicitly retained

Projects that should trigger reviews:

• Product launches
• Marketing campaigns
• Engineering initiatives
• Sales enablement programs
• Customer success initiatives
• Any cross-functional project with dedicated access

Strategy 4: Tool Migration Sunset Policy

When migrating tools, force cleanup of old tool access:

Migration announcement:

• Old tool sunset date: 90 days from now
• New tool provisioned broadly
• Old tool marked "legacy" in app catalog
• Countdown timer visible to all users

30 days before sunset:

• Notification to all old tool users:
  
  • "HubSpot will be sunset on [date]"
  • "Access will be automatically revoked"
  • "Migrate remaining work to Marketo"
• Check migration status per user

Sunset date:

• Auto-revoke old tool access for ALL users
• No exceptions without VP approval
• VP approval requires specific justification and 30-day review

Implementation:

• Migrations MUST include sunset dates (no indefinite parallel access)
• Can't provision new tool broadly without scheduling old tool removal
• System enforces cleanup automatically
• Cultural shift: "Migration" means "replacement," not "addition"

This prevents:

• Tool sprawl from migrations
• "Some data is still there" permanent retention
• Indefinite parallel licensing costs
• Access accumulation from incomplete migrations

Strategy 5: Emergency Access Auto-Expiration

All emergency access includes automatic sunset:

Emergency grant:

• Access approved with "emergency" flag
• Default expiration: 48-72 hours
• Can be extended, but requires justification

Grant notification:

Emergency Access Granted

User: Sarah Martinez

App: Google Search Console

Reason: SEO crisis - traffic dropped 40%

Granted: Jan 15, 2024 8:47 AM

Expires: Jan 17, 2024 8:47 AM (48 hours)

This access will be automatically revoked unless extended.

After emergency resolves:

• Access auto-revokes at expiration
• Extension requires:
  
  • Reason why still needed
  • New expiration date (not indefinite)
  • Manager approval
• Every extension leaves audit trail

Implementation:

• Emergency access requests must specify expected duration
• System enforces expiration automatically
• No "permanent emergency access"
• Audit trail shows all emergency grants and their resolution

This prevents:

• Emergency access becoming baseline access
• Forgotten crisis grants remaining active indefinitely
• "Better to keep it just in case" accumulation

Strategy 6: Quarterly Static Employee Access Reviews

Different review approach for static employees:

Standard access reviews ask: "Does this person still need access to this system?"

Static employee reviews ask: "Does this person's current role justify this breadth of access?"

Review process:

Identify static employees:

• No role changes in past 12+ months
• Access count > baseline for role

Manager review with context:

Sarah Martinez - Marketing Manager (unchanged for 36 months)

Current access: 38 apps

Peer baseline: 15 apps

Variance: +23 apps (153% over baseline)

Cross-functional tools:

  Product team: Productboard, Amplitude, Mixpanel, Pendo, Intercom

  Sales team: Salesforce, Gong, Seismic

  CS team: Zendesk, ChurnZero, Gainsight

  Engineering: Google Search Console, Google Tag Manager

Dormant access (90+ days no usage):

  Productboard, Amplitude, Mixpanel, Eventbrite, Swoogo, Cvent

Recommended actions:

  [Remove dormant apps] [Review cross-functional access] [Approve all]

Manager questions to answer:

• Does Sarah's current role require Product team tools?
• Is she still working with Sales/CS teams?
• Should dormant apps be removed?
• Is this breadth appropriate for "Marketing Manager" role?

Result: Focus review on accumulation patterns, not just app-by-app validation

What Jessica and Sarah's Journeys Reveal

Two employees. Same start date. Same company. Same access governance policies.

One moved through four roles. One stayed in the same role.

Both accumulated massive access sprawl.

Jessica's sprawl was visible. Every role change created a paper trail. HRIS recorded it. Managers knew about it. Triggers could have fired. The problem: JML workflows added but didn't subtract. Cleanup logic didn't exist. [See our article "The Mover's Journey: How Privilege Creep Compounds in Two Directions" for the complete analysis of Jessica's accumulation.]

Sarah's sprawl was invisible. Projects came and went. Collaborations happened informally. Emergencies resolved quietly. HRIS saw nothing. The problem: No triggering events. No governance hooks. No cleanup mechanism at all.

The lesson isn't that one type of accumulation is worse than the other. The lesson is that both types exist, both compound over time, and both require governance.

Traditional JML only addresses Source 1 (scheduled-based changes from role transitions). It assumes access changes happen because of employment status changes tracked in HRIS.

But Source 2 (event-based changes from projects, collaboration, and informal work) represents the majority of access sprawl—and HRIS never sees it.

You cannot fix access sprawl by fixing JML alone.

You need:

• Scheduled-based governance for movers (Source 1): HRIS-triggered workflows that remove old access during role changes
• Event-based governance for all employees (Source 2): Time-based expiration, usage monitoring, project closure triggers
• Time-based cleanup that works regardless of employment status
• Behavioral monitoring that detects dormant access from any source

Fix Source 1, and you prevent mover accumulation (40% of the problem).
Fix Source 2, and you prevent static employee accumulation (60% of the problem).
Fix both, and you actually solve access sprawl.

Ignore Source 2, and you're governing the visible minority while the invisible majority compounds silently—until an audit or breach forces you to see what HRIS never could.