SaaS onboarding automation exposes the limits of manual access control

At a glance

What this is: This is a Zluri analysis of four ways to give employees SaaS access during onboarding, arguing that manual workflows break down as app usage grows and governance depends on complete inventory plus repeatable provisioning.

Why it matters: It matters because IAM and IGA teams need onboarding controls that scale across SaaS sprawl without leaving access gaps, creating shadow IT, or relying on ad hoc approvals that cannot be governed consistently.

By the numbers:

• Today, an employee in a mid-size company uses over 100 apps on average.
• Using an SSO, you can give access to only 30% of the required SaaS tools.

Context

SaaS onboarding becomes an identity governance problem when access decisions are spread across app admin panels, SSO coverage, and manual request handling. The central issue is not simply how fast IT can click through provisioning, but whether the organisation knows which apps exist, which users need them, and which workflows preserve control as the stack grows.

Zluri’s article frames four provisioning patterns: manual setup, SSO, SaaS management platforms, and self-serve app catalog access with guardrails. The operational lesson is that onboarding only stays controlled when inventory, approvals, and revocation are connected to a repeatable process rather than left to individual admins or employees.

Key questions

Q: Why does manual onboarding become risky as the SaaS estate grows?

A: Manual onboarding becomes risky because the number of apps, accounts, and access rights grows faster than teams can reliably manage them. Errors in account creation, missed deprovisioning, and outdated tracking increase the chance of overprovisioning and stale access. At scale, the problem is not only efficiency. It is also control loss and inconsistent enforcement.

Q: How should teams handle SaaS apps that are not covered by SSO?

A: Teams should treat non-SSO applications as a separate governed population, not as exceptions to ignore. Those apps need their own provisioning, approval, and review path so access does not disappear outside the federation layer. If they remain unmanaged, the organisation will have partial visibility and incomplete onboarding coverage.

Q: What are the signs that SaaS onboarding is not under control?

A: Common signs include employees waiting days for basic access, frequent one-off provisioning requests, users signing up for tools on their own, and disagreement about which applications are actually in use. Those symptoms point to a missing inventory and a broken onboarding workflow, not simply to a slow IT team.

Q: What breaks when fraud investigations depend on spreadsheets and ad hoc team pings?

A: The main failure is latency. By the time someone gathers the numbers, the signal may have gone cold and the fraud pattern may have shifted. That slows investigation, hides the orders driving the issue, and makes executive reporting stale. Teams also lose consistency, because different analysts may assemble different views of the same problem.

Technical breakdown

Why manual SaaS provisioning breaks at scale

Manual onboarding means an admin grants access app by app, usually based on title, department, or a manager conversation. That model depends on perfect prior knowledge, but SaaS estates change constantly and employees often need tools that were not captured in the original plan. The result is delay, incomplete access, and employee workarounds. In IAM terms, the failure is not just effort. It is the absence of a governed entitlement model that can keep pace with app sprawl and business variation.

Practical implication: replace ad hoc app-by-app provisioning with a controlled onboarding model tied to known roles and current application inventory.

What SSO covers and what it does not

SSO reduces password handling and lets teams grant access to multiple apps at once, but it does not automatically solve onboarding coverage. The article notes that many SaaS applications cannot connect to SSO, with coverage limited to about 30% of required tools in its example. That means SSO is a federation and convenience layer, not a full lifecycle control for SaaS access. If teams treat it as complete coverage, they leave a large unmanaged tail outside the onboarding process.

Practical implication: map which SaaS apps sit outside SSO and govern those applications through separate provisioning and review paths.

How SaaS management platforms create governed onboarding

A SaaS management platform centralises discovery, onboarding workflows, and request handling so access is not dependent on manual memory or spreadsheet tracking. The key mechanism is discovery first, because you cannot govern onboarding for apps you have not identified. From there, role-based recommendations, playbooks, and request workflows turn onboarding into a repeatable entitlement process. That changes the control objective from manual completion to inventory-backed governance across the SaaS estate.

Practical implication: build onboarding around discovery, workflow automation, and periodic inventory reconciliation so access coverage matches the real app estate.

Threat narrative

