Most IGA comparisons pretend to be neutral. This one doesn't. We're Zluri, and we'll tell you exactly where we win, where Lumos wins, and why the difference matters for security and compliance outcomes at scale.
If you're an IT or security leader evaluating identity governance platforms, you've probably landed on two names: Zluri and Lumos. Both show up on IGA shortlists. Both handle access requests, access reviews, and lifecycle management. Both position themselves as modern alternatives to legacy IGA.
But here's what most shortlist comparisons miss: Lumos is a governance point solution built around a self-service access request interface. Zluri is a full identity security platform built around a different premise entirely.
Lumos's answer to identity governance is an access request interface. Zluri's is: you cannot govern what you cannot see. Until every identity (human, non-human, sanctioned, shadow) is discovered and continuously monitored, the access request experience is a frontend sitting on top of an ungoverned environment — however well-designed that frontend might be.
That difference plays out across every capability area below.
Identity Discovery
Where We Overlap
Both platforms connect to applications through direct integrations, pull identity data from your SSO or IdP, surface access within connected apps, and trigger lifecycle actions from your HR system. For organizations whose entire app estate lives within what both platforms support, the starting point looks similar.
Where We Differ
Lumos discovers identities through its integration library. If the app is in the library and the connector is set up, Lumos can see it. If it isn't, it can't. That's it. No multi-method detection. No shadow IT coverage. G2 reviewers consistently flag integration gaps for custom and niche applications as a recurring frustration, and not an edge case.
Think about what lives outside a single integration library in a typical enterprise: apps employees signed up for directly with a company email, OAuth-connected tools that bypassed your IdP, browser extensions accessing company data, niche tools the IT team never approved. In most organizations above 200 people, that's a significant share of the app estate. Lumos cannot see any of it.
We built IVIP specifically because single-method discovery was the fundamental weakness in every IGA tool that came before us. Our engine runs eight discovery methods simultaneously: direct integrations, SSO/IdP connections, HR system sync, browser extension detection, finance and expense data, email analysis, API token scanning, OAuth connection mapping, and agent-based discovery. We typically find three times more apps than organizations expected. Not because they were careless, but because a meaningful portion of every enterprise app estate lives in channels that single-method discovery never reaches.
The offboarding consequence is the clearest proof of this gap. When someone leaves, our offboarding auto-populates from their actual discovered access footprint (every app, every OAuth connection, every shadow tool). Lumos offboarding stops at the integration library boundary. Access outside that boundary persists after the employee is gone. That's not a UX problem. That's a security failure.
Non-Human Identity (NHI) Governance
Where We Overlap
Both platforms have acknowledged non-human identity as a governance priority. Both recognize that service accounts, API tokens, OAuth connections, and AI agents represent a growing share of the identity surface and a growing share of identity risk.
Where We Differ
In most enterprise environments today, non-human identities outnumber human ones. They are also the least governed and the most exploited. Every unreviewed service account, every long-lived API token, every OAuth connection granted and forgotten is an open door.
Lumos launched NHI-related agents in June 2026. We'll be direct about what that means: not a mature capability with production depth. If your next compliance audit requires evidence of service account access reviews, API token lifecycle management, or AI agent governance as systematic workflows, this is not the foundation you want to stake that on.
We've covered service accounts, API tokens, OAuth connections, and AI agents as part of our standard discovery and governance framework for significantly longer. NHI governance in Zluri runs through the same access review, lifecycle management, and offboarding workflows as human identities, not a separate module bolted on after the fact. Guesty saved 15,000 IT hours on access requests and offboarding across all identity types, including non-human, using Zluri.
Access Requests
Where We Overlap
Both platforms offer self-service access request workflows, approval routing, manager approvals, Slack-native flows, and auto-provisioning on approval. Both support basic workflow configuration for common approval scenarios.
Where We Differ
Lumos's AppStore is its strongest capability: one-click access requests, clean UX, an AI agent handling the first pass on decisions. For engineering-led teams who want employees to self-serve without friction, it's a well-built interface. The constraint is that it only governs requests for apps inside its integration library, with limited approval logic, shallow workflow conditions, and restricted compliance tagging. You get a polished experience within a narrow, constrained governance model.
Zluri's Access Requests module is built for power and configurability across the full identity surface. Risk-score routing, compliance tagging, Jira integration, and multi-condition approval logic give IT and security teams the depth they need. More importantly, Zluri doesn't just grant or revoke access: it can upgrade or downgrade license plan types, change a user's role from admin to standard, modify entitlement tiers, and execute dozens of other access-state changes that go far beyond what any AppStore-style interface is built to handle. Every identity Zluri has discovered is in scope for governance, including the 40% Lumos cannot see.
Just-in-Time (JIT) Access
Where We Overlap
Both platforms support time-bound access provisioning and automatic revocation within their connected app catalog. Both handle the basic JIT workflow: request, approve, grant, expire.
Where We Differ
Lumos's JIT works within its integration library. Outside that boundary, there is no JIT mechanism at all. Temporary elevated access requests for any app not in the catalog fall back to email, Slack, and IT tickets, with no time-bound enforcement and no automatic revocation. JIT that stops at the library boundary isn't a time-bound access control. It's a gap with a clean UI in front of it.
Zluri handles JIT through an Access Duration condition across the full catalog. Time-bound provisioning and automatic revocation apply to every governed app, not a library subset. The coverage is what matters, not the click count.
Access Reviews
Where We Overlap
Both platforms support scheduled access certifications, manager-driven review workflows, risk-based prioritization, remediation actions, and audit-ready exports.
Where We Differ
Lumos's access reviews are scoped to what its library can see. NHI access, shadow app entitlements, and tools outside the catalog fall outside the review perimeter entirely. You can run certifications on schedule and still leave a significant portion of your identity surface unreviewed every cycle.
Zluri's access reviews cover the full discovered identity surface, human and non-human alike. Every identity Zluri has discovered is in scope, not just the ones in a library.
The question that matters: how fast you review the access you know about, or whether your reviews actually cover all the access that exists?
Identity Security Posture Management (ISPM)
Where We Overlap
Both platforms have moved toward identity monitoring beyond scheduled review cycles. Both surface some form of risk signals outside of formal certifications.
Where We Differ
Here's what happens without a dedicated ISPM layer: a user gets provisioned with broad access during onboarding. Over the next six months, they accumulate more access as projects shift. Their peer group's baseline access has nothing to do with what they're holding. Between review cycles, nobody flags it. By the time the next certification runs, over-privilege has been sitting there for months, either exploited or about to be.
Lumos's Identity Security Agents surface some risk signals in the background. That is not the same as continuous posture management. There is no systematic peer group comparison, no real-time risk scoring across the full estate, no automated enforcement between certifications.
Our ISPM runs continuously. Over-privilege detection, dormant account monitoring, and risk scoring operate independently of review schedules. When access exceeds a peer group baseline, when an account goes dormant with elevated access, when a role combination creates a risk pattern, we flag it immediately. Not at the next quarterly review. Immediately.
Separation of Duties (SoD)
Where We Overlap
Both platforms surface SoD conflict signals within access review workflows. Both can flag access combinations that create risk during a review cycle.
Where We Differ
SoD is not a core Lumos product capability. For organizations with SOX, ISO 27001, or similar mandates, flagging conflicts during a review is not the same as systematic SoD enforcement as an ongoing control. If your auditor asks for evidence of SoD enforcement across Salesforce, Okta, and GitHub, a review-time flag is not sufficient evidence.
Our SoD is SaaS-native with support for traditional systems. Conflict detection works systematically across the full catalog, not as a hint during reviews but as an enforced control your auditors can rely on.
Provisioning Depth (JML Automation)
Where We Overlap
Both platforms cover joiner, mover, and leaver lifecycle events, automate provisioning from HR triggers, and handle role-based access assignment and removal. Both support standard HRMS connectors like Workday, BambooHR, and similar systems.
Where We Differ
Lumos's lifecycle automation covers standard JML workflows within its library. What it isn't is flexible or deep. Workflow customization is limited, conditional logic is shallow, and anything outside the standard library (custom applications, niche tools, legacy systems) runs into friction. G2 reviewers consistently flag complex setup and unreliable connectors for non-standard apps. What Lumos can't reliably integrate, it can't reliably govern.
Zluri offers 1,500+ provisioning actions across 300+ apps. The distinction isn't the count of apps but the depth and flexibility of actions within each. Lumos provisions and deprovisions. Zluri does that and significantly more: upgrading or downgrading a user's license plan, changing a role from admin to standard user, modifying entitlement tiers mid-lifecycle, revoking specific session tokens while preserving other access, reassigning app ownership, and dozens of other access-state changes that matter at scale.
Need to create an administrative unit in Azure AD, assign a specific app role, revoke active sessions, and remove ownership simultaneously? That's a single Zluri workflow.
For legacy systems, ERP platforms, and database-backed applications, the Universal Identity Connector provides five pathways that cover environments most IGA tools simply cannot reach.
Who Should Choose Zluri
Lumos fits better when you have engineering-led organizations where the entire identity estate falls within its integration library, NHI is not in scope, SoD is not a compliance requirement, and posture management between review cycles is not a priority. Even then, you're accepting constrained workflow flexibility and a governance perimeter that cannot grow beyond the library.
The moment any of those conditions break, the library boundary becomes a governance boundary. And governance boundaries are where identity risk accumulates, where audits fail, and where attackers find their way in.
Choose Zluri when:
Your identity surface extends beyond a single integration library. Shadow IT exists in every organization above a certain size. OAuth-connected tools, browser extensions, and direct SaaS sign-ups create access that Lumos cannot see. We discover and govern the full environment.
NHI governance is a current compliance requirement. Service accounts, API tokens, OAuth connections, and AI agents need the same lifecycle management, access reviews, and offboarding as human identities. We've covered this for years. Lumos's NHI capabilities are not production-ready.
SoD is a compliance mandate. If SOX, ISO 27001, or another framework requires systematic SoD enforcement, Lumos is not built for that requirement. We are.
Continuous posture monitoring matters to you. Scheduled certifications are a point-in-time control. Over-privilege accumulates between cycles. Our ISPM monitors continuously. Lumos does not have an equivalent layer.
Offboarding needs to revoke everything, not just what's in the HRMS. We revoke access from the user's actual discovered footprint. Lumos revokes what it can see in the library. The difference is ungoverned access that persists after someone leaves.
Your user base is mixed. Technical and non-technical reviewers in the same workflow, legacy systems alongside SaaS, human and non-human identities in the same review cycle. We handle all of it.
Frequently Asked Questions
Is Lumos a full IGA platform?
Lumos is an access governance platform built around a self-service AppStore. Within its integration library, it covers access requests, reviews, and lifecycle automation. What it doesn't have is a full IGA stack: no dedicated ISPM layer, no multi-method discovery, limited SoD, and NHI governance that is not yet mature. If your definition of IGA includes continuous posture management across your full identity surface, Lumos doesn't meet that bar today.
Does Lumos cover non-human identities?
Lumos has NHI-related agents but they lack production depth. If NHI governance is a current compliance requirement, pressure-test those capabilities carefully before committing. Zluri has covered NHI as part of its standard framework for significantly longer.
What happens to apps outside Lumos's integration library?
They are ungoverned. Access requests go outside the AppStore workflow. JIT doesn't apply. Reviews don't cover them. Offboarding doesn't revoke access. For any organization where part of the app estate sits outside Lumos's library, that's a real security and compliance gap, not a minor inconvenience.
How does Zluri handle apps without a standard API integration?
Our Universal Identity Connector provides five pathways to connect systems that don't expose standard APIs, including legacy systems, ERP platforms, and database-backed applications. This extends governance to environments most IGA tools cannot reach.
What does Zluri's offboarding do differently?
Our offboarding auto-populates from the user's actual discovered access footprint, covering every app including shadow IT, OAuth-connected tools, and anything outside the HRMS or IdP. When someone leaves, access is revoked across everything we discovered. Lumos offboarding revokes what its library can see. Everything outside persists.
How does Zluri's ISPM work between review cycles?
Our ISPM runs continuously. Over-privilege accumulation, dormant accounts with elevated access, and risk pattern changes are flagged in real time. Lumos's governance is review-cycle-driven: between certifications, there is no continuous monitoring. For organizations where access risk doesn't wait for the next quarterly review, that gap matters.
How long does Zluri take to implement?
We typically deploy in 2–3 months, compared to 6–12 months for legacy IGA platforms like SailPoint or Saviynt. For organizations that need governance coverage quickly rather than after a year-long deployment, that difference is significant.
What compliance frameworks does Zluri support?
Our access reviews and audit exports are aligned to SOC 2, ISO 27001, PCI DSS, HIPAA, and SOX — giving compliance teams the documentation they need without manual assembly.
.svg)
