SaaS user provisioning is rarely treated as a discipline. Most Australian IT teams handle it reactively: a new hire starts, a ticket goes in, accounts get created. A person leaves, and the offboarding ticket lands days later, if it lands at all. That gap between arrival and departure is where access sprawl begins, and where breach investigators keep finding the bodies.
The problem isn't that teams don't care. It's that provisioning has no natural owner. HR controls the employee lifecycle. IT controls the tools. Neither fully owns the intersection. The result is a growing list of accounts that don't match the current state of the business.
What goes wrong in practice
The most common failure is orphaned accounts: active SaaS logins attached to people who have left. In a stack of 20 platforms, even a competent offboarding process will miss a few. Multiply that across a year of turnover and the problem compounds fast. One lapsed account in a CRM, a finance platform, or a document store is all a threat actor needs.
The second failure is over-provisioning. IT teams default to the role that's easiest to create, not the role that fits the job. A marketing contractor gets admin access to a project management tool because the team lead asked for "full access." That access persists for six months after the contract ends. This isn't negligence: it's the predictable result of no formal process for tiered provisioning.
Third is inconsistent identity sources. When provisioning decisions are driven by a mix of HR systems, spreadsheets, and direct manager requests, there's no single source of truth. The same person might exist in Salesforce under a personal email, in Slack under a work alias, and in the VPN logs under their employee number. Reconciling those identities during an incident is slow and error-prone.
Why SCIM adoption has stalled
Most enterprise SaaS platforms now support the SCIM protocol (System for Cross-domain Identity Management), which automates provisioning and deprovisioning through a direct feed from your identity provider. When it works, a user created in your IdP appears in all connected SaaS tools within minutes. When their account is disabled, it propagates everywhere automatically.
The problem is adoption. SCIM requires a mature identity provider setup, and many Australian mid-market organisations are still running hybrid Active Directory environments that weren't designed for this. Configuring SCIM for one platform takes an afternoon. Doing it for 15 platforms, each with slightly different attribute mappings and quirks, takes months. Teams start the project, get interrupted by operational priorities, and the partially-configured state quietly becomes permanent.
The organisations that have made it work tend to start with a short list. Pick 4 or 5 high-risk, high-volume platforms first: your CRM, your HR system, your cloud storage, and your communication tools. Get SCIM working cleanly on those before expanding. Completeness is the enemy of progress here.
The role of your SSO rollout
Single sign-on and provisioning are related but distinct. SSO controls how users authenticate. Provisioning controls whether an account exists at all. Teams that roll out SSO without addressing provisioning often find they've created a false sense of control: you can see who's logging in, but you can't see the dormant accounts that never touch SSO because they authenticate directly.
This is a common gap that surfaces during audits. A well-run SSO rollout should enforce SSO as the only authentication path for every connected platform. If a vendor allows both SSO and native login, the native login becomes a backdoor. Force SSO, disable native passwords, and then provisioning becomes the actual control surface.
What a mature provisioning process looks like
Mature provisioning has three characteristics that most Australian IT teams are missing.
The first is a single authoritative source. Your HR system should be the trigger for all provisioning events: hire, role change, team transfer, termination. Every access decision flows from that record, not from a Slack message or a manager's email.
The second is role-based access profiles. Instead of provisioning individual users manually, you define access profiles for each role in the business. A new account manager gets a defined set of tools at defined permission levels. No negotiation, no defaults. When their role changes, the profile changes with it.
The third is a regular access review cycle. Quarterly is practical for most organisations. Every manager reviews the active accounts in their team against current staff. This catches the cases that automated deprovisioning misses: contractors whose end date wasn't recorded, secondments that became permanent, tools provisioned for a project that ended.
How provisioning connects to broader SaaS governance
Provisioning doesn't exist in isolation. It sits at the intersection of identity management, license spend, and security posture. An account that exists but shouldn't be active is both a security risk and a wasted license. Australian IT teams spending time on SaaS license management often find that their first step is deprovisioning: removing accounts that are active in the vendor's billing system but attached to people who left months ago.
The tooling to manage this has improved. Platforms like BetterCloud and Torii connect to your SaaS stack and surface orphaned accounts, shadow apps, and usage data. They don't replace a provisioning process, but they give you visibility into the current state of your environment, which is the prerequisite for fixing it.
The honest starting point for most Australian IT teams isn't a tool purchase. It's a discovery exercise: connect to your identity provider, pull a list of active accounts, and compare it against your current employee list. What you find will be uncomfortable. That discomfort is the reason to take provisioning seriously before an auditor or an incident investigation forces the conversation.