The instinct to build this yourself is a good signal that the problem is real. Automating user provisioning, deprovisioning, and access attestations is genuinely one of the most expensive unsolved problems in IT operations — and the reason most companies are still doing it manually isn't that they haven't thought about automating it. It's that the automation is harder to build than it looks, and the gap between a working script and a production-grade system is where most internal projects stall.

If you're evaluating whether to build a user access management system or adopt a platform that already solves it, understanding what the build actually requires is the right starting point.

Why This Problem Is Worth Solving

Orphaned accounts and shadow IT. When an employee leaves, most IT teams disable their SSO account and consider offboarding done. The problem is that a significant share of enterprise SaaS tools are procured outside centralized IT channels — and because they're not tied to SSO, disabling the Okta or Entra ID account doesn't touch them. The user's account in those tools stays active, the license keeps running, and the credentials remain valid. Automated deprovisioning that goes beyond SSO — that actually discovers and revokes access across the full app stack, not just the federated portion — is what closes that gap.

Access attestations and compliance. SOC 2, ISO 27001, and HIPAA all require regular user access reviews. The manual version of this looks like downloading user lists from each application, running VLOOKUPs against the HR directory to verify employment status, screenshotting evidence, and chasing department heads for approvals over email. For a company with 50 applications and 200 users, this consumes weeks of IT and compliance team time every review cycle. A system that automates the data collection, routes review requests to the right managers, captures the approvals, and generates an auditor-ready report turns a weeks-long project into a scheduled workflow.

The mover phase. Joiner and leaver automation is where most scripts start and end. The mover scenario — an employee changing roles or departments — is the hardest part and the most commonly skipped. When someone moves from Engineering to Sales, two things need to happen simultaneously: access tied to their previous role gets revoked, and access appropriate for the new role gets provisioned. Without automation, this either requires two separate tickets handled by different teams, or it doesn't happen at all and the employee accumulates access across every role they've ever held. Entitlement entropy is the technical term; "this person somehow has admin access to six systems they haven't used in two years" is what it looks like in practice.

What Building This Actually Requires

The problems that simple scripts can't handle are worth understanding before deciding whether to build.

SCIM isn't enough. SCIM is the right protocol for provisioning when the downstream application supports it. The problem is that SCIM adoption across the SaaS industry is lower than it should be. A large share of the applications in any enterprise stack don't implement SCIM. Building a viable provisioning system means building and maintaining direct API integrations for each non-SCIM app individually — and for applications that have no API at all, advanced platforms have to fall back to browser automation that navigates the admin UI the way a human would. The SCIM spec is the easy part of the integration problem.

Granular entitlements, not just account creation. Provisioning can't stop at creating or deleting an account. The system needs to handle what the account can do — assigning the correct role tier, mapping the user to the right security groups, downgrading an Admin to a Viewer when a role changes, granting access to specific resources rather than the whole application. This is the authorization layer, and it's application-specific. What "Viewer" means in Salesforce is different from what it means in GitHub, and the API calls to set it are different too.

Immutable audit trails. Access attestations are auditor-facing artifacts. The log that proves a specific user's access was reviewed, approved, and either retained or revoked needs to be timestamped, tamper-proof, and queryable by auditor without requiring IT to reconstruct the record from memory or Slack history. Building this correctly — with enough detail to satisfy a SOC 2 auditor's questions about a specific user's access history — is a non-trivial engineering problem.

Ongoing maintenance. APIs change. Authentication methods rotate. Applications add new permission tiers. Every connector your system depends on is something that needs to be updated when the downstream app changes its behavior. For a handful of internal tools with stable APIs, this is manageable. At 50 or 100 applications, maintaining the connector layer becomes its own operational burden that competes with building new features.

How Zluri Handles the Full Access Management Lifecycle

Zluri is built to solve exactly the problem you've described — and specifically to handle the parts that internal scripts and tools typically don't reach.

