SaaS management and identity governance gaps in Zluri vs Torii

At a glance

What this is: A vendor comparison of SaaS management platforms that frames discovery, automation, reporting, and security as governance capabilities.

Why it matters: It matters because SaaS sprawl sits at the intersection of human access, service accounts, and delegated application privileges, so IAM teams need to separate operational visibility from actual identity control.

By the numbers:

• 300+ integrations, 0+ integrations, offering a wide range of options to seamlessly connect with various tools essential for your business operations.
• 24 reports

👉 Read Zluri's comparison of SaaS management features and security controls

Context

SaaS management is the operational layer where application discovery, licence usage, renewals, and access oversight meet. In practice, that makes it part of identity governance, because unmanaged SaaS often creates hidden human access, persistent delegated access, and weak offboarding controls that sit outside the core IAM programme.

This comparison between Zluri and Torii is not really about feature checklists. It shows how many organisations are using SaaS management platforms as a proxy for access governance, while the underlying questions remain whether identities are visible, whether privileges are right-sized, and whether compliance evidence is usable in reviews and audits.

Key questions

Q: How should security teams govern SaaS access across multiple applications?

A: Security teams should govern SaaS access by first building a reconciled inventory of applications, then mapping each app to an owner, an entitlement source, and a review cadence. The key is to treat SaaS access as part of the identity programme, not a separate software administration task. Without that linkage, reviews miss orphaned apps and hidden delegated access.

Q: Why do SaaS management platforms matter to IAM teams?

A: They matter because SaaS platforms often contain the real evidence of who has access, which permissions are active, and whether offboarding actually happened. IAM teams need that evidence to validate least privilege, certify access, and reduce privilege creep across apps that sit outside core enterprise controls.

Q: What do organisations get wrong about SaaS discovery?

A: They assume discovery means visibility, when it often only means partial inventory. A true discovery process must reconcile identities, integrations, and usage signals across multiple systems so that shadow IT, abandoned apps, and hidden access paths are all surfaced in one control view.

Q: How do you know if SaaS access governance is working?

A: It is working when your identity review process can answer three questions quickly: who owns the app, who currently has access, and what evidence shows the access was approved or removed. If those answers depend on manual chasing, governance is still incomplete.

Technical breakdown

SaaS discovery and shadow IT visibility

SaaS discovery is the process of finding which applications exist, who uses them, and how they connect to identity sources such as SSO, HR systems, and device management tools. In identity terms, discovery is the front door to governance because you cannot review access, prove ownership, or remove orphaned applications if the application estate is incomplete. When discovery relies on browser agents, directory signals, finance data, and direct integrations, it can expose shadow IT as well as sanctioned apps that never enter the official control plane.

Practical implication: build a discovery baseline that reconciles SaaS inventory against identity sources before you attempt access review or compliance reporting.

Integrations, automation, and delegated access control

Automation in SaaS management platforms usually means workflow orchestration across HR, IT, procurement, and security systems. That can accelerate onboarding, licence reclamation, and renewal handling, but automation is not the same as authority. If a platform can trigger actions without clean ownership models, it may automate bad decisions faster than humans can correct them. For IAM teams, the real technical question is whether automated workflows are tied to authoritative identity data and whether they preserve evidence for approval, revocation, and audit.

Practical implication: connect automation only to authoritative sources and require auditable approval paths for access-changing workflows.

Security scoring, audit logs, and compliance evidence

Security scoring and audit logging turn SaaS usage data into governance evidence. A risk score is only useful if it reflects meaningful signals such as permissions, exposure, and configuration state, while audit logs matter because they show who did what, when, and under which entitlement. Without these records, SaaS management becomes a spend tool rather than an identity control layer. For organisations running hybrid human and machine access, the same evidence is needed to support access reviews, investigations, and regulated-control testing.

Practical implication: treat audit logs and app risk scoring as evidence sources for IAM, not as reporting features owned only by operations.

Threat narrative

Attacker objective: The objective is to exploit unmanaged SaaS access paths, gain visibility or privilege inside connected applications, and use that hidden access to access data or evade governance.

1. entry: SaaS sprawl enters the environment through unsanctioned or poorly tracked applications that do not appear in the official identity inventory.
2. escalation: Over-broad integration paths and weak licence or access governance allow users and administrators to retain more SaaS privilege than they should.
3. impact: Hidden applications, abandoned accounts, and weak compliance evidence increase the chance of exposed data and failed audits.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SaaS management is now an identity governance problem, not just an operations problem. Once discovery, access review, and audit evidence live inside a SaaS management platform, the tool becomes part of the identity control plane. That matters because orphaned SaaS apps and unmanaged delegated access create the same governance failures seen in wider NHI programmes. The practitioner lesson is to govern SaaS management outputs as identity records, not as separate admin dashboards.

