IAM Friction and Waste: Why Enterprise Identity Management Creates More Problems Than It Solves

1. Why IAM is Not Friction-Free

Think about IAM as a set of flows, not a technology:

• • Joiner / Mover / Leaver (JML) – employees, contractors, partners
• • Customer / citizen access (CIAM) – portals, apps, APIs
• • Machine identities – service accounts, workloads, APIs, secrets
• • Privileged access – admins, break-glass accounts

Each of these cuts across HR → IT → security → business owners → vendors. Friction appears because:

Ownership is Fragmented

• • HR owns "who is this person?"
• • IT owns devices and directories.
• • Security owns policies.
• • App owners decide approvals.

IAM Architecture is Usually an Archaeological Site

Legacy AD forests, on-prem apps, multiple IdPs (Okta, Azure AD, Ping, custom SSO), VPN, custom RBAC in each app.

Security vs UX Trade-offs are Handled Ad-Hoc

Add MFA here, step-up auth there, extra approvals for "sensitive" apps…

2. Common Pain Points & Waste in Enterprise IAM

A. New Onboarding (Joiners) – Slow, Manual, Inconsistent

Typical story:

HR creates a new hire in Workday → overnight sync → ticket to IT → ticket to IAM team → manual group assignments → email to app owner for that one legacy system…

Friction & Waste:

• • Long lead time – new hires can't work productively for days.
• • Ticket ping-pong – "wrong group", "missing system", "approval from X needed".
• • Role design by guesswork – instead of proper roles, someone copies access from "a similar person".
• • Rework – onboarding completed, then manager says "they also need Salesforce / Jira / XYZ".

You can frame this as classic Lean wastes:

B. Movers – The Silent Source of Both Risk and Cost

Role changes (promotion, department move, project change) are not handled cleanly:

• • Access is added but not removed ("access creep").
• • Old teams' groups stay; new groups get added.
• • Shadow access: shared team accounts, shared mailboxes, copied API keys.

Waste and Risk:

• • Audit firefights – every review, auditors highlight excessive access, so you run manual attestation campaigns and remediation projects.
• • License bloat – users still have licenses for tools they no longer use.
• • Hidden SOD (segregation of duties) – people ending up with combinations of permissions that violate policy.

C. Leavers – Offboarding Gaps and Manual Work

Offboarding is often very strong on AD/email, weaker on apps:

• • Network / email disabled immediately ✔
• • But dozens of SaaS apps, internal tools, and service accounts lag behind.

Waste & Risk:

• • Time-consuming manual checklists for IT and managers.
• • Zombie accounts still active in external SaaS or internal apps.
• • Audit & compliance overhead to prove everything was revoked.

D. Access Requests & Approvals – High Friction, Low Insight

The "access request" process is usually where users feel IAM most:

Portal / ticket to request access → routed to line manager → routed to app owner → sometimes security for "high-risk access".

Approvers often have no context:

• • "What does 'APP_ROLE_FINANCE_RPT_3' actually allow?"
• • "Is this overlapping with something they already have?"
• • "Is there a least-privilege alternative?"

Waste:

• • Approval bottlenecks – approvers rubber-stamp because they're overloaded.
• • Back-and-forth clarifications – "Why do you need this?" repeated via email.
• • Over-approval – to avoid blocking work, people approve everything, creating future clean-up work.

E. Passwords, MFA & Authentication Fatigue

For employees and customers:

• • Multiple passwords (legacy apps not federated).
• • Frequent password expiry policies (still too common).
• • MFA every login, instead of risk-based or session-aware.

Waste:

• • Huge service desk load – password reset tickets are still a giant chunk of IT support in many orgs.
• • User frustration & workarounds – writing passwords down, reusing weak passwords, sharing accounts.
• • Lost productivity – micro-frictions add up (extra seconds/minutes per login, repeated authentication).

F. Tool Sprawl & Integration Pain

Most large enterprises have:

• • An IdP (or several)
• • A PAM tool
• • One or more IGA / provisioning tools
• • Legacy home-grown access DBs / scripts
• • Multiple HR systems or HR + contractor systems

Waste:

• • Integration projects for every new system – custom connectors, brittle scripts, one-off workflows.
• • Parallel IAM stacks (e.g. one for acquired company, one for HQ) that never fully converge.
• • Duplicate data and inconsistent truth – HR says one thing, AD says another, SaaS app has its own profile.

G. Governance & Compliance – "Burst" Instead of Continuous

Most orgs still do access reviews in big bursts:

• • Quarterly or annual reviews where managers must review 100s of entitlements.
• • Managers don't understand the entitlements; they "approve all" to get it done.
• • After the review, remediation projects to fix obviously bad access.

Waste:

• • Time sink for managers and security teams.
• • Low signal – a lot of effort, little meaningful risk reduction.
• • Audit surprises – because the underlying role model is messy, each audit finds a new variant of the same problem.

3. Specific "Waste Patterns" Around IAM Onboarding & Processes

If you want language that resonates with "we cut cost and remove waste", you can talk in patterns:

Manual Identity Data Fixing

HR sends incomplete records → IAM team manually corrects names, departments, manager links.

Every exception becomes a one-off script or manual fix.

Role Design by Escalation

Instead of a clean role model (Job → Role → Entitlements), roles evolve reactively:

"X can't access Y → add group Z → repeat."

App Onboarding Backlog

Each new application needs:

• • Connector or custom automation
• • Role mapping
• • Approval flow definition

IAM team becomes a bottleneck, so apps live outside formal IAM for months/years.

Duplicate Approvals

Same line manager approval replicated in HR, access request, and sometimes in the app itself.

No central view of: "Who approved what, and based on which policy?"

Fire-Fighting Instead of Design

Time spent fixing failed provisions/de-provisions, broken connectors, urgent "grant access now" tickets.

Very little time allocated to redesigning processes so the problems stop recurring.

4. Why "Decentralised" / Federated Models Add More Complexity

Modern operating models move towards:

• • Autonomous product teams
• • Multi-cloud deployments
• • SaaS first adoption

That means:

• • Each team wants freedom to choose tools and define access, but central IAM still owns policy and compliance.
• • Local admins create their own groups/roles in SaaS tools that are not mapped back into central IAM.
• • Teams implement their own "light IAM" (e.g., custom user DB + JWT auth) without reusing central capabilities.

New Wastes:

• • Inconsistent policies – different password/MFA/session rules across tools.
• • Duplicated implementation – similar role concepts implemented differently in each team.
• • Harder incident response – "Who has access to what?" becomes a detective exercise whenever there's a breach.

Conclusion: The Path Forward

IAM friction and waste are not inevitable. They're symptoms of fragmented ownership, legacy architecture, and reactive processes. By identifying these patterns, you can:

• Map your specific waste patterns to quantify the cost
• Design end-to-end ownership models that eliminate hand-offs
• Implement continuous governance instead of burst reviews
• Build risk-based, user-centric authentication flows

The goal isn't perfect IAM—it's IAM that enables rather than blocks. When you can articulate these waste patterns to stakeholders, you create the business case for change.