Attacker objective: The practical objective is not a single exploit, but an unmanaged access state that bypasses governance and expands shadow IT risk.

1. Entry occurs when a new employee needs access and the organisation relies on manual provisioning or incomplete SSO coverage instead of a governed inventory.
2. Escalation happens as the employee waits for access and begins using unsanctioned tools or self-provisioned apps to complete work faster.
3. Impact is an unmanaged SaaS footprint with shadow IT, incomplete access coverage, and weak visibility into who has access to what.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Manual onboarding is really an inventory problem disguised as an access problem. If teams do not know which SaaS applications are in use, they cannot credibly say onboarding is complete. The article’s strongest point is that access gaps often start before provisioning, at discovery and classification. That makes inventory the prerequisite control for any scalable onboarding programme.

SSO reduces friction, but it does not close the SaaS governance gap. Federation solves a subset of authentication and access delivery, not the full entitlement lifecycle across disconnected applications. The article’s 30% coverage claim underlines a common failure mode: teams overestimate what SSO can govern and underestimate the unmanaged remainder. Practitioners should treat SSO as one control layer, not the programme boundary.

Self-serve access works only when it is backed by guardrails. App catalog models can reduce ticket volume and improve user experience, but they also shift responsibility toward policy, approval metadata, and transparent request handling. Without those controls, self-service simply moves sprawl from IT queues into decentralised demand. The practitioner lesson is to govern choice, not merely accelerate it.

SaaS onboarding automation is becoming a lifecycle governance discipline, not an admin convenience. The combination of discovery, playbooks, and access requests means onboarding now sits at the intersection of IGA, SaaS management, and joiner processes. That convergence demands one named concept: discovery-backed onboarding: access can only be governed if the application estate is first discovered, continuously updated, and tied to repeatable provisioning logic. Practitioners should design onboarding around that assumption.

Control coverage, not tool count, is the real benchmark. The article shows that access tooling choices only matter insofar as they close the gap between the real application estate and the governed entitlement process. Teams that measure success by how many apps are connected to one login system will miss the larger problem of unmanaged SaaS outside the control plane. The implication is to evaluate governance completeness, not just provisioning convenience.

What this signals

Discovery-backed onboarding: access governance now starts with understanding the live SaaS estate, not with accelerating approval workflows. If the organisation cannot enumerate its applications accurately, onboarding automation only scales uncertainty.

SaaS onboarding is converging with IGA and SaaS lifecycle management, which means teams should expect more pressure to tie provisioning, revocation, and app inventory into one operating model. The practical move is to assess coverage gaps before expanding self-service access.

SSO should be treated as one layer in a broader access model, not as the control that completes onboarding. Where a large share of SaaS remains outside federation, organisations need separate entitlement paths and periodic reconciliation.

For practitioners

• Build a live SaaS inventory Continuously discover the applications actually used in the organisation before attempting to automate onboarding or access requests.
• Map coverage gaps outside SSO Identify the SaaS tools that cannot be reached through single sign-on and assign a separate provisioning path for them.
• Standardise role-based onboarding playbooks Create repeatable onboarding workflows that use department and seniority signals to provision the common access set consistently.
• Add guardrails to self-serve access Require approval metadata, app alternatives, and request visibility so employees can choose apps without creating unmanaged sprawl.
• Reconcile onboarding against the real app estate Review whether all discovered applications are represented in the provisioning process and close any coverage gaps as part of access governance.

Key takeaways

• Manual SaaS onboarding breaks down because it cannot keep pace with a growing and changing application estate.
• The biggest control gap is incomplete discovery and coverage, not only slow provisioning.
• Automation works when onboarding is tied to inventory, repeatable workflows, and guardrails for self-service access.

Key terms

• SaaS Onboarding: SaaS onboarding is the process of granting a new employee the applications, permissions, and related access needed to start work. In practice, it spans discovery, approval, provisioning, and verification, and it fails when the organisation cannot see the full app estate.
• SaaS Management Platform: A SaaS management platform is a visibility and optimisation layer for cloud software use. It helps teams discover applications, track utilisation, and understand spend patterns, but it does not by itself enforce access policy, revoke permissions, or manage identity lifecycle state.
• Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.