Discovery breadth is the named concept that separates inventory from governance. A platform that can see 9 or 300 integrations is not automatically governing anything; it is creating the raw material for governance. The field should stop treating discovery as a feature and start treating it as the condition that makes lifecycle control possible. Practitioners should measure whether discovery closes the gap between what is used and what is authorised.

Audit logs become decisive when SaaS access crosses human and machine boundaries. In mixed environments, the same application may host employee logins, service integrations, and automated workflows. That makes evidence quality more important than feature count, because reviews and investigations depend on knowing which identity actually performed an action. The implication is that identity governance must unify human access, delegated application access, and machine credentials under one evidence model.

SaaS automation can hide privilege drift if ownership is unclear. Workflows that reclaim licences, provision users, or connect systems are only as strong as the identity data behind them. If ownership, approval, and offboarding are fuzzy, automation simply accelerates the drift. The discipline-level takeaway is that governance needs accountable identity sources before workflow scale becomes safe.

The category is converging on control, not convenience. The market language around SaaS management increasingly overlaps with security, compliance, and access governance because buyers are trying to solve entitlement sprawl with operational tooling. That should push IAM and IGA teams to re-evaluate where SaaS management ends and identity governance begins. The practical conclusion is to assess these platforms by how well they support evidence, ownership, and revocation, not just by how many apps they connect to.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, which shows how quickly access governance is outrunning operating maturity.
• For a broader control lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that help close that gap.

What this signals

Discovery is becoming the first control boundary in SaaS governance. As more organisations rely on SaaS platforms to expose shadow IT and usage patterns, the deciding factor is whether those signals can be translated into ownership, revocation, and review. That is why inventory quality, not dashboard depth, will increasingly determine whether SaaS management reduces risk or just documents it.

Access evidence will matter more than access volume. In programmes that span human users, delegated app access, and machine identities, the question is no longer how many integrations exist but whether each entitlement can be tied back to a named owner and a defensible control. Teams should expect identity reviews to shift from application counts to evidence quality.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per The 2026 Infrastructure Identity Survey, the same governance weakness now reaches into SaaS integrations and workflow automation. That makes delegated access, app-to-app permissions, and renewal workflows part of the identity risk surface, not just platform administration. Teams should prepare for tighter scrutiny of every hidden credential path.

For practitioners

• Reconcile SaaS discovery against authoritative identity sources Compare application inventories from HR, SSO, finance, and device sources before accepting any SaaS management dashboard as complete. Use the resulting baseline to identify shadow IT, duplicate apps, and orphaned access paths.
• Tie automation to ownership and approval records Require every lifecycle workflow for onboarding, licence removal, and renewal handling to reference an accountable owner and an auditable approval step. Do not let orchestration act on stale identity data.
• Use audit logs as identity evidence Export and retain action-level logs that show who changed access, which entitlement was affected, and what system initiated the change. Feed those logs into access review and investigation workflows.
• Review third-party integrations as delegated access paths Treat each SaaS integration as a privilege-bearing relationship that needs ownership, scope review, and offboarding. Revalidate integrations when business ownership changes or applications are abandoned.

Key takeaways

• SaaS management tools are becoming identity governance tools whenever they are used to discover, approve, and remove access.
• Discovery, automation, and audit logging only reduce risk when they are anchored to authoritative identity sources and accountable ownership.
• The strongest programmes will judge SaaS platforms by evidence quality, lifecycle control, and delegated access oversight rather than by feature breadth alone.

Key terms

• SaaS discovery: SaaS discovery is the process of identifying which software-as-a-service applications exist in an environment and how they are being accessed. In governance terms, it is the starting point for visibility, ownership, and lifecycle control across sanctioned and unsanctioned apps.
• Delegated access: Delegated access is access granted through an application or integration rather than directly through a user login. It matters because the privilege may outlive the person who approved it, and the control point often sits outside the main IAM workflow.
• Shadow IT: Shadow IT is software or service use that has not been approved, inventoried, or governed by the organisation’s formal control processes. It creates identity risk because access, data sharing, and offboarding may happen without the oversight needed for audit or revocation.
• Access evidence: Access evidence is the set of records that proves who had access, who approved it, and when it changed. In SaaS governance, evidence quality determines whether access reviews, investigations, and compliance audits can be completed without manual reconstruction.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Zluri: SaaS Management Zluri vs Torii: Exploring Features, Benefits & Differences. Read the original.