Most IGA platforms ask you to tell them what to govern. Zluri's starts by finding out what actually exists, then governs all of it.
Ask most IGA vendors what makes their platform different, and you'll get a list of features: access reviews, provisioning workflows, compliance reports. Those are table stakes now. Every serious platform in this category has them.
What actually separates one IGA platform from another shows up somewhere less obvious: whether it can see your full environment before it starts governing, whether its modules actually talk to each other or just sit next to each other, and whether the integrations underneath it hold up once you're running them at real scale, month after month, not just in a demo.
Here's what powers Zluri's IGA platform, and why each piece exists.
The Problem Most IGA Platforms Don't Solve
Traditional IGA operates on an assumption: you already know what applications exist, so the platform's job is to govern access to that known list. Feed it an inventory, and it will provision, review, and report on exactly that inventory, reliably and well. Three problems break that assumption in practice, and Zluri's IGA platform was built to address them in this order:
- The visibility assumption breaks first. Most organizations can see 30 to 40 percent of their actual application footprint through their identity provider and procurement records. The rest sits in unfederated apps, tools purchased directly by departments, and AI applications nobody formally approved. A platform that governs only what it's told about isn't governing your environment, it's governing the visible slice of it while the rest accumulates risk untouched. For the fuller argument, see why visibility-first beats governance-first.
- The second problem is separate tools instead of one converged system. Most IGA setups are stitched together from standalone tools for access management, access reviews, access requests, and SaaS visibility. Each holds its own view of users and access. When something changes in one, it doesn't automatically update in the others, so teams end up manually reconciling data between systems that were never designed to share it, the same disparate model problem in its most common form.
- The third problem is invisible until it breaks: integration reliability. An IGA platform can have every capability on the checklist, but none of it matters if the connector pulling data from your HRIS or your identity provider quietly stops syncing and nobody notices until an access review is already built on stale data.
Visibility First, Then Governance
Zluri's identity visibility and intelligence layer, IVIP, is the foundation the rest of the platform sits on. Instead of starting from a list of known applications, IVIP runs a patented discovery engine that pulls identity and access signals from SSO, HR systems, finance and expense tools, CASBs, directories, endpoints, and APIs, building a single inventory that goes well beyond what any SSO-only approach can see.
That distinction matters more than it sounds. A platform that only sees federated apps is reviewing and provisioning against a partial picture and calling it governance. IVIP is designed to surface the other 60 to 70 percent, including shadow IT, unmanaged apps, and non-human identities like service accounts, tokens, and AI agents that typically have no assigned owner and no lifecycle control at all.
Once identities and applications are discovered, IVIP's unified identity graph connects them, mapping not just who has access to what, but how that access was granted, how it spreads across systems, and where it concentrates into risk. That's a meaningfully different question than "does this person have access to Salesforce." It's closer to "how did they get admin rights, who else inherited the same path, and is that path still justified."
Governance applied to a partial inventory isn't incomplete governance, it's an accurate picture of a fraction of your risk. Visibility-first means the governance layer never has to ask "is this all of it."
One Platform, Four Connected Modules, Not Four Separate Tools
Zluri's IGA suite is built from four modules that operate on the same underlying data rather than as standalone products that happen to share a login screen:
- Access Management handles the full joiner-mover-leaver lifecycle, provisioning and deprovisioning across both federated and unfederated apps, with 300+ integrations and 1,500+ granular workflow actions that go beyond simple group-based access.
- Access Requests gives employees a self-service way to request access, with policy-driven approvals, time-bound access grants, and Slack-native workflows that remove the ticket queue without removing oversight.
- Access Reviews automates certification campaigns with contextual risk data and closed-loop remediation, covered in more detail below.
- Segregation of Duties continuously monitors entitlements across any connected application, not just your ERP, to detect and remediate toxic access combinations before they become audit findings.
The reason these being one connected system matters more than it sounds: access reviews and access management are supposed to inform each other. When a review consistently finds the same category of problem, like contractors accumulating admin access that never gets revoked, that's not just a finding to remediate, it's a signal that the underlying provisioning workflow is broken.
On most fragmented setups, that signal never makes it back to the team managing provisioning, because the review platform and the provisioning platform are different tools with no feedback loop between them.
On Zluri, review findings and provisioning workflows sit in the same system. A broken offboarding workflow that keeps leaving departed contractors with active access shows up as a pattern, not a recurring line item you clean up quarterly and forget.
Access Reviews Built for How Audits Actually Work
Most IGA platforms let you review access one way: by application. That's useful when the question you're answering is "who has access to Salesforce." It's the wrong shape entirely when the question is "does this one contractor's entire access footprint still make sense" or "review everyone in this access group across five different apps."
Zluri scopes reviews to the actual question being asked:
- Application-based reviews, who has access to one system.
- Group-based reviews, everyone in one access group across multiple apps at once.
- User-based reviews, one person's entire access footprint, end to end.
Most platforms only support the first, which forces you to reconstruct the other two answers from overlapping campaigns and manual reconciliation.
Reviews also carry the contextual risk insights most platforms leave out. Instead of asking a reviewer to approve or reject a name on a list, Zluri surfaces:
- Last login and usage frequency
- Whether the account is dormant, or inactive with access still active
- Privileged or high-risk access assignments
- Access outliers based on app usage or department alignment
- Unusual privilege levels compared to peers in the same role
That context is what turns an informed decision into the default instead of rubber-stamping. Combined with recurring certifications, bulk approvals for low-risk accounts, and multi-level reviewer routing, this is designed to cut audit prep from multiple days down to a fraction of that, measurable value that shows up on more than one team's dashboard.
When a review concludes that access should be revoked, remediation happens through closed-loop automation, meaning the deprovisioning action fires immediately through the same API-based workflows Access Management already uses, without a manual handoff to IT or a second tool to log into. That closed loop is only possible because reviews and management run on the same platform in the first place.
Access Management: The Full Joiner-Mover-Leaver Lifecycle
Most platforms provision at the group level: add someone to a Salesforce group, done. Zluri's actions chain further, assigning the right license tier, setting the specific role inside the app, adding someone to the right Slack channels, all as part of one workflow instead of five manual follow-ups. For how those actions actually chain together, see Access Management under the hood.
The lifecycle side matters as much as the provisioning side. Movers, people changing roles or departments, are where access most often goes unmanaged: old access rarely gets revoked when new access gets granted, and the accounts that fall through that gap are exactly how orphaned accounts accumulate for an audit to find months later. Access Management closes that gap by treating a role change as a full re-provisioning event, not just an addition.
Access Requests: Self-Service Without Losing Oversight
The ticket queue is where most IT teams lose the most time to the least interesting work: "can I get access to X," approved, provisioned, closed, repeated hundreds of times a month. Access Requests removes IT from that loop for anything low-risk, while keeping policy-driven approval routing for anything that isn't.
The effect shows up furthest from the IT team itself. A new hire who can self-serve their way to the tools they need on day one experiences IGA as something invisible and fast, not a ticket they're waiting on, and that shift in employee experience is as much the point as the ticket reduction is. The underlying mechanics, the self-service catalog and approval flow itself, are what make that experience possible without opening up unreviewed access sprawl.
Segregation of Duties: Continuous, Not Just at Audit Time
Most SoD checks run on a schedule: quarterly, ahead of an audit, whenever someone remembers. In between, conflicting entitlements can sit on the same person for months before anyone notices, which is exactly the exposure window SoD closes.
Because Segregation of Duties runs on the same platform as Access Management, it isn't limited to checking conflicts after they've already been granted. Toxic combinations can be blocked at request time, before the second conflicting entitlement is ever approved, which is a materially different guarantee than finding the conflict on the next quarterly scan.
Real-Time Sync with Your HRIS, Not a Nightly Batch Job
Every identity lifecycle event, someone joining, changing roles, or leaving, originates in your HR system. If your IGA platform syncs with that system on a delay, every downstream action inherits that delay: new hires wait longer for access, role changes lag behind reality, and departed employees keep access for however long the sync window allows.
Zluri connects directly to core HRIS and HRMS platforms for real-time synchronization, so a status change in HR (active, terminated, role change, department transfer) triggers the corresponding access change immediately rather than waiting for the next scheduled pull. That immediacy is what closes the gap between "this person left the company" and "this person's access was revoked everywhere it existed," which is exactly the window where most offboarding failures live.
Reliability Is the Part That Doesn't Show Up in a Demo
An identity platform can list hundreds of integrations and still fail in production if those integrations were built as one-off, hand-coded connectors. That's the standard approach across most of the IGA market, and it works for the first several dozen, then gets fragile fast, because nothing about one connector's reliability improvements carries over to the next.
Zluri built a native iPaaS engine instead:
When the engine gets better at handling rate limits, every integration benefits at once. When a vendor changes their API, the fix is a schema update, not a re-engineering project buried in one connector's code.
This matters for a reason that has nothing to do with engineering elegance: identity security is a data completeness problem before it's anything else. A sync that silently skips records or times out partway through means an access review gets built on a picture that's already wrong, and reviewers end up certifying access based on incomplete data without knowing it. Zluri's engine tracks ingestion progress and verifies it pulled what it expected to pull, surfacing gaps before they turn into a bad review or a missed audit finding, not after.
The same reliability discipline applies to writes, not just reads. Provisioning, deprovisioning, license downgrades, and role changes all run through the same integration layer, with the same retry and error-handling logic as a large data pull. An integration that's solid for reading data but shaky for executing actions still leaves you exposed, just somewhere else in the process.
IRIS and UIC: The Intelligence and Connectivity Layers Underneath Everything
Two platform-level components sit underneath the IGA modules themselves.
IRIS, Zluri's Identity Risk Intelligence System, is the intelligence layer that turns raw identity signals into decisions. It aggregates and normalizes identity data, builds a relationship graph connecting identities and access paths, and detects risks and anomalies before recommending remediation, feeding context into access reviews, SoD monitoring, and provisioning decisions across the platform.
UIC, the Universal Identity Connector, extends identity security into systems that traditional connectors can't reach: legacy infrastructure, custom databases, on-premises ERPs, and internal applications without modern APIs. It offers five distinct pathways so that even systems without a public API can be brought under consistent policy enforcement:
- Directory integration
- Enterprise connectors
- Database orchestration
- An extensible connector framework
- Interface automation
Standard integrations typically take 2 to 4 weeks; enterprise connectors take 4 to 8 weeks, both well inside the 6 to 12 month timelines common with legacy IGA implementations.
What This Adds Up To
None of this is meant to suggest Zluri is the right fit for every organization. A 35,000-person enterprise with a dedicated identity team and deep SoD requirements across a dozen legacy ERPs may still be better served by a platform built exclusively for that scale, like SailPoint or Saviynt, the tradeoff our guide to choosing IGA software walks through in full. What Zluri's architecture is built for is a specific, underserved gap: organizations that carry enterprise-grade compliance and security requirements without an enterprise-grade identity team or an enterprise-grade timeline to get there.
Three pieces, and none of them work alone:
- Visibility-first foundation: governance never has to guess whether it's covering the whole environment.
- Connected modules: access reviews actually improve provisioning instead of just documenting its failures.
- Reliable integration layer: the data underneath every review, risk score, and audit report can be trusted.
That combination, not any single feature on its own, is what an IGA platform actually needs to hold up once it's running in production, and it's the same combination our phased implementation guide assumes you're building toward.
Frequently Asked Questions
What does "visibility-first" mean in an IGA platform?
It means discovery happens before governance is applied, rather than assuming you already know which applications and identities exist. A visibility-first platform like Zluri finds shadow IT, unmanaged apps, and non-human identities first, then governs the complete picture. A governance-first platform only governs what it's told about, leaving whatever it doesn't know about completely ungoverned.
What's the difference between IRIS and IVIP?
IVIP (Identity Visibility and Intelligence) is the discovery and mapping layer that finds identities, applications, and how they connect. IRIS (Identity Risk Intelligence System) is the intelligence layer that analyzes that data to detect risk, anomalies, and recommend remediation. IVIP tells you what exists; IRIS tells you what matters about it.
Why does it matter if access reviews and access management run on the same platform?
Because they're supposed to inform each other. Review findings should reveal which provisioning workflows are broken, and provisioning changes should get validated by the next review cycle. When reviews and management live in separate tools, that feedback loop requires manual exports and reconciliation, which usually means it just doesn't happen. On a connected platform, a recurring review finding shows up as a workflow problem to fix, not a cleanup task to repeat every quarter.
Can Zluri run access reviews scoped to a specific group or user, not just an application?
Yes. Zluri supports application-based, access-group-based, and user-based reviews, so a review can be scoped to the actual question being asked, whether that's everyone with access to one system, one access group across multiple apps, or one user's complete access footprint.
What is the Universal Identity Connector for?
UIC extends identity governance into systems that don't have modern APIs, including legacy infrastructure, custom-built internal applications, and database-backed systems. It provides five integration pathways so that even hard-to-reach systems can be brought under the same policy enforcement as your SaaS stack.
How is Zluri's integration approach different from typical IGA connectors?
Most IGA platforms build integrations as separate, hand-coded connectors, one per application, each with its own logic for authentication and error handling. Zluri built a native iPaaS engine where integrations are declared as schemas and a shared engine handles authentication, rate limiting, retries, and data completeness verification consistently across every connector, so reliability improves platform-wide rather than connector by connector.
.svg)
