Most IGA connectors break silently at scale. Zluri's engineering team explains why we built a native iPaaS engine to fix integration reliability for good.
An identity security platform can have every capability on the checklist: visibility into every identity and app, risk intelligence, access reviews, certifications, SoD checks, lifecycle automation, posture management, the works.
None of it matters if the integration pulling data from Workday or Okta or Salesforce quietly stops syncing on a Tuesday and nobody notices until an auditor asks why a terminated employee still shows active access. Reliability, not capability count, is what actually determines whether an identity security platform works in production.
This is the part of identity security that doesn't show up in demos. We sat down with our engineering team to understand why integration reliability is so hard for most platforms in this space to sustain, and why we made a deliberate bet to build differently.
The capability is not the same as reliability
Most identity security vendors compete on the same surface: discovery, risk scoring, certifications, workflows, dashboards, policy engines. Those capabilities are visible, easy to demo, and easy to compare in an RFP. What's invisible in a demo is what happens when that platform tries to pull identity and access data from 200 apps across a real enterprise, at real volume, on a real schedule, month after month.
A capability that works perfectly in a sandbox with clean test data tells you almost nothing about whether it will survive contact with a production environment that has rate limits, paginated APIs, inconsistent schemas, and apps that change their endpoints without warning. That's where most identity security tools actually fail, not in what they can do, but in whether they can keep doing it reliably.
Why one to one integrations break reliability
The standard approach across most of the identity security market is to build integrations one app at a time, as custom code. An engineer writes a connector for Okta, another for Workday, another for Salesforce, each with its own logic for authentication, pagination, and error handling.
This works fine for the first ten integrations. It starts to buckle by the fiftieth. Our team described the pattern plainly: every connector becomes its own small piece of infrastructure that someone has to remember exists.
When a vendor changes their API, the fix has to be found and applied to that one connector specifically. Rate limit handling gets reinvented slightly differently each time, because it was written by whoever happened to build that connector that quarter. Nothing is shared, so nothing gets uniformly more reliable as the platform grows. It gets more fragile.
And the failures aren't always loud. A sync can quietly skip records, time out partway through a large pull, or silently retry into a rate limit wall. For an identity security platform, this isn't a minor inconvenience, it's a security and governance risk. Incomplete data flowing into an access review means reviewers are certifying access based on a picture that's already wrong, and that risk shows up everywhere downstream, in IGA, in risk scoring, in posture management.
What we built instead
Rather than scaling the same coded-connector model and hoping it holds, Zluri's engineering team built a native iPaaS engine. Every integration is declared as a schema, not written as bespoke code. The engine itself, one shared system, owns the hard parts: authentication, pagination, granular rate limiting, automatic retries with backoff, pause and resume, and consistent error handling, applied the same way across every single connector.
The shift in mindset our engineers described was simple but important: instead of asking "how do we write a good connector for this app," the question became "how do we make our engine handle any app well." That's a structural difference, not a cosmetic one.
When the engine gets better at handling rate limits, every connector benefits at once. When an API changes, the fix is a schema update, not a re-engineering effort buried in one connector's code.
Because identity security is fundamentally a data completeness problem, not just a connectivity problem, the engine is built to verify it actually pulled what it was supposed to pull. It tracks ingestion progress and surfaces gaps before they turn into a broken access review, a missed risk signal, or a failed audit, instead of after.
What this actually changes
New integrations ship faster. Most new app support is a schema change our team can build and validate quickly, not a development sprint that competes with other engineering priorities.
Reliability compounds instead of fragmenting. Improvements to rate limiting, retries, or error handling apply across every connector at once, because they live in the shared engine rather than in individual connector code.
Scale doesn't mean breakage. Whether an app allows three calls a second or a thousand a day, the engine enforces those limits centrally, so large enterprise syncs don't get throttled or fail silently halfway through.
Data completeness is checked, not assumed. The engine verifies what it pulled against what it expected to pull, which matters enormously when that data feeds access reviews, risk intelligence, and compliance reporting across the platform.
The integration count game, and why it's a vanity metric
This is also where a lot of identity security vendors quietly inflate their numbers. A platform claiming five hundred or a thousand integrations sounds impressive on a comparison chart, but the number alone says nothing about depth. T
he uncomfortable truth is that a large share of those integrations across the market are SCIM-only connections, capable of creating or deactivating an account and not much else. They can't reach into an app to downgrade a license tier, shift a role from admin to standard user, or revoke a specific scope without removing the account entirely. That's a shallow integration wearing the same label as a deep one, and the integration count on a slide doesn't tell you which is which.
What actually matters is quality, reliability, and resilience, not the raw count. An integration that can only do the basics, and only does them reliably some of the time, is worse than having fewer integrations that hold up under real production load and can act deep inside an app, not just at the account level.
This is also a pattern we see directly in customer migrations. Some of Zluri's customers came from platforms that won the RFP on paper, more integrations listed, more capabilities checked off, and then broke down in actual execution: syncs that silently failed, actions that didn't fully complete, reviews built on incomplete data. They didn't switch for a longer feature list. They switched because the platform they had couldn't be trusted to do what it claimed reliably, at scale, in production.
It's not just data, it's every action too
Reliability at the integration layer doesn't only decide whether your access review data is complete. It decides whether the actions an identity security platform is supposed to automate actually happen. Automating onboarding, revoking access when someone is offboarded, downgrading a license when a role changes, or pushing a user from admin down to a standard role, all of that runs through the same integrations.
If a connector silently fails or can't keep up at scale, it's not just a reporting gap anymore. It's a former employee who still has access a week after their last day, or an admin role that never got downgraded because the action quietly didn't go through.
This is exactly why the engine can't be tuned only for reads. It has to handle writes, the provisioning and deprovisioning calls, the license changes, the role updates, with the same rate limiting, retries, and error handling discipline as a large data pull. An integration layer that's reliable for fetching data but shaky for executing actions still leaves the organization exposed, just in a different place.
IGA is one pillar of identity security, and integrations are the foundation under all of them
It helps to be precise about what sits where. Zluri is built as an Identity Security Platform: identity visibility and inventory across every app and account, identity risk intelligence, identity governance and administration, and identity security posture management, working together as one connected system rather than as separate point tools stitched together.
IGA, the access reviews, certifications, SoD checks, and lifecycle automation, is one pillar of that platform, not the whole of it. And every pillar depends on the same foundation. Visibility can't be accurate if the integration pulling app and account data is unreliable. Risk intelligence can't be trusted if it's scoring incomplete data. Posture management can't catch a misconfiguration in an app it can't reliably reach. IGA can't certify access correctly if the data underneath the certification is already wrong.
The point worth sitting with is that the iPaaS engine isn't a feature sitting next to IGA or next to any other module, it's the connectivity layer the entire identity security platform depends on. If that layer is fragile, built out of one-off coded connectors that degrade as they scale, every pillar built on top of it inherits that fragility no matter how good its individual logic looks in isolation. Reliability at the integration layer is what makes "platform" more than a marketing word, and it's what makes identity security actually function as security, not just as reporting.
The real lesson: reliability compounds, or it erodes
Every identity security vendor will tell you their platform integrates with hundreds of apps. Almost none will tell you how. The honest answer, for most of them, is hundreds of separate pieces of code, maintained separately, breaking separately, and quietly degrading the trustworthiness of the identity data sitting underneath every risk score, every certification, and every review.
Zluri made a different bet early: build one engine that gets more reliable as it scales, instead of hundreds of connectors that get more fragile as they grow. That decision doesn't show up on a feature list. It shows up six months into production, when the sync still runs clean and every pillar of the platform is still standing on solid data.
Frequently Asked Questions
Doesn't every identity security platform claim broad integration coverage? Yes, but coverage and reliability are different claims. Most vendors can point to a long list of supported apps. Few can explain how those integrations stay stable at scale, because most were built as separate coded connectors with no shared resilience layer.
What specifically breaks with one to one coded integrations? Rate limit handling, retry logic, and error handling are typically reimplemented per connector, so reliability varies app by app. API changes require fixing the specific connector affected, and large data pulls are more likely to fail or skip records silently.
How does Zluri's engine prevent silent data gaps? The engine tracks ingestion progress and validates that all expected data was actually retrieved, surfacing incomplete pulls before they reach an access review, a risk score, or an audit rather than after.
Where does IGA fit into all of this? IGA, access reviews, certifications, SoD, and lifecycle automation, is one pillar of Zluri's Identity Security Platform. It depends on the same integration layer that powers visibility, risk intelligence, and posture management, which is why integration reliability matters across the whole platform, not just for governance workflows.
How fast can a new integration be added? Often hours to a day, since adding support for a new app is typically a schema change rather than new custom code, assuming app access and data mapping are finalized.
Is this only useful at a large scale? No, but the difference becomes most visible at scale, when rate limits, API volume, and data volume start to expose the cracks in a coded, connector by connector approach.
.svg)
