Access Provisioning: The 90% of Provisioning Nobody Talks About

Your new hire can log into 20 applications. They can't do anything in any of them. The difference between 'provisioned' and 'productive' is a Layer 3 problem—and SCIM, your SSO, and most IGA tools stop at Layer 2.

Your SSO provisions accounts to 20 applications in 2 minutes. Configuring actual permissions in those 20 applications takes 3 hours. Guess which part you automated?

Most companies think they've automated provisioning. They haven't. They've automated account creation—which is 18% of the work.

This isn't a semantic argument about terminology. This is about the gap between what your provisioning tools claim to do and what they actually deliver. And that gap costs you productivity, security, and sanity.

What Actually Happens When You "Provision" Someone

Here's what happens at most companies when they claim to have "automated provisioning":

Day 1 Morning:

• IT adds new engineer Josh to Okta
• SCIM syncs Josh to 12 applications
• Josh receives 12 welcome emails: "You've been added to GitHub!" "You've been added to Jira!"
• Josh logs into each application successfully
• IT dashboard shows: Provisioned ✓

Day 1 Afternoon:

• Josh can't access any GitHub repositories
• Can't see the Platform Team project in Jira
• Can't view team channels in Slack
• Can't open design files in Figma

He's inside the building, but every door is locked. The dashboard says "Provisioned." Josh says "I can't do anything."

What follows is a week of tickets, guesses, and wrong permission levels—Josh ends up with Write access to a production repository when he needed Read access to review code. Not because anyone was careless. Because nobody knew what permission level he needed, and the tools that "provisioned" him never asked.

This is the gap between user provisioning (creating accounts) and access provisioning (granting useful permissions).

The Three Layers: Where Your Tools Stop and Real Work Begins

Let's trace what actually needs to happen when provisioning someone:

Layer 1: Identity Creation (Who Are You?)

What happens:

• Create user account in system
• Set core attributes: name, email, employee ID
• Assign username and authentication credentials
• Link to identity provider for SSO

Tools that handle this: Okta, Google Workspace, Azure AD Protocol: SCIM works perfectly here Industry coverage:Excellent (95% of companies automate this) Zluri approach: Integrates with existing identity providers, doesn't replace them

Layer 2: Application Access (Can You Log In?)

What happens:

• Grant login access to application
• Add user to application-level groups (Engineering, Marketing, Sales)
• Assign license (Free, Pro, Enterprise)
• Enable SSO/SAML integration
• Sync basic group memberships

Protocol: SCIM (System for Cross-domain Identity Management) Industry coverage: Good (70% of companies automate this)

What SCIM handles well:

POST /Users

{
 "userName": "josh.smith@company.com",
 "name": {"givenName": "Josh", "familyName": "Smith"},
 "emails": [{"value": "josh.smith@company.com"}],
 "groups": ["Engineering", "Platform-Team"]
}

Creates account, adds to groups, assigns license. Perfect for Layer 1 and Layer 2.

Where SCIM stops: There is no SCIM endpoint for:

• Granting access to specific GitHub repository with Maintain permissions
• Adding user to specific Jira project with Developer role
• Sharing specific Google Drive folder with Editor access
• Inviting user to specific Slack channels
• Configuring AWS IAM permissions for specific environments

That's not a limitation of implementation. That's a limitation of the SCIM protocol itself.

Zluri approach: Leverages SCIM for Layers 1-2, uses direct API integration for Layer 3

Layer 3: Permission Configuration (What Can You Do?)

What happens:

• Grant permissions within application (not just access to application)
• Assign to specific projects, repositories, folders, teams
• Set permission level (Read, Write, Admin, Maintain, Custom Roles)
• Configure resource-level access controls
• Define scope boundaries (which resources, not all resources)

Tools that handle this: Almost none Protocol: SCIM doesn't work here—requires application-specific APIs Industry coverage: Terrible (10% automate, 90% manual)

Examples of granular permissions:

GitHub (5 permission levels per repository):