For the joiner flow, Zluri connects to your HRMS as the source of truth. When a new hire is added, an Onboarding Playbook runs automatically — provisioning accounts, assigning licenses, and adding the user to the correct groups across every connected application based on their role and department. For apps with native API integrations, this happens without any manual step. For apps outside the native library, custom HTTP Request actions handle the API call. For apps with no API at all, AI-powered browser automation executes the provisioning action in the application's admin interface.

For the mover flow, Zluri detects attribute changes in the HRMS — department, title, manager — and triggers a workflow that simultaneously deprovisions access tied to the previous role and provisions the access appropriate for the new one. Both sides of the transition run in the same automated workflow, not two separate tickets.

For the leaver flow, Zluri's Discovery Engine maps every application a user has access to — including tools that were never formally provisioned through IT — before the offboarding playbook runs. The deprovisioning scope covers the full access footprint, not just the SSO-connected applications.

For access attestations, Zluri schedules automated review campaigns that route access decisions to the right managers — app owners, department heads, or reporting managers depending on how you configure the workflow. Managers review and approve or revoke access directly from a Slack message or email. Every decision is logged with a timestamp. The output is an auditor-ready access review record generated without anyone downloading spreadsheets or chasing approvals manually.

Build vs. Adopt: The Honest Framing

Building this as an internal tool is a legitimate choice if your app stack is small, stable, and well-documented at the API level. Scripts that handle a handful of well-integrated applications are entirely viable and worth writing.

The case for adopting a platform gets stronger as the app count grows, as the mover and attestation requirements become compliance-driven rather than just operational, and as the maintenance burden of per-app connectors starts competing with other IT priorities. The engineering problem you're solving is the same one Zluri has already solved across 300+ application integrations — the question is whether it's a better use of your team's time to build and maintain those connectors or to deploy a platform that already has them.

Neither answer is wrong. The right one depends on your scale, your compliance requirements, and how much of your team's time you want allocated to maintaining identity infrastructure versus using it.

Frequently Asked Questions

What is the difference between user provisioning and access attestation?

User provisioning is the process of granting and revoking access as part of the employee lifecycle — creating accounts for new hires, updating access when roles change, and removing access when employees leave. Access attestation is a periodic compliance process where managers review and certify that their team members' current access is still appropriate. Both are required for SOC 2, ISO 27001, and HIPAA compliance — provisioning keeps access current, attestation provides the audit evidence that access is being reviewed.

What is entitlement entropy in identity management?

Entitlement entropy is the accumulation of access permissions over time as employees change roles, join projects, and are granted temporary access that never gets revoked. Over time, employees end up with admin privileges or application access from roles they left months or years ago. This creates both a security risk and a compliance exposure — particularly when an access review reveals that a current employee has access they shouldn't have, or when an offboarded employee's accounts in non-SSO apps were never cleaned up.

Why isn't SCIM enough for enterprise user provisioning?

SCIM standardizes how identity providers communicate user lifecycle events to applications, but many enterprise SaaS tools don't implement SCIM. For these applications, provisioning requires direct API integrations built and maintained per app — or, for tools with no API, browser automation. An IGA platform maintains these integrations across hundreds of applications so your team doesn't have to build and update them individually.

What does an auditor-ready access review report include?

A compliant access review record needs to show which users had access to which applications, who reviewed that access, what decision was made (retain or revoke), when the decision was made, and what action was taken as a result. It needs to be timestamped and tamper-proof. Generating this manually from spreadsheets and screenshots is the standard approach — automating the collection, review routing, decision capture, and report generation is what platforms like Zluri provide.

See How Zluri Maps to Your Current App Stack and Compliance Requirements

If you're deciding whether to build this or adopt a platform that already handles the connector maintenance, see how Zluri maps to your current app stack and compliance requirements — including which applications are covered natively and where the custom HTTP Request or browser automation path applies.