SaaS onboarding automation exposes the limits of manual access control

At a glance

What this is: The article argues that onboarding SaaS access is too slow and fragmented to manage manually, and that automation is needed to keep provisioning, approvals, and governance aligned.

Why it matters: It matters because onboarding is where identity sprawl, shadow IT, and access drift often begin, and those same weaknesses later complicate NHI, autonomous, and human access governance.

By the numbers:

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

👉 Read Zluri's article on four ways to automate SaaS onboarding access

Context

SaaS onboarding is an identity governance problem before it is an efficiency problem. When new joiners need access to dozens of applications, manual provisioning quickly creates inconsistency, delays, and hidden access paths that IT can no longer track cleanly.

The article frames automation as the answer, but the deeper issue is coverage and control. If onboarding does not maintain visibility into every application, access request, and offboarding path, the organisation creates the same governance gaps that later affect NHI lifecycle management and broader identity operations.

Key questions

Q: How should security teams automate SaaS onboarding without losing access control?

A: Start with a complete application inventory, then map standard access by role and department. Automate the repeatable parts, such as app assignment and group membership, but keep exceptions visible and reviewable. The goal is not just faster provisioning. It is repeatable access decisions that can also be reversed cleanly when the employee leaves.

Q: Why does SSO not solve all SaaS onboarding problems?

A: SSO centralises login, but it does not cover every application or every entitlement. Many SaaS tools sit outside the SSO boundary, and some permissions are still controlled inside the app itself. Teams still need discovery, workflow, and lifecycle governance to avoid leaving large parts of the access estate unmanaged.

Q: What breaks when onboarding access is still handled manually?

A: Manual onboarding breaks consistency. Different admins make different decisions, apps get missed, and employees wait for access or self-provision tools on their own. That creates shadow IT, inconsistent entitlements, and poor auditability. Over time, the organisation loses confidence that access was granted on policy rather than convenience.

Q: How do IAM teams know whether SaaS provisioning is actually governed?

A: Look for a current application inventory, documented role patterns, visible approvals, and the ability to revoke the same access later. If onboarding depends on memory, spreadsheets, or manual follow-up, it is not governed. A controlled process should show who got access, why they got it, and how it will be removed.

Technical breakdown

Why manual SaaS provisioning does not scale

Manual provisioning depends on people knowing the right apps, the right role, and the right timing for every joiner. That works only when app portfolios are small and stable. As soon as a company grows, manual assignment becomes fragmented, request-driven, and inconsistent across teams. It also creates a hidden policy problem because access is often granted based on who asks fastest, not on governed entitlement logic. In practice, that means onboarding becomes a mixture of provisioning, exception handling, and shadow IT intake rather than controlled identity lifecycle management.

Practical implication: define which joiner access decisions must be policy-driven rather than ticket-driven.

What SSO solves and what it leaves behind

SSO reduces credential friction by centralising authentication, but it does not automatically solve application coverage. Many SaaS apps sit outside the SSO boundary or are connected imperfectly, which leaves a large portion of the access estate governed through separate workflows. That matters because authentication centralisation is not the same as entitlement governance. You may have one login path and still have dozens of unmanaged access paths, approvals, and application-specific permissions that SSO never touches.

Practical implication: map SSO coverage against the full application estate before assuming onboarding is controlled.

How SaaS management platforms change onboarding control

A SaaS management platform extends onboarding beyond sign-in by discovering applications, suggesting access, and creating reusable workflows. The architectural shift is from isolated provisioning actions to a governed workflow that can include apps, groups, channels, and licenses. That makes lifecycle management more repeatable, but only if the underlying inventory is accurate and continuously updated. Without that inventory, automation can still reproduce gaps at scale. The key technical point is that workflow automation is only as good as discovery and entitlement mapping.

Practical implication: pair workflow automation with continuous application discovery and entitlement review.

NHI Mgmt Group analysis

Manual onboarding is an identity governance bottleneck, not just an admin burden. The article shows that access assignment becomes unreliable once app counts rise and requests multiply. That is a lifecycle failure as much as an operational one, because identity decisions are being made too late and too inconsistently. The practitioner takeaway is that onboarding must be treated as governed access distribution, not ad hoc fulfilment.

