Half the failure modes in the standard "why IGA implementations fail" article describe a platform category SaaS-first companies aren't running anymore. Meanwhile, a genuinely new SaaS-specific failure mode has taken shape that most implementations still don't plan around.
Search for why IGA implementations fail and the answers converge on a familiar list:
- Integration costs balloon because connectors need custom development.
- Resource requirements get underestimated because the platform needs dedicated engineering.
- Pilots drag on because visibility into the environment takes months to build.
All of this is true. It was written about SailPoint, Saviynt, and their generation of enterprise suites: hand-coded connectors, on-premises deployments, professional services engagements measured in quarters. It describes that world accurately, and it's largely not the world a SaaS-first company is operating in.
For an organization running mostly SaaS applications, with a lean IT or security team and no dedicated identity engineering function:
- A modern platform doesn't have $75,000 custom connectors as a routine cost, because it wasn't built around hand-coded, per-application integrations in the first place.
- It doesn't need a dedicated identity engineering team, because it wasn't designed assuming one exists.
Planning around those risks anyway means solving a problem this environment doesn't actually have.
But something else happened alongside that progress, something specific to how SaaS-first environments actually work, that most implementations still don't plan around. This piece covers both halves: what genuinely doesn't apply anymore in a SaaS-first environment, and what's quietly still broken, old and new.
A note on scope, since this topic has a few related angles: this piece is about currency, not causality, which advice about IGA failure is still accurate today, and which is outdated. Two related questions have their own dedicated pieces:
- Why the failures that remain actually happen, and how they trace back to a smaller set of root decisions: our root cause analysis of IGA program failures.
- Why legacy IGA's resourcing and budget assumptions specifically excluded smaller, leaner organizations, independent of whether they're SaaS-first: how Zluri is democratizing IGA for mid-market companies.
Failure Modes That No Longer Apply to SaaS-First Environments
These describe real problems, but ones tied to legacy, on-premises, enterprise-suite architecture. If you're a SaaS-first organization evaluating or running a modern platform, these are largely not your risk anymore.
Failure Modes That Are Still Real for SaaS-First Environments
This is the list worth actually planning around. Three of these are organizational and have never been platform-dependent. Two are new or transformed, specifically shaped by how SaaS environments actually behave.
What Modern Platforms Actually Resolved
Custom connector costs and delays.
- The classic failure story: a vendor demo shows hundreds of pre-built connectors, the platform gets purchased, and specific applications turn out to need custom development costing tens of thousands of dollars and taking months per app. Routine with hand-coded, per-application connector architectures.
- Modern platforms built around API-based and schema-driven integration handle most standard SaaS applications without bespoke development, since the approach generalizes across applications with similar API patterns.
- On-premises systems and custom-built internal apps are the real exception: still connectable, but genuinely requiring development effort and some dedicated engineering resources.
- The difference from the legacy world is degree, not kind: a scoped integration effort for a specific application, not a routine, months-long cycle applying to nearly everything in the portfolio.
Heavy dedicated resourcing requirement.
- Enterprise suites assumed a dedicated identity engineering function would run them, people who understand the connector framework and manage a genuinely complex configuration surface.
- Modern platforms are built for teams without that dedicated function, with configuration that doesn't require engineering-level expertise.
- Someone still needs to own the rollout and run reviews, but the gap between what teams assume they need and what the platform actually requires is much smaller than it used to be.
- This shift matters most for organizations that were priced and staffed out of IGA entirely under the old model; that gap, and how it closes, is covered in more depth in how Zluri is democratizing IGA for mid-market companies.
Pilot dragging on for technical reasons.
- A meaningful share of legacy pilot delays came from technical bottlenecks: waiting on custom connectors before the pilot could start, or discovering coverage gaps mid-pilot that required scrambling to patch.
- With integration timelines compressed from months to days, the technical excuse for a slow pilot is mostly gone.
- What's left, covered below, is a purely organizational problem that faster technical timelines make more visible, not less.
The New Problem: Point-in-Time Visibility vs. Continuous Visibility
This is the failure mode most "modern platform" marketing doesn't mention, because it's not solved by being fast. It's solved by being continuous, and speed and continuity are different properties.
What the old version of this problem was: teams got impatient waiting months for slow, connector-based discovery to finish, and started building policies on an incomplete picture out of necessity. Modern platforms fixed that specific version by making initial visibility fast, often days instead of months.
Why a new version replaced it: on-premises environments had a relatively fixed application footprint. A new system required procurement, budget approval, and IT provisioning before it existed at all. SaaS removed nearly all of that friction:
- An employee can sign up for a new tool with a personal card or a free tier in minutes, with no involvement from IT, security, or procurement.
- An OAuth grant connecting a third-party app to Google Workspace or Microsoft 365 takes a few clicks and routes through no approval process whatsoever.
- A team can adopt a new collaboration or productivity tool that never touches a purchasing system finance would otherwise catch.
The application inventory isn't a fixed thing to be visible once. It's a constantly shifting surface that changes weekly, sometimes daily, in any organization of meaningful size.
Why most modern platforms still miss this: a platform can be genuinely fast and comprehensive at initial visibility, connecting in days rather than months, and still treat that visibility as a one-time onboarding event rather than an ongoing capability. Governance workflows get configured against whatever the environment looked like at setup. Without continuous or frequently recurring visibility, an environment that looked complete in week one is measurably incomplete by month three, and nothing in the platform necessarily flags that drift.
What this looks like in practice:
- A new SaaS sign-up via free tier or personal card goes unnoticed for months.
- An OAuth grant connecting a risky third-party app to core Microsoft or Google accounts never surfaces, because nothing is watching for new grants after the initial setup.
- A department starts using a new tool that never appears in the governed inventory, because visibility ran once, early, and never ran again.
- An access review runs confidently against what looks like a complete picture, and it isn't one.
What actually fixes it: continuous or frequently recurring visibility, not a single onboarding scan, combined with signals that catch new application adoption as it happens: OAuth grant monitoring, browser and expense signals, and recurring re-scans. When evaluating a platform, the question worth asking directly isn't "how fast is your initial scan." It's "how do you catch the application that gets adopted the week after that scan finishes."
What Hasn't Changed at All
Misaligned stakeholders. No platform, at any generation, fixes the decision to run IGA requirements through IT and security alone, without compliance, HR, or the app owners who'll actually perform reviews. This was never a technology problem. With the connector and resourcing bottlenecks mostly cleared, stakeholder misalignment is now one of the few remaining things capable of stalling a rollout that would otherwise move quickly.
Weak change management. A faster, easier-to-configure platform doesn't automatically produce adoption. People still need to understand why a review matters, still need to trust the tool's data, and still adopt fastest when they helped define what the tool needed to do. This failure mode was never about integration complexity, so removing integration complexity doesn't reduce it.
Wrong pilot starting point. Choosing which applications to pilot based on strategic value rather than convenience or complexity is a judgment call, not a technical capability. A modern platform executes the pilot quickly once applications are chosen. It has no opinion on which ones you should have chosen.
Boiling the ocean, in a new shape.
- Old trigger: comprehensive governance across every application despite slow, expensive integration, producing a project that never finished.
- New trigger: modern visibility shows the full environment in days, so teams see their entire portfolio immediately and feel pressure to govern all of it at once simply because it's suddenly visible.
- The scope discipline problem is the same. The trigger is different, and arguably harder to resist, because the old excuse ("we can't see everything yet") no longer applies.
Why This Distinction Matters for Planning
Treating platform-era failure modes as still-live risks has a real cost. Padding a budget for custom connector work a modern platform doesn't require, or assuming a dedicated engineering hire is needed before starting, wastes planning effort and can delay a project a lean team could actually run.
The bigger risk runs the other way: assuming that because initial visibility is fast, visibility as a problem is solved. It isn't. It changed shape, from a slow, one-time bottleneck into a continuous maintenance requirement that most implementation plans don't budget for at all, because nothing about a fast initial scan forces the question of what happens in month four.
Meanwhile, the organizational failure modes, stakeholder alignment, change management, scope discipline, get comparatively under-resourced, because they don't show up on a technical risk register the way connector costs used to.
What Actually Causes Failure With Modern Platforms
Stripped of the legacy-era noise, the honest list of what still derails a modern IGA implementation:
- Requirements defined by one department instead of a cross-functional group
- Visibility treated as a one-time onboarding event instead of a continuous capability
- No bounded scope or exit criteria set before planning, the pilot, or each rollout phase begins
- Success measured as one end-state number instead of tracked and reported phase by phase
- Change management treated as a late-stage communication task instead of a continuation of who was involved from the start
- Full initial visibility creating pressure to govern everything at once, rather than sequencing deliberately
None of these get solved by platform selection alone. They get solved by how the project is scoped, staffed, and run, and, in the case of continuous visibility, by asking vendors a more precise question than most evaluations currently ask.
These six items aren't independent of each other either, which is exactly the ground the root cause analysis covers in more depth.
Frequently Asked Questions
Does this mean integration problems never happen with modern IGA platforms?
No. Applications without APIs, deeply customized instances, and genuinely legacy on-premises systems still require real development effort and some dedicated engineering resources to connect. That work hasn't disappeared, it's just gotten lighter. The routine, expensive, months-long custom connector cycle that used to apply to nearly every application on enterprise suites is no longer the default experience for a SaaS-heavy portfolio; it's now a scoped exception for the specific systems that genuinely need it.
How do we test whether a platform actually provides continuous visibility, versus a fast one-time scan?
Ask the vendor directly how a new application, signed up after the initial connection, gets caught, and how long that typically takes. A platform with genuine continuous visibility will describe an ongoing mechanism: recurring re-scans, OAuth grant monitoring, or similar signals. A platform without it will describe only the process for the initial setup, which is a sign that anything adopted afterward falls outside what the platform actually sees.
If resourcing requirements are lower now, does that mean we don't need a dedicated project owner?
You still need one. A modern platform doesn't require a dedicated identity engineering team, but someone still needs to own the rollout, make scope decisions, and run access reviews. Skipping ownership entirely remains a real risk, just a smaller and more recoverable one than assuming an under-resourced team can absorb a legacy-style implementation.
Why does boiling the ocean still happen if visibility is fast now?
Because the underlying temptation isn't about how long visibility takes to build, it's about scope discipline once the full picture is available. Fast visibility makes the temptation more immediate: instead of scope creep happening gradually over months, it can happen on day one, the moment a team sees its entire application portfolio at once and wants to govern all of it immediately.
How do we know if we're planning around outdated failure modes instead of real ones?
For each risk on your implementation plan, ask whether it's a property of platform architecture or a property of how your organization is running the project. If a modern platform's own integration approach already addresses it, it's likely an outdated risk. If it's about whether visibility stays current after week one, or whether stakeholders are aligned, or whether scope is bounded, it's a real, current risk regardless of which generation of platform you buy.
.svg)
