Your VP of Engineering asks a simple question during the quarterly security review:

"How many apps does the average employee have access to? And how many should they have?"

You're the IT Director. You pause. Because the honest answer requires math nobody's actually done.

Let's do it now:

Your organization:

• 500 employees (stable workforce)
• 100 SaaS applications
• 30% internal mobility (150 role changes, promotions, team moves per year)

The math:

Potential access combinations: 500 employees × 100 apps = 50,000 possible access grants

Actual access grants: Average 20 apps per employee = 10,000 active access grants

But here's the question nobody asks: How many of those 20 apps should each employee actually have?

If employees only had role-appropriate access:

• Average should be: 14 apps per employee (current role baseline)
• You actually have: 20 apps per employee
• The difference: 6 apps per person are access creep (43% excess access)
• Across 500 employees: 3,000 access grants that shouldn't exist

Where does the creep come from?

NOT from onboarding (you do this right):

• New hires get 14 apps for their role ✓
• Baseline provisioning is clean ✓

NOT from offboarding (separate problem):

• Termination deprovisioning is its own workflow
• Access creep happens during employment, not at exit

Creep comes from the messy middle - during employment itself.

But before you can clean up any access, you need to see it. Those 100 SaaS applications in your count? 

That's optimistic. Your actual app footprint includes federated apps IT manages, non-federated apps users provision themselves, unmanaged tools purchased by departments, and shadow IT nobody even knows exists. You can't remove access to applications you can't see.

What You'll Learn in This Article

In this article, we break down the mathematics of access creep and why manual cleanup is impossible:

The Two Sources of Accumulation