• Read: View code, clone repo
• Triage: Manage issues without code access
• Write: Push to protected branches with approval
• Maintain: Manage repo settings (can't delete)
• Admin: Full control including delete

Jira (project-level roles):

• Browse Projects: See project and issues
• Create Issues: Log new issues
• Edit Issues: Modify content
• Assign Issues: Assign to team members
• Administer Projects: Change project settings
• Plus: Custom permission schemes per project

AWS (IAM roles per environment):

• ReadOnly: View resources, no changes
• PowerUser: Modify resources, no IAM changes
• AdministratorAccess: Full control
• Custom policies: Specific service + action combinations

Slack (channel-level access):

• Public channels: Auto-join or invite-only
• Private channels: Must be invited by member
• Channel posting permissions: All members vs. admins only
• Guest access: External collaborators, limited channels

Salesforce (layered permission model):

• Profiles: Base permission sets
• Permission Sets: Additive permissions
• Role Hierarchy: Data visibility
• Sharing Rules: Record-level access
• Field-Level Security: Column-level access

Zluri approach: 300+ pre-built API integrations with 1,593 granular actions across applications. Not just "add user"—specific permissions like "Grant Write access to platform-api repository" or "Add to Platform Team project with Developer role"

This is where the gap lives. This is 82% of actual provisioning work.

The Real Math of Provisioning Josh

Layer 1-2 (SCIM Coverage):

• 5 applications: accounts created ✓
• 5 applications: basic group memberships ✓
• Time: 2 minutes (automated)
• Work: 0 hours

Layer 3 (What SCIM Can't Do):

• 23 specific permissions needed across those 5 apps
• GitHub: 3 repositories (platform-api: Maintain, platform-infra: Write, platform-docs: Write)
• Jira: 2 projects (Platform Team: Developer, Engineering Ops: Reporter)
• Slack: 4 channels (#platform-team, #engineering-all-hands, #incident-response, #platform-oncall)
• AWS: 3 environments (dev: PowerUser, staging: ReadOnly, prod: no standing access)
• Figma: 2 projects (Design System: View, Q4 Roadmap: Edit)

Manual execution: 4-6 hours (across multiple people, multiple tickets) API-based automation: 5 minutes

The reality: SCIM handles 18% of provisioning. APIs must handle the other 82%.

The Three Problems Nobody Solves

Problem 1: You Don't Know What Permissions People Actually Need

When someone asks: "What access does a Platform Engineer need?" most companies can answer at the app level—GitHub, Jira, AWS. Ask one level deeper—which repositories, which permission level, which projects—and the answer is guesswork.

The visibility-first approach:

Before provisioning anyone, map what people in similar roles actually use:

• What specific repositories, projects, channels do they access?
• What permission levels do they hold in each?
• Which permissions do they actually exercise vs. just have?

This requires continuous visibility, not point-in-time audits. Zluri's discovery engine tracks 9 billion permission events monthly to understand actual access patterns—not assumptions.

You can't provision what you can't see.

Problem 2: Everyone Over-Provisions By Default

One customer's IT admin told us: "When someone asks for GitHub access, I give them Write. Not because they need it—because if I give them Read and they need more, I get another ticket. Over-provisioning is faster than multiple approval rounds."

This is rational behavior given bad incentives:

The urgency asymmetry:

• Under-provision → immediate complaint, urgent escalation
• Over-provision → silent problem, discovered months later (if ever)

Result: 67% of granted permissions are never used (based on Zluri's analysis of 4,000+ customers).

The solution isn't better training. It's usage-based provisioning:

• Track what similar users actually use (not what they have)
• Provision based on real patterns
• Flag unused access after 90 days
• Auto-revoke dormant permissions

When provisioning is usage-driven instead of request-driven, you grant what people need, not what they might possibly need someday.

Problem 3: You Assume Provisioning Worked (It Didn't)

Traditional workflow:

1. Send provisioning API call
2. Receive 200 OK response
3. Mark as "Provisioned ✓"
4. User reports it didn't work 2 days later

What went wrong:

• API call succeeded, but permission wasn't actually granted (API bug)
• Permission was granted, then immediately revoked by conflicting policy
• Permission was granted at wrong level (gave Read, needed Write)
• Rate limit hit, request silently failed

APIs lie. Or more precisely: a 200 OK means "I received your request" not "I successfully provisioned access."

The verification loop:

After every provisioning action:

1. Send API call
2. Receive response
3. Query application to verify permission exists
4. If verified → mark complete
5. If not verified → retry with exponential backoff
6. If fails after 3 retries → alert IT for manual investigation

This requires read access to every application's API and verification logic for every permission type.

One customer told us: "Before Zluri, 30% of our provisioning 'completed successfully' but the user still couldn't access what they needed. We only found out when users complained. Now we verify every action, and our Day 1 productivity went from 60% to 95%."

Modern Access Provisioning Architecture

Access provisioning done right requires four systems working together:

1. Discovery Engine (Know Before You Provision)

Purpose: Map permission-level reality before making any provisioning decisions

Capabilities:

• Permission-level visibility (not just "has access" but "can edit this project")
• Usage tracking (active vs. dormant permissions)
• Pattern recognition (what permissions do similar users actually exercise)
• Entitlement mapping across applications (repos, projects, channels, roles)

Why it matters: You can't automate what you don't understand. Companies that skip this step automate chaos.

Zluri's approach: 9 discovery methods (SSO, browser extensions, finance integrations, APIs) capturing 9 billion permission events monthly. Not point-in-time—continuous.

2. Policy Engine (Decide What Access to Grant)

Purpose: Translate business rules into automated provisioning decisions

Capabilities:

• Attribute-based rules (role + department + team + seniority + location)
• Birthright access (automatic provisioning based on role)
• Just-in-time access (temporary elevated permissions)
• Time-bound policies (access that expires automatically)
• Exception handling (approval workflows for edge cases)

Example policy:

IF job_title = "Platform Engineer"

AND department = "Engineering"

AND team = "Platform"

THEN provision:

 GitHub:

   - platform-api: Maintain
   - platform-infra: Write
   - platform-docs: Write

 Jira:

   - Platform Team project: Developer

 AWS:

   - dev environment: PowerUser
   - staging: ReadOnly

 Slack:

   - #platform-team, #engineering-all-hands

No tickets. No approvals. No delays. Policy-driven.

Zluri's approach: Visual policy builder—IT teams configure without coding. If 50% of access requests need manual approval, policies are too narrow.

3. Execution Engine (Actually Provision the Access)

Purpose: Translate policies into actual permission changes across applications

Capabilities:

• Direct API integration
• Application-specific authentication
• Rate limiting and retry logic
• Idempotent operations (safe to retry)
• Parallel execution (provision 15 apps in 5 minutes, not 45 minutes)
• Error handling per application

The complexity nobody talks about:

Each application requires:

• Custom API authentication (OAuth, API keys, JWT, SAML)
• Different rate limits (GitHub: 5000/hour, varies by plan)
• Unique error codes and retry strategies
• Application-specific permission models

Engineering effort to build in-house:

• Initial integration: 20-40 hours per app
• Ongoing maintenance: 5-10 hours/month per app
• 50 applications = 1,000-2,000 hours initial + 250-500 hours/month ongoing
• That's 2-3 full-time engineers just maintaining integrations

Zluri's approach: 300+ pre-built API integrations, maintained by dedicated team. Available immediately, no engineering required.

4. Verification & Audit (Prove It Worked)

Purpose: Confirm provisioning succeeded and maintain compliance audit trail

Capabilities:

• Post-provisioning verification (query app to confirm)
• Automated retry on failure
• Complete audit logs (who provisioned what, when, why)
• Drift detection (access granted outside policies)
• Compliance reporting (SOC 2, ISO 27001, HIPAA)

Example verification flow:

// 1. Provision access

const provision = await github.addCollaborator('platform-api', 'josh.smith', 'maintain');

// 2. Verify it worked

const verify = await github.getPermission('platform-api', 'josh.smith');

// 3. Retry if failed

if (verify.permission !== 'maintain') {
 await retryWithBackoff(() =>
   github.addCollaborator('platform-api', 'josh.smith', 'maintain')
 );
}

‍

// 4. Log for audit

await audit.log({
 user: 'josh.smith',
 action: 'grant_repo_access',
 resource: 'platform-api',
 permission: 'maintain',
 triggered_by: 'onboarding_policy',
 timestamp: Date.now(),
 verified: true
});

Zluri's approach: Verification loops for every action. If provisioning fails, the system retries automatically. If retry fails, IT gets alerted with full context.

How the Four Systems Work Together

Let's trace complete provisioning for Josh:

Discovery Phase (Continuous, Before Josh Joins):

• System identifies baseline access for "Platform Engineers"
• Maps 23 specific permissions across 5 applications
• Tracks which permissions are actively used vs. just held
• Builds confidence scores (95% of Platform Engineers use platform-api)

Policy Evaluation (Triggered by HRMS):

• HR system marks Josh as hired (job_title: Platform Engineer, start_date: 2024-03-15)
• Policy engine evaluates applicable rules
• Determines birthright access (automatic, no approval)
• Queues 23 provisioning actions

Execution (Day 1, 9:00 AM):

• GitHub: Grant Maintain to platform-api, Write to platform-infra, Write to platform-docs (parallel API calls, 12 seconds total)
• Jira: Add to Platform Team project with Developer role (8 seconds)
• AWS: Attach PowerUser policy for dev, ReadOnly for staging (15 seconds)
• Slack: Invite to 4 channels (6 seconds)
• Figma: Grant View to Design System, Edit to Q4 Roadmap (9 seconds)
• Total: 50 seconds for 23 permissions across 5 apps

Verification (9:01 AM):

• System queries each application to confirm permissions
• GitHub: ✓ Verified (3 repos, correct permission levels)
• Jira: ✓ Verified (Platform Team project, Developer role)
• AWS: ✓ Verified (correct IAM policies attached)
• Slack: ✓ Verified (member of 4 channels)
• Figma: ✓ Verified (correct project permissions)

Audit Trail:

User: josh.smith
Action: onboarding
Timestamp: 2024-03-15 09:00:14 UTC
Triggered by: HRMS (new hire)
Policy: platform-engineer-baseline

Actions executed: 23
Success: 23
Failed: 0
Verification: 100% confirmed

Time to complete: 50 seconds

Josh logs in at 9:30 AM. Everything works. No tickets, no delays, no guessing.

This is what access provisioning actually means.

Why Most Companies Don't Do This

The gap exists because:

1. SSO providers told you SCIM "does provisioning"—it doesn't, it does identity sync
2. Building API integrations in-house requires 2-3 full-time engineers—most companies can't afford this
3. Traditional IGA tools (SailPoint, Saviynt) can do it—but require enterprise complexity, 6-12 month implementations, and dedicated IGA teams

The mid-market is stuck: too complex for manual processes, too small for enterprise IGA, and SSO doesn't actually solve the problem. (Why manual provisioning breaks at scale—the coordination math, the cost accumulation—is a story of its own. We cover it in our user provisioning guide.)

What Actually Works

Access provisioning at scale requires:

1. Visibility First Map existing permission patterns—who holds what, who uses what—before automating anything. You can't manage what you can't see.

2. Policy-Driven Automation 80% of provisioning should be automatic (birthright access based on role). 20% should require approval (sensitive access, exceptions).

3. API-Based Execution Direct API integration with applications to configure fine-grained permissions. SCIM for identity, APIs for everything else.

4. Continuous Verification Confirm every provisioning action succeeded. Detect drift. Auto-remediate when permissions change outside policies.

5. Usage-Based Refinement Track which permissions are used vs. held. Flag unused access. Revoke dormant permissions. Keep policies current.

This isn't aspirational. This is how access provisioning works when you use the right tools.

The bottom line: Access provisioning isn't creating accounts. It's granting specific permissions in specific systems at specific levels—so users can actually do their jobs from Day 1.

Most companies provision accounts and hope for the best. Best-in-class companies provision access and verify it worked.

The difference is productivity, security, and sanity.

Frequently Asked Questions

What is access provisioning?

Access provisioning is the process of granting specific permissions within applications—not just creating accounts or enabling login. It answers "what can this user do?" not just "can this user log in?" A user is provisioned at Layer 1 (account created) and Layer 2 (SSO enabled). They are access-provisioned at Layer 3: granted Write access to specific GitHub repositories, Developer role in specific Jira projects, and View access to specific Figma files. Most companies automate Layers 1–2 and leave Layer 3 entirely manual.

What is the difference between access provisioning and user provisioning?

User provisioning creates and manages user identities—accounts, attributes, group memberships—across systems. It's triggered by HR events (hire, transfer, terminate) and answers "does this user exist?" Access provisioning configures what that identity can do inside each application. It answers "what can this user do?" at the permission level. You can't have one without the other, but most tools—SCIM, SSO, basic HRIS integrations—only automate user provisioning. Access provisioning requires direct API integration with each application.

What is SCIM, and why doesn't it handle access provisioning?

SCIM (System for Cross-domain Identity Management) is a standard protocol for syncing identity data across systems. It handles account creation, attribute updates, group membership sync, and license assignment. What SCIM cannot do is configure application-specific permissions—repository access levels in GitHub, project roles in Jira, channel membership in Slack, or IAM policies in AWS. There is no SCIM endpoint for "grant Write access to platform-api repository." That's not an implementation gap—it's a protocol limitation. SCIM operates at the identity layer. Fine-grained permissions require application-specific APIs.

What is Layer 3 provisioning?

Layer 3 is fine-grained entitlement configuration—the actual permissions that determine what a user can do inside an application. Layer 1 is identity creation (account exists, SSO linked). Layer 2 is application access (user can log in, license assigned, added to groups). Layer 3 is permission configuration: Read vs Write vs Maintain on a specific GitHub repository, Developer vs Reporter vs Admin on a specific Jira project, PowerUser vs ReadOnly on a specific AWS environment. SCIM handles Layers 1 and 2. Layer 3 requires API-by-API integrations with each application's permission model.

Why do companies over-provision access by default?

Over-provisioning is a rational response to bad incentives. Under-provisioning generates immediate complaints and escalations. Over-provisioning creates a security problem that surfaces months later—if ever. When IT has no usage data to guide permission decisions, they grant the highest level that seems plausible to avoid follow-up tickets. Zluri's analysis of 4,000+ customers shows 67% of granted permissions are never used. The fix isn't better training—it's usage-based provisioning that matches permission levels to actual usage patterns rather than guesses.

Why does a 200 OK response not confirm that provisioning worked?

A 200 OK confirms the API received and accepted the request. It does not confirm the permission was applied. Common failure modes after a successful API call: the permission was applied but immediately revoked by a conflicting policy; the call hit a rate limit and was silently dropped; the permission was applied at the wrong level due to an API parameter mismatch; replication lag means the permission exists in the system but hasn't propagated to all nodes yet. Reliable access provisioning requires a verification loop—querying the application after provisioning to confirm the permission actually exists, with retry logic for failures.

What is birthright access in access provisioning?

Birthright access is the set of permissions granted automatically based on a user's role, department, and attributes—no request or approval required. For example: every Platform Engineer automatically gets Write access to platform-api, Developer role in the Platform Team Jira project, and membership in #platform-team Slack channel on Day 1. Access qualifies as birthright when it's consistent across a role (used by 80%+ of people in that role) and carries low security risk. The goal is 80% automatic birthright, 20% request-based with approval. If more than 30% of provisioning requires approval, policies are too narrow.

What is the difference between coarse-grained and fine-grained access provisioning?

Coarse-grained provisioning controls broad access: this user is in the "Engineering" group, has a "Pro" license, is a "Member" of the workspace. SCIM handles this well. Fine-grained provisioning controls specific entitlements: this user has Write access to platform-api but not platform-infra, Developer role in Platform Team project but Reporter role in Engineering Ops project, and PowerUser in dev but ReadOnly in staging. Fine-grained provisioning requires per-application API integration because every application has a unique permission model. GitHub has 5 levels. Jira has 7+ permission types per project. Salesforce has profiles, permission sets, role hierarchy, sharing rules, and field-level security—all operating simultaneously.

How do you build access provisioning policies that actually work?

Start with visibility, not assumptions. Pull actual usage data from existing users in each role—what permissions they hold, what they actively exercise. Identify the 80% that's consistent across a role (birthright candidates) and the 20% that varies (request-based candidates). Define policies based on observed patterns, not job title guesses. Version-control policies—track what changed, when, and why. Review quarterly using exception data: frequent approval requests that follow a pattern should become birthright access. Policies that go unchanged for a year are usually stale, not stable.

When should access provisioning require approval vs. happen automatically?

Automatic (no approval): Standard role-based permissions with low security risk—birthright access that 80%+ of the role uses, well-defined permission levels, no access to production data or sensitive systems. Approval required: Elevated permissions beyond the role baseline, access to production systems or sensitive data, cross-functional access (engineer accessing finance tools), temporary access for specific projects, any permission that creates SoD (segregation of duties) conflicts. The ratio to target: 80% automatic, 20% approval. Access requests as a category—user-initiated requests for specific tools or elevated permissions—are a distinct workflow. We cover that in our access request management guide.

‍