SSO is only a partial control plane for SaaS access. Centralised authentication can reduce password friction, but it does not cover the full application estate. The article’s own 30% estimate for SaaS coverage highlights the structural gap between login control and entitlement control. Practitioners should not confuse authentication consolidation with complete access governance.

Application discovery is the prerequisite for any credible onboarding workflow. If the organisation does not know which SaaS tools exist, it cannot claim to provision them consistently or revoke them cleanly later. This is the same governance logic that underpins NHI visibility and lifecycle control. The practitioner implication is simple: discovery first, workflow automation second.

Shadow IT emerges when access friction outpaces governance design. When employees cannot get the right tools quickly, they route around process and self-provision elsewhere. That creates both cost and control exposure, because unmanaged apps become unmanaged identities. The lesson for identity teams is to reduce delay without losing approval boundaries.

Onboarding playbooks create repeatability, but only when entitlement logic is standardised. Reusable workflows are useful because they reduce variation between similar roles. But if role definitions, app suggestions, and approvals are inconsistent, the playbook simply codifies bad decisions faster. The practitioner conclusion is that workflow design must be anchored in role and entitlement governance, not convenience alone.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• For a broader lifecycle lens, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns.

What this signals

The onboarding pattern described here is likely to spread across identity operations as organisations try to remove manual work from joiner flows. The programme risk is that automation gets implemented before the entitlement model is stable, which turns speed into scale for bad decisions rather than better control.

Access coverage gap: organisations that cannot see the full application estate will keep discovering missing entitlements after onboarding is supposedly complete. That gap is especially important where SaaS sprawl, shadow IT, and decentralised procurement overlap.

Teams should treat the same workflow discipline as a future requirement for non-human access flows, especially as machine identities and agentic systems increasingly need governed onboarding, approval, and offboarding paths.

For practitioners

• Build a complete SaaS inventory before automating onboarding Use discovery methods, procurement records, and user feedback to identify the full application estate. Automation should only start once the inventory is current enough to support onboarding and offboarding decisions.
• Map onboarding workflows to role-based entitlement logic Define which apps, groups, and permissions are standard for each job family, then make exceptions explicit. This reduces one-off provisioning and makes onboarding repeatable across teams.
• Measure SSO coverage against the real app estate Compare what sits behind SSO with the total number of SaaS tools in use. If large segments remain outside SSO, treat those applications as separate governance paths that need their own controls.
• Connect onboarding and offboarding into the same lifecycle flow Use the same governance model for joiners and leavers so that access granted at day one can also be revoked cleanly at exit. This helps prevent lingering app access and reduces manual cleanup.

Key takeaways

• SaaS onboarding becomes a governance problem once app counts rise, because manual access decisions no longer scale cleanly.
• SSO reduces login friction, but application discovery and entitlement mapping are still required to control the full access estate.
• The safest automation strategy is to standardise role-based provisioning first and then connect onboarding to offboarding in the same lifecycle flow.

Key terms

• SaaS Provisioning: The process of granting a user access to cloud applications and related entitlements when they join or change roles. In practice, it includes apps, groups, licenses, and in-app permissions, not just login creation. The control challenge is making those decisions repeatable, visible, and reversible.
• Single Sign-On: A central authentication method that lets users log in once and reach multiple applications. It simplifies access, but it does not automatically govern all application-specific permissions or cover every SaaS tool in use. Teams still need discovery and lifecycle controls around the apps outside the SSO boundary.
• Shadow IT: Software or services adopted without formal IT approval or visibility. In identity terms, it creates unmanaged access paths because the organisation cannot confidently govern, review, or revoke what it does not know exists. Shadow IT often appears when approved onboarding is too slow or incomplete.
• Identity Lifecycle Management: The set of governance processes that manage access from joiner to mover to leaver. It covers provisioning, changes, reviews, and revocation across human and non-human identities. The core objective is to keep access aligned to current need while ensuring old access is removed reliably.

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 lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Automation 4 ways of giving quick access to tools while onboarding employees. Read the original.