• Scheduled-based changes (HRIS knows, but cleanup doesn't happen): Promotions, team moves, department changes
• Event-based changes (invisible endings): Projects, temporary needs, urgent access

The Capacity Gap

• Why 0.5 FTE can't handle 1.54 FTE of work
• Where the hours actually go (provisioning vs. cleanup)
• Why accumulation compounds over years

Why You Can't Just Hire Another Person

• The information problem (you don't know when temporary needs end)
• The integration problem (no HRIS triggers for role changes)
• The scaling problem (complexity grows exponentially, not linearly)
• The effectiveness problem (manual cleanup achieves 20-40%, automation achieves 75-85%)

Sarah's 5-Year Journey

• How one employee goes from 14 apps (correct) to 51 apps (72% excess)
• Scheduled accumulation from 2 role changes (7 excess apps)
• Event-based accumulation from 30 temporary grants (30 excess apps)

Company-Wide Impact

• 500 employees × same pattern = 22,500 excess grants after 5 years
• $1.125M annual license waste
• 321% attack surface expansion
• Audit findings and compliance violations

The Solution: Visibility-First Automation

• Complete application visibility (see all 150-200 apps, not just 40-60 federated)
• Real-time HRIS triggers + automation rules (close the delay gap)
• Time-based access control (temporary access expires by default)
• Just-in-time privilege (elevated access only when needed)
• Usage-based safe cleanup (prove before you remove)
• Self-service access requests (reduce provisioning burden)

By the end, you'll understand why manual lifecycle cleanup is mathematically impossible and what specific capabilities solve both scheduled and event-based accumulation.

The Two Sources of Access Creep

Access accumulates during employment from two distinct sources. Understanding this distinction is critical because each requires different tracking and different automation.

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

What they are:

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

Why they're called "scheduled":

• These are tracked in HRIS systems
• They happen at known, documented times
• You KNOW they happened
• Your HRIS records the date, updates the org chart, notifies payroll

The problem:

• Employee gets promoted → New role baseline, keeps old access
• Employee changes teams → New team tools, keeps old team tools
• Employee moves departments → New department baseline, keeps old department access

Volume: 150 scheduled changes per year (30% of 500 employees)

• Promotions: 50/year
• Team changes: 60/year
• Department moves: 25/year
• Location changes: 15/year

What should happen:

1. HRIS triggers access review
2. Determine new baseline for new role/team/department/location
3. Remove old baseline that's no longer relevant
4. Keep only legitimate cross-over access

What actually happens:

1. HRIS records the change ✓
2. IT provisions new baseline (14 apps) ✓
3. No alert to IT system ✗
4. No access review triggered ✗
5. Old baseline (14 apps) remains ✗
6. Employee now has 28 apps (should have 14)

Example:

• Engineer → Engineering Manager (promotion in HRIS)
• Should have: Manager tools (14 apps)
• Actually has: Manager tools + old engineering tools (28 apps)
• Excess: 14 apps from previous role

Annual accumulation: 150 changes × 10 apps kept unnecessarily = 1,500 excess grants

The paradox: Your HRIS knows about every single one of these changes. These are documented, scheduled events. Yet cleanup still doesn't happen because there's no integration between HRIS and IT, and no capacity for manual reviews.

The visibility challenge: Even if HRIS triggered a review, you can only clean up access you can see. That Engineering Manager still has access to shadow IT tools from their IC days that never appeared in any IT system.

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

Why they're called "event-based":

• Unpredictable timing
• Based on business needs, not scheduled lifecycle
• Usually temporary in nature
• Hard to track when they END

The problem:

• Employee requests access for specific need
• Need ends (project completes, emergency resolved, coverage ends)
• Access remains because no one tracks when needs end

Volume: ~3,000 event-based requests per year across 500 employees

Breakdown:

• Project-based access: 1,000/year (33%)
• Cross-functional collaboration: 660/year (22%)
• Temporary elevated access: 420/year (14%)
• Urgent/emergency access: 330/year (11%)
• Coverage/backup access: 240/year (8%)
• Learning/exploration: 350/year (12%)

Average: 6 requests per employee per year

What should happen:

• Project ends → Remove project access
• Temporary period expires → Remove elevated access
• Coverage ends → Remove coverage tools
• Learning trial ends → Remove if not used

What actually happens:

• All requests granted
• Almost none removed when need ends
• No tracking of when projects complete
• No expiration dates for temporary access
• No follow-up process for any event-based access

Annual accumulation: ~3,000 access grants that become permanent

Why cleanup doesn't happen:

• No visibility into when events end
• Project completion doesn't trigger access review
• No expiration tracking for temporary access
• Event start is visible (request submitted), event end is invisible

The visibility challenge: Many of these requests are for non-federated apps IT doesn't manage. Users sign up directly, get added by colleagues, or are provisioned through departmental tools. These grant patterns are completely invisible to traditional IAM systems.

Combined Impact: Total Annual Accumulation

Scheduled-based changes (predictable):

• 150 changes per year
• Each keeps ~10 old apps unnecessarily
• Accumulation: 1,500 excess grants/year

Event-based changes (ad-hoc):

• 3,000 requests per year (6 per employee average)
• Almost none removed when need ends
• Accumulation: 3,000 excess grants/year

Total accumulation: 4,500 grants/year

Access removed during employment:

• Scheduled cleanup: 0 (no HRIS integration)
• Event-based cleanup: 0 (no tracking, no capacity)
• Total deprovisions: 0

Net accumulation: +4,500 access grants per year

Why This Distinction Matters

Scheduled changes should be the easiest to handle:

• HRIS already tracks promotions, role changes, team moves
• You KNOW they happened (documented in HR system)
• IT just needs to react to these known events
• Should trigger automatic access reviews
• Yet even these cause access creep

Event-based changes are inherently harder:

• No system tracks when projects complete
• No visibility into when temporary needs resolve
• No alerts when coverage periods end
• Event start is visible (request submitted), event end is invisible
• Much harder to track, but must be addressed

The sobering reality: Organizations can't even handle scheduled cleanup (which HRIS knows about!), let alone event-based cleanup (which requires tracking when invisible events end).

But here's what makes both impossible: You can only manage access you can see. Federated SSO apps appear in your IAM logs. But non-federated apps provisioned directly by users? Unmanaged tools purchased by departments? Shadow IT discovered through expense reports? These remain invisible until you have complete application visibility across your entire SaaS footprint.

The Capacity Gap: Why Cleanup Never Happens

Your IT team: 2 people handling identity management (among other duties)

Time available for access governance: ~25% of their time = 0.5 FTE

Time per access change:

Annual workload required:

Available capacity: 0.5 FTE

Gap: 1.54 FTE needed - 0.5 FTE available = 1.04 FTE short

You need 3× your current capacity to handle event-based provisions AND proper lifecycle cleanup.

Note: This assumes you can even see all the access to review. The actual capacity gap is larger once you account for discovering and cataloging non-federated and shadow IT applications before you can govern them.

Why You Can't Just Hire Another Person

The capacity gap is 1.04 FTE. The obvious solution: hire one more person. Problem solved, right?

Not quite. The capacity shortage is a symptom. The real problems are structural:

Problem 1: You Don't Have the Information to Do Cleanup

The core issue is access visibility. Without complete visibility, you don't even know who has access to what. Your IdP/SSO shows partial data—only the federated applications IT manages. Everything else is invisible:

• SSO tax: Apps employees could access through SSO but don't, so they sign up directly instead
• Non-federated apps: Tools that don't support SSO or weren't configured for it
• Department-managed apps: Marketing ops buys tools, HR purchases platforms, Finance provisions systems—all outside IT procurement
• Shadow IT: Employees discover tools, sign up with credit cards, spread across teams
• AI tools explosion: ChatGPT, Claude, Midjourney, Copilot—proliferating faster than IT can track

Your IdP shows 40-60 apps. Your actual footprint is 150-200+ apps. Manual cleanup can only address the visible subset, while 60-70% of accumulation happens in applications you can't see.

Visibility-first platforms address this through continuous discovery: SSO logs (federated apps), browser extensions (real-time usage detection), endpoint agents (installed applications), finance integrations (expense-based discovery), and direct API connections to 800+ SaaS applications. This reveals the complete footprint—not just what IT provisioned, but what employees actually use.

For event-based requests, even within visible apps, the information doesn't exist:

When you approved Sarah's access request 3 months ago for "Q3 sales enablement project," you recorded:

• What: Salesforce read access
• Why: Q3 sales enablement project
• When granted: June 15

What you didn't record:

• When does the project end?
• Who confirms project completion?
• What triggers the review?

3 months later, your new FTE asks:

• "Which of these 3,000 event-based grants from this year are still needed?"
• "How do I know when temporary needs resolved?"
• "Who do I ask about projects completed?"

They can't answer these questions because the data doesn't exist. They'd need to:

• Email 500 employees: "List all projects you worked on this year, tell me which are complete"
• Interview managers: "Which temporary access grants from Q2 are still needed?"
• Review 3,000 tickets: "Was this for a project? Is it done? Who knows?"

This isn't a capacity problem. It's a visibility and tracking problem. Even with unlimited time, you can't review access to applications you can't see, and you can't determine if visible access is still needed when the context for why it was granted and when the need ended was never captured.

Problem 2: Scheduled Cleanup Still Requires HRIS Integration

For the 150 scheduled changes per year, your new FTE would need to:

Manually check HRIS daily:

• Log into Workday, export employee data
• Compare yesterday's export to today's export
• Identify: promotions, department changes, team moves, location changes
• For each change: Pull employee's current access, compare to new role baseline, flag old-role tools, contact manager for review

Time required: 2 hours per day to manually audit HRIS changes = 0.25 FTE

Without HRIS integration, they're doing periodic audits, not event-triggered reviews. By the time they detect Sarah's promotion (could be days or weeks later), she's already been provisioned manually and old access forgotten.

With real-time HRIS integration: Promotion happens → Webhook fires instantly (not nightly sync) → Automated rules trigger → Playbook compares old PM baseline vs new Senior PM baseline → Manager receives alert within minutes: "Sarah promoted, review old PM tools: [list]" → Manager approves removals → Access deprovisioned before manual provisioning begins.

Modern identity platforms connect directly to HRIS systems (Workday, BambooHR, Rippling) and IdPs (Okta, Azure AD, Google Workspace) via real-time webhooks, not periodic syncs. When role changes happen, automation rules evaluate conditions (Department = Engineering AND Job Title contains "Manager") and execute playbooks that compare baselines, flag old access, alert managers, and auto-deprovision approved removals. The human just handles exceptions—15 minutes per change instead of 30 minutes.

Problem 3: It Doesn't Scale (And Gets Worse Faster Than You Think)

Access creep doesn't scale linearly—it compounds exponentially as your company grows.

Today (500 employees):

• Need: 1.54 FTE
• Have: 0.5 FTE
• Hire: +1 FTE
• Total: 1.5 FTE (barely enough)

Next year (750 employees, 50% headcount growth):

• Employees: 500 → 750 (+50%)
• But complexity grows faster:
  
  • New locations/branches: Different regional tools, local compliance apps
  • New teams: More department-specific applications
  • New compliance requirements: GDPR (EU expansion), SOC 2 (enterprise customers), industry regulations
  • App footprint: 100 → 180 apps (+80%, not +50%)
  • Scheduled changes: 150 → 270 (+80%, more reorganizations as company scales)
  • Event-based requests: 3,000 → 6,000 (+100%, more cross-functional projects)
• Need: 3.2 FTE (not 2.3 FTE)
• Have: 1.5 FTE
• Short: 1.7 FTE (hire nearly 2 more people?)

Year 3 (1,000 employees, another 33% headcount growth):

• Employees: 750 → 1,000 (+33%)
• Complexity compounds further:
  
  • Multi-location operations: 5+ offices, each with location-specific tools
  • Business units: Product lines become separate P&Ls with distinct app stacks
  • M&A activity: Acquired companies bring their own SaaS footprint
  • Regulatory expansion: More jurisdictions, more compliance frameworks
  • App footprint: 180 → 300 apps (+67%)
  • Scheduled changes: 270 → 450 (+67%, more internal mobility, more complex org)
  • Event-based requests: 6,000 → 11,000 (+83%, matrix org creates more cross-functional work)
• Need: 5.8 FTE (not 3.1 FTE)
• Have: 3.2 FTE (if you kept hiring)
• Short: 2.6 FTE (hire 3 more people?)

The compounding factors:

Organizational complexity:

• 500 employees: 1 office, 5 departments, simple structure
• 1,000 employees: 5 offices, 15 departments, matrix reporting, regional variations

Application proliferation:

• Apps grow faster than headcount: 2× employees = 3× applications
• Each location adds regional tools (local HR, regional CRM, compliance apps)
• Each new compliance framework adds 3-5 specialized tools
• Departments build their own tech stacks (Marketing ops, Sales ops, Engineering platform)

Access pattern complexity:

• More cross-functional projects (matrixed organization)
• More temporary access (covering multiple locations)
• More exceptions (regional compliance variations)
• More role variations (5 types of engineers become 15 specializations)

Event-based accumulation accelerates:

• 500 employees: 6 requests per employee per year = 3,000
• 1,000 employees: 11 requests per employee per year = 11,000 (not 6,000)
• Why? More projects, more cross-team work, more temporary coverage, more exploration

The manual approach requires exponentially more people:

• Year 1: +1 FTE (total: 1.5)
• Year 2: +1.7 FTE (total: 3.2)
• Year 3: +2.6 FTE (total: 5.8)

You're not hiring linearly. You're trying to staff against exponential complexity growth.

Automation scales without adding headcount:

• Year 1: Platform cost $60-80K
• Year 2: Same platform, handles 750 employees and 180 apps
• Year 3: Same platform, handles 1,000 employees and 300 apps
• Cost: Fixed. Scales with complexity automatically.

Problem 4: Manual Cleanup Achieves Lower Effectiveness

Even with 2 FTE dedicated full-time to lifecycle management:

Event-based cleanup effectiveness:

• Without expiration tracking: They review each of 3,000 grants, ask employees "still need this?", employees say "yes" (risk-averse), removal rate: 10-20%
• With expiration tracking: Temporary access expires by default, removal rate: 85-90%

Scheduled cleanup effectiveness:

• Without usage data: Manager asked "Does Sarah still need these 4 old PM tools?", manager guesses based on memory, removal rate: 30-40%
• With usage data: Manager shown "Sarah hasn't logged into these 4 apps in 60 days," removal rate: 70-80%

The information quality determines cleanup effectiveness, not just capacity.

Problem 5: Cost Comparison Gets Worse at Scale

Hiring approach:

Year 1: Hire 1 FTE = $120K loaded cost
Year 2: Company grows 50%, hire another 0.8 FTE = $96K
Year 3: Company grows to 1,000 employees, hire another 0.6 FTE = $72K

3-year cost: $288K

Cleanup effectiveness: 20-40% (limited by information gaps)

Automation approach:

Year 1: Platform cost = $60-80K
Year 2: Same platform, no additional cost
Year 3: Same platform, scales to 1,000 employees

3-year cost: $180-240K

Cleanup effectiveness: 75-85% (information captured automatically)

Problem 6: The Real Issue Is Visibility + Tracking

What the new hire would need to succeed:

1. Complete application visibility
   
   • See all federated apps (current SSO)
   • See all non-federated apps (direct sign-ups)
   • See all shadow IT (undiscovered tools)
   • See usage data (who's actually logging in)
2. Expiration tracking for event-based access
   
   • Capture: "Why was this granted? For what project? Until when?"
   • Track: When do temporary needs end?
   • Alert: When should we review?
3. HRIS integration for scheduled changes
   
   • Real-time notifications when roles change
   • Automated baseline comparison
   • Manager review workflows
4. Usage analytics for safe cleanup
   
   • Track: Last login date per app per user
   • Identify: Dormant access (30/60/90 day thresholds)
   • Prove: "Zero usage for 90 days" before removal

Without these systems, your new hire spends time trying to reconstruct information that was never captured. They're not doing cleanup—they're doing detective work.

With these systems, your existing 0.5 FTE can handle it because the systems provide the information and execute the routine work.

The Uncomfortable Truth

Hiring another person doesn't solve:

• Lack of visibility into non-federated and shadow IT
• Missing context on why event-based access was granted and when needs end
• No HRIS integration triggering reviews when roles change
• No usage data to prove which access is dormant
• Manual review relying on memory and guessing instead of data

You're not short of capacity. You're short systems.

The 1.04 FTE gap assumes you have all the information needed to do cleanup. You don't. Even with 2 FTE dedicated full-time, cleanup effectiveness would be 20-40% because the information required doesn't exist in manual processes.

Automation doesn't just provide capacity—it provides the tracking, visibility, and data quality that makes cleanup possible in the first place.

What Actually Happens with 0.5 FTE

Priority 1: Event-based provisions (0.75 FTE needed)

• Business is waiting, projects blocked
• "Need this to close the deal"
• "Need access for this project"
• "Production down, need access NOW"
• Gets done through overtime (visible requests, urgent pressure)

The provisioning burden itself could be reduced through self-service access request systems. Instead of ITSM tickets that require manual investigation ("What app? What access level? Who approves? What's the business justification?"), an app-store-style catalog lets users browse available applications, select needed access, and routes requests through pre-configured approval workflows. IT handles exceptions rather than every individual request, reducing event-based provisioning from 0.75 FTE to 0.15 FTE. But this only addresses half the problem—provisioning gets easier, cleanup still doesn't happen.

Priority 2: Scheduled-based cleanup (0.04 FTE needed)

• HRIS shows promotion/role change
• Should trigger access review
• Never happens (no integration between HRIS and IT)

Priority 3: Event-based cleanup (0.75 FTE needed)

• No visibility when events end
• Who tracks when projects complete?
• Who remembers temporary access was granted 3 months ago?
• Never happens (invisible, no tracking)

Actual work completed:

• Event-based provisions: 100% through overtime (0.75 FTE forced through 0.5 FTE)
• Scheduled-based cleanup: 0% (0 FTE)
• Event-based cleanup: 0% (0 FTE)

Result:

• Event-based provisions: 3,000 per year
• Scheduled changes (excess kept): 1,500 per year
• Cleanup completed: 0 per year
• Net accumulation: 4,500 access grants per year

A Single Employee's Journey: How Access Accumulates

Let's trace Sarah through 5 years of employment to see how both types of accumulation compound.

Year 0: Onboarding (Clean)

Day 1:

• Hired as Product Manager
• Provisioned with PM baseline: 14 apps
• Total: 14 apps ✓

Year 1: Event-Based Accumulation

Starting with: 14 apps

6 event-based requests during the year:

1. Month 2: Sales enablement project needs Salesforce read access (+1)
2. Month 3: Analytics team collaboration needs Tableau (+1)
3. Month 4: Customer escalation requires support tool (+1, removed after 2 days? No)
4. Month 6: Market research project needs survey tool (+1)
5. Month 9: Deal closing needs contract management tool (+1)
6. Month 11: Data migration requires elevated permissions (+1, task completes in 1 week? Access remains)

End of Year 1: 20 apps (14 baseline + 6 event-based)

Year 2: Continued Event-Based Accumulation

Starting with: 20 apps

6 more event-based requests:

• 2 new project access grants
• 2 cross-functional collaborations
• 1 temporary elevated access (never removed)
• 1 coverage access (never removed)

End of Year 2: 26 apps (14 baseline + 12 event-based)

Year 3: Scheduled Change (Promotion) + Event-Based

Promoted to Senior Product Manager (SCHEDULED CHANGE in HRIS)

What should happen:

• HRIS triggers access review
• Get new Senior PM baseline: 14 apps (some overlap with PM, some new)
• Remove old PM-specific tools that aren't in Senior PM role
• Net result: Still ~14 apps for current role

What actually happens:

• HRIS shows promotion ✓
• IT doesn't connect it to access review ✗
• Get new Senior PM tools: 4 unique apps
• Keep all 26 old apps (no cleanup triggered)
• Now has: 30 apps (should have 14)

Continuing Year 3 - 6 more event-based requests:

End of Year 3: 36 apps (should be 14, has 36)

• Current Senior PM baseline needed: 14 apps
• Old PM-specific tools: 4 apps (should be removed)
• Event-based accumulation: 18 apps (12 pre-promotion + 6 this year)

Year 4: Another Scheduled Change (Team Move) + Event-Based

Moved to different product team (SCHEDULED CHANGE in HRIS)

What should happen:

• Get new team-specific tools: 3 unique apps
• Remove old team-specific tools: 3 apps
• Net result: Still ~14-15 apps for current role

What actually happens:

• Get new team tools: 3 apps
• Keep all old team tools: 3 apps that should be removed
• Now has: 39 apps before year's event-based requests

Continuing Year 4 - 6 more event-based requests:

End of Year 4: 45 apps

• Scheduled excess: 7 apps (4 from promotion + 3 from team change)
• Event-based accumulation: 24 apps

Year 5: The Compounding Effect

Continuing Year 5 - 6 more event-based requests:

End of Year 5: 51 apps

How many should Sarah have? 14 apps (her current role)

How many does Sarah actually have? 51 apps

Excess: 37 apps (72% excess access)

Breakdown of 51 apps:

• Current role baseline: 14 apps (appropriate) ✓
• Scheduled excess (old role/team tools): 7 apps ✗
• Event-based accumulation: 30 apps ✗
• Excess: 37 apps that shouldn't exist

The visibility problem in Sarah's accumulation: Of those 51 apps, how many does IT actually know about? The federated SSO apps appear in logs. But the non-federated tools Sarah signed up for directly? The departmental apps added by colleagues? The shadow IT discovered only when she expenses them? IT can't deprovision access they don't know exists.

Company-Wide Impact: The Compounding Math

500 Employees × Same Pattern

Starting state (all employees onboarded correctly):

• 500 employees × 14 apps = 7,000 access grants
• Baseline: Clean

Year 1 accumulation:

• Scheduled changes: 150 × 10 kept = 1,500 grants
• Event-based requests: 3,000 grants
• Total accumulation: 4,500 grants
• Ending state: 11,500 grants (should be 7,000)
• Average: 23 apps per person (should be 14)

Year 2 accumulation:

• Starting: 11,500 grants
• Annual accumulation: +4,500 grants
• Ending state: 16,000 grants (should be 7,000)
• Average: 32 apps per person (should be 14)

Year 5 accumulation:

• Accumulated over 5 years: ~22,500 excess grants
• Total: 29,500 grants (should be 7,000)
• Average: 59 apps per person (should be 14)
• Excess: 76% of all access grants are unnecessary

The visibility multiplier: These numbers assume you can actually see all 100 applications. Most organizations discover they have 150-200+ applications once they implement comprehensive discovery across federated, non-federated, unmanaged, and shadow IT. The actual accumulation is likely 50-100% higher than calculated.

The Hidden Cost: What This Actually Costs

License Waste

Year 1:

• Excess grants: 4,500
• Average license: $50/app/year
• Cost: $225K/year

Year 5:

• Excess grants: 22,500
• Cost: $1.125M/year

Security Risk

Attack surface expansion:

• Baseline (proper): 7,000 access paths
• Year 1 actual: 11,500 access paths (+64%)
• Year 5 actual: 29,500 access paths (+321%)

Insider threat exposure:

• Employee changes roles but keeps all old access
• Now has current role access + previous role access + project accumulation
• If compromised: Excessive lateral movement capability

Shadow IT risk amplification: The access you can't see poses the greatest security risk. Non-federated applications with no SSO enforcement, unmanaged tools with weak authentication, departmental purchases with no security review—these accumulate alongside visible access and often contain sensitive data.

Compliance Violations

Audit finding:

• "Employee has 59 apps, role requires 14 apps"
• "45 apps cannot be justified by current role"
• "No evidence of periodic access review during employment"
• "Scheduled changes show no access cleanup process"

Remediation cost: $500K+ per audit finding

What Automated Lifecycle Management Looks Like

Manual lifecycle cleanup is impossible for both scheduled and event-based changes. The capacity gap makes it mathematically unfeasible. But automation only works if you can see what you're automating.

The foundation: Complete application visibility

Before you can automate cleanup, you need comprehensive discovery across:

• Federated applications: SSO-managed apps in your IAM system
• Non-federated applications: Direct user sign-ups, no SSO
• Unmanaged tools: Departmental purchases outside IT procurement
• Shadow IT: Discovered through expense analysis, browser extensions, endpoint agents

Without this foundation, your automation only governs the subset of applications IT already manages—typically 40-60% of actual SaaS footprint.

Automated Scheduled-Based Cleanup: Playbooks Triggered by HRIS

How it works:

Step 1: HRIS integration detects change

• HRIS event: "Sarah promoted from PM to Senior PM"
• Webhook triggers automated playbook
• Playbook initiates role-based access review workflow

Step 2: Playbook compares baselines

• Current access: All 30 apps Sarah has (across federated, non-federated, shadow IT)
• Old role baseline: 14 PM apps
• New role baseline: 14 Senior PM apps
• System identifies: 10 overlap, 4 PM-only, 4 Senior-PM-only

Step 3: Playbook flags for review

• PM-only apps (4): Auto-flag as "likely removable"
• Overlapping apps (10): Auto-keep
• Senior-PM-only apps (4): Auto-provision
• Accumulated access (12 apps from projects/temporary): Flag all for manager review

Step 4: Manager review portal

• Email to manager: "Sarah promoted, review access"
• Portal shows complete access picture (not just federated apps)
• Manager decides: Keep with justification, or Remove

Step 5: Playbook executes decisions

• Approved removals: Auto-deprovision across federated and non-federated apps
• Approved keeps: Document justification, set 6-month review reminder
• New baseline: Auto-provision

Result:

• 150 scheduled changes per year
• Playbook handles comparison, flagging, alerting automatically
• Manager review time: 15 minutes (down from 60)
• 70% of old access auto-removed
• Annual accumulation: 450 instead of 1,500

Why playbooks work for scheduled changes: HRIS events are structured, predictable, and trigger-able. Playbooks can encode the review logic once and apply it consistently to every promotion, team change, or department move.

Automated Event-Based Cleanup: Time-Based Access Control

Event-based cleanup requires a fundamentally different approach: time-based access control that treats temporary access as temporary by default.

Just-In-Time Access for Projects

Request: "Need Salesforce access for Q3 sales enablement project"

Automated handling:

• Grant with expiration: Auto-set 90 days based on project timeline
• Zero standing privilege: Access provisioned only when needed, auto-revoked when period ends
• 7 days before expiration: Alert to user "Project access expires in 7 days, extend?"
• User response: Justify continued need → Manager approval → Extend
• No response: Auto-revoke on expiration date

Result:

• 1,000 project grants per year
• 90% auto-revoked when period ends
• Annual accumulation: 100 instead of 1,000

Just-In-Time Privilege Escalation

Request: "Need admin access to complete data migration"

Automated handling:

• Grant elevated access with time limit: 24-48 hours
• Zero standing privilege: Admin access exists only during task window
• Usage tracking: Monitor if actually used
• Auto-revoke: Elevated access removed when time expires
• Permanent need: Requires full approval cycle, not temporary JIT

Result:

• 420 temporary privilege grants per year
• 95% auto-revoked when time expires
• Standing admin privileges reduced by 80%
• Annual accumulation: 21 instead of 420

Time-Based Access for Coverage

Request: "Covering Sarah's PM responsibilities for 30 days"

Automated handling:

• Grant with coverage period: 30 days auto-set
• Link to calendar: Integrate with OOO/PTO systems
• Auto-revoke: When coverage period ends
• Extension: Requires justification if coverage extends

Result:

• 240 coverage grants per year
• 85% auto-revoked when coverage ends
• Annual accumulation: 36 instead of 240

Time-Based Access for Learning/Trials

Request: "Want to explore Tableau for potential use"

Automated handling:

• Grant trial access: 60-day evaluation period
• Usage tracking: Monitor actual usage during trial
• Decision point at day 45:
  
  • Used regularly (5+ sessions): Convert to permanent, assign license cost
  • Unused: Auto-revoke at day 60
  • Sporadic: 30-day extension to determine fit

Result:

• 350 exploration grants per year
• 70% either confirmed as needed or auto-revoked if unused
• Annual accumulation: 105 instead of 350

Why Time-Based Access Control Works for Event-Based Changes

The core principle: Temporary access should expire by default, not remain forever.

Traditional approach:

• Grant access when requested
• Hope someone remembers to remove it when no longer needed
• Result: All temporary access becomes permanent

Time-based access control:

• Grant access with expiration date
• Auto-revoke when period ends
• Extension requires justification
• Result: Temporary access actually expires

Critical enabler: Complete visibility

Time-based access control only works if you can:

• Set expiration dates across federated AND non-federated apps
• Track usage across all applications (not just SSO logs)
• Auto-revoke across your entire SaaS footprint (not just IAM-managed apps)

Without comprehensive application visibility, time-based controls only apply to the subset of apps IT manages, leaving 40-60% of temporary access to accumulate unchecked.

The Automated Model: Capacity Comparison

With automation:

• Required capacity: 0.24 FTE
• Available capacity: 0.5 FTE
• Excess capacity: 0.26 FTE (can focus on strategic work)

Cleanup effectiveness:

• Manual: 0% (no capacity)
• Automated with playbooks + time-based controls: 80% (3,600 of 4,500 excess grants prevented annually)

But only if you have the visibility foundation: These efficiency gains assume comprehensive application discovery. Automation without visibility just means you're efficiently managing 40-60% of your SaaS footprint while the rest accumulates unchecked.

The Core Reality: Two Types, Zero Cleanup, Built on Blind Spots

The traditional view of access creep:

• ✗ "People get over-provisioned at onboarding"
• ✗ "Offboarding is incomplete"

The actual problem:

• ✓ Onboarding gives correct baseline (14 apps)
• ✓ Offboarding is a separate termination workflow
• ✓ Accumulation happens during employment from TWO sources
• ✓ But you can only clean up what you can see

Type 1: Scheduled-based (Should be easiest)

• Promotions, role changes, team moves
• HRIS already tracks these events
• 150 changes per year × 10 apps kept = 1,500 excess grants
• Solution: Playbooks that trigger on HRIS events and automate review workflows
• Paradox: Even documented events HRIS knows about don't trigger cleanup without integration

Type 2: Event-based (Inherently harder)

• Projects, urgent access, temporary needs
• Unpredictable timing, invisible endings
• 3,000 requests per year, all granted, none removed
• Solution: Time-based access control with auto-revocation and zero standing privilege
• Challenge: No tracking of when events end without expiration dates

Type 0: Visibility (The prerequisite for both)

• Federated apps: In your IAM system
• Non-federated apps: Direct sign-ups, no SSO
• Unmanaged tools: Department purchases
• Shadow IT: Discovered through expense/endpoint analysis
• Foundation: Can't automate cleanup for apps you can't see

Combined effect:

• Total accumulation: 4,500 grants per year
• After 5 years: 59 apps per person (should be 14)
• Need: 1.54 FTE for provisions + cleanup
• Have: 0.5 FTE
• Cleanup happens: Never

The uncomfortable truth: Your team provisions perfectly. They grant every legitimate business request. They're responsive, helpful, and overworked at 150% capacity just handling provisions. They can't clean up scheduled changes (no HRIS playbooks) or event-based changes (no time-based controls). And even if they had both, they can only act on applications they can see—which is typically less than half the actual SaaS footprint.

The three-part solution:

1. Complete application visibility across federated, non-federated, unmanaged, and shadow IT
2. Automated playbooks for scheduled changes (so HRIS events trigger access reviews)
3. Time-based access control for event-based changes (so temporary access actually expires)

Manual lifecycle cleanup is mathematically impossible. Automated cleanup for both scheduled and event-based changes is the only solution. But automation without visibility just means efficiently managing the apps you know about while the invisible majority continues to accumulate.

How to Solve This: Visibility-First Automation

The math shows you need three capabilities working together: complete application visibility, automated playbooks for scheduled changes, and time-based access control for event-based changes. Here's how these work in practice.

The Foundation: Complete Application Visibility

You can't remove access to applications you can't see. When Sarah gets promoted from PM to Senior PM, cleanup can only address the apps IT knows about. Traditional IGA assumes you provide the application catalog upfront—fine for enterprises with mature IT operations, problematic for mid-market companies where users sign up for SaaS directly, departments purchase tools outside procurement, and non-federated apps exist alongside SSO.

Visibility-first approach: Discover applications continuously through multiple sources:

• SSO logs: Federated apps in your IAM system
• Browser extensions: Real-time usage detection as employees work
• Endpoint agents: Installed applications and cloud service access
• Finance integrations: Expense-based discovery (credit card transactions, invoice data)
• Direct API connections: 800+ SaaS application integrations for detailed access data

This reveals your actual SaaS footprint—typically 150-200+ apps instead of the 40-60 federated apps IT thinks exist.

Why this matters: When Sarah's promotion triggers a review, the playbook can flag all 22 apps she should lose (14 federated + 8 non-federated discovered via usage tracking), not just the 14 IT manages. Without complete visibility, 40-60% of accumulation continues unchecked because it happens in apps you don't know exist.

Scheduled Changes: Real-Time HRIS Triggers + Automated Rules

The timing problem: Most lifecycle management tools sync with HRIS periodically (hourly at best, daily in practice). Sarah's 9:00 AM promotion isn't detected until midnight. By then, she's submitted manual access requests and IT has provisioned her new baseline. Old access never gets flagged because the delay created a window where manual provisioning finished first.

Real-time solution: HRIS webhooks fire instantly when promotions happen. Sarah promoted at 9:00 AM → Webhook triggers at 9:01 AM → Automation rule evaluates conditions (Department = Product AND Job Title changed from "PM" to "Senior PM") → Playbook executes at 9:02 AM → Manager receives alert: "Sarah promoted, review old PM tools: [list]" → Manager approves removals → Old access deprovisioned before manual provisioning begins.

The automation rules logic:

Modern platforms use WHEN-IF-THEN rules:

• WHEN: User's Designation Changes (triggered by HRIS webhook)
• IF: Previous Job Title = "Product Manager" AND New Job Title contains "Senior"
• THEN: Execute playbook: Compare old PM baseline vs new Senior PM baseline → Identify 10 apps both roles need (auto-keep) → Flag 4 PM-only apps (likely removable) → Alert manager for review → Provision new Senior PM tools → Execute approved removals → Document decisions with 6-month review reminder

Result for 150 scheduled changes per year:

• Manual review: 60 min each = 150 hours
• Automated: 15 min each = 37.5 hours
• 75% less effort, 70% of old access removed

Progressive implementation: Start with promotions (50/year, highest volume), validate, expand to department changes, then team changes, then location changes. You don't automate everything at once—test, validate, expand incrementally.

Event-Based Changes: Time-Based Access Control with Auto-Revocation

Event-based cleanup is harder because you don't know when projects complete or temporary needs resolve. Time-based access control shifts the burden: temporary access expires by default unless extended.

How time-based access control works: Grant access with expiration dates built into the provisioning. Platforms supporting this capability let you set expiration timers that auto-revoke access:

For project access:

• User requests: "Need Salesforce for Q3 sales enablement project"
• System grants: Salesforce access + 90-day expiration timer
• Day 83: Alert user "Access expires in 7 days, extend if still needed"
• Day 90: Auto-revoke (unless user justified extension and manager approved)

For temporary elevated access:

• User requests: "Need admin access for production deployment"
• System grants: Admin access + 48-hour expiration timer
• Hour 48: Auto-revoke admin, restore baseline access
• If deployment runs long: User must request extension with new justification

For coverage/backup:

• Manager sets: "Sarah covering Mike's role for 30 days"
• System grants: Mike's tool access + 30-day expiration linked to coverage end date
• Day 30: Auto-revoke coverage access
• If coverage extends: Manager extends with updated end date

Extension requires explicit approval, not passive neglect. This inverts the default: access expires automatically unless someone justifies continuation.

Result for 3,000 event-based requests per year:

• Projects (1,000): 90% auto-revoked → 100 permanent instead of 1,000
• Temporary admin (420): 95% auto-revoked → 21 permanent instead of 420
• Coverage (240): 85% auto-revoked → 36 permanent instead of 240
• Total event-based accumulation: 262 instead of 3,000 (91% reduction)

Just-in-time (JIT) privilege for elevated access: For roles requiring temporary privilege escalation (on-call engineers, deployment admins, emergency access), JIT access provisions elevated privileges only during the needed window and auto-revokes when complete.

JIT implementation example:

• Engineer enters on-call rotation → Status changes to "Oncall = Yes"
• Automation triggers: Provision PagerDuty escalation + production monitoring + elevated database access
• Engineer has necessary privileges during on-call window (typically 1 week)
• On-call rotation ends → Status changes to "Oncall = No"
• Automation triggers: Revoke PagerDuty + remove elevated access + flag manually granted permissions for review

Zero standing privilege: Elevated access exists only when needed, auto-revokes when rotation ends. This prevents permanent admin access accumulation (the "we granted admin for this one deployment 2 years ago" problem) while ensuring engineers have necessary privileges during critical windows.

Conservative Approach: Usage-Based Safe Cleanup

Even if you're hesitant to remove access, usage tracking provides proof. Instead of removing all old-role access after promotions, flag only unused access:

After Sarah's promotion:

• Day 30: Identify apps with zero logins since promotion
• Alert manager: "Sarah hasn't used these 6 apps in 30 days, remove?"
• Manager reviews: Safe to remove (proven unused) vs Keep (sporadic use)
• Execute approved removals with documentation: "Removed [app], zero usage for 30 days post-promotion"

Thresholds:

• 30 days: Very safe, catches obviously unused apps (60-70% of scheduled accumulation prevented)
• 60 days: Catches sporadic tools no longer needed
• 90 days: Most conservative, only truly dormant access (40-50% prevented)

Why this works: All removals backed by usage proof, not assumptions. Creates cross-functional alignment:

• HR: Role changes don't disrupt employees (usage data proves access wasn't needed)
• Security: Excess access removed with audit-ready justification
• Finance: License reclamation backed by proof of non-usage

Self-Service Access Requests: Reducing Provisioning Burden

The 0.75 FTE spent on event-based provisioning can be dramatically reduced through self-service access request systems. Traditional ITSM ticket-based provisioning requires IT to manually investigate every request:

• "What app are they requesting?"
• "What access level do they need?"
• "Who needs to approve this?"
• "What's the business justification?"
• "How do I provision this specific app?"

App store-style catalogs solve this: Users browse available applications, see descriptions and access tiers, select what they need, and requests automatically route through pre-configured approval workflows. IT handles exceptions rather than every individual request.

Key capabilities:

• Application catalog: Searchable directory of all available apps with descriptions, access tiers (Viewer, Editor, Admin), and typical use cases
• Self-service requests: Users select apps, system routes to appropriate approver based on app risk level and user department
• Pre-configured workflows: High-risk apps (production access, financial systems) require CISO approval; standard tools (Slack, Zoom) auto-approve for employees
• Provisioning automation: Approved requests trigger automated provisioning (API-based for integrated apps, ticket creation for manual apps)

Result: Event-based provisioning reduced from 0.75 FTE to 0.15 FTE (80% reduction). But this only addresses provisioning—cleanup still requires visibility, automated rules, and time-based access control.

The Capacity Impact

Manual lifecycle management:

• Event-based provisioning: 0.75 FTE
• Scheduled cleanup: 0.04 FTE
• Event-based cleanup: 0.75 FTE
• Total: 1.54 FTE needed, 0.5 FTE available

With automation:

• Event-based provisioning: 0.15 FTE (80% reduction via self-service access requests with app store catalogs)
• Scheduled cleanup: 0.01 FTE (75% reduction via real-time HRIS/IdP webhooks + automated rules)
• Event-based cleanup: 0.08 FTE (89% reduction via time-based access control + JIT privilege)
• Total: 0.24 FTE needed, 0.5 FTE available

Result: 0.26 FTE excess capacity. Your IT team can focus on strategic work instead of firefighting access requests.

Cleanup effectiveness:

• Manual: 0% (no capacity)
• Automated: 80% (3,600 of 4,500 excess grants prevented annually)

Cost impact over 5 years:

• Manual accumulation: 22,500 excess grants × $50/app = $1.125M/year
• Automated prevention: 4,500 excess grants × $50/app = $225K/year
• Annual savings: $900K

Why This Approach Works for Mid-Market

Enterprise IGA vendors require complete application catalogs upfront (6-8 weeks), perfect identity federation (3-4 months), dedicated IGA teams (2-3 FTE), and 6-12 month implementations. Mid-market companies can't afford this: IT teams measured in people not departments, applications discovered continuously not cataloged upfront, need results in weeks not quarters.

Progressive deployment solves this: Week 1: Deploy one rule (engineering onboarding), test on 2-3 hires. Week 2: Add conditions (IC vs Manager baselines). Week 3: Add contractor restrictions. Week 4: Add time delays for staged workflows. Week 5: Add scheduled cleanup (promotions trigger reviews). Week 6: Expand to other departments. Each week delivers tangible results. No 6-month wait to see if it works. One broken rule doesn't crash your entire system.

Visibility-first automation also enables governance for discovered applications: When continuous discovery identifies a user in an undiscovered app, governance workflows trigger immediately—not when you manually add it to your catalog. This prevents shadow IT from accumulating unchecked for months before discovery.

The three-part solution:

1. Complete visibility across federated, non-federated, and shadow IT (continuous discovery via SSO logs, browser extensions, endpoint agents, finance integrations)
2. Real-time automation rules triggered by HRIS/IdP webhooks for scheduled changes (instant playbook execution when roles change)
3. Time-based access control + JIT privilege for event-based changes (temporary access expires by default, elevated access provisioned only when needed)

Bonus capability: Self-service access requests through app store catalogs reduce provisioning burden from 0.75 FTE to 0.15 FTE, but only address half the problem—provisioning gets easier, cleanup still requires the above three capabilities.

Manual lifecycle cleanup is mathematically impossible. You need 3× your current capacity. Automated cleanup addressing both scheduled and event-based changes is the only solution—but only if you can see what you're automating.

‍