TL;DR: The hard part of user provisioning is no longer SCIM-covered apps but the long tail of GitHub teams, AWS roles, and other systems that still need approvals, custom APIs, or manual tasks, according to Serval’s guide. The governance issue is not automation itself but matching removal, logging, and approval controls to the way access is actually granted.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Serval's blog post: User provisioning beyond SCIM remains a governance problem because the systems that stay manual need matched grant and removal controls.
Why it matters: IAM teams need to treat provisioning as a lifecycle control problem, not just an integration problem, because manual access paths are where approval, offboarding, and audit gaps persist.
Context
User provisioning breaks down when the access model is split across identity providers, help desks, and application-specific workflows. SCIM covers only the apps that support it, while the real governance burden sits with the systems that need approvals, role-specific removal, or custom API calls.
For help desk-led provisioning, the gap is not whether a ticket can be closed. The gap is whether the grant, approval, and offboarding path stays consistent across SaaS apps, engineering tools, and time-bound access requests. That is where access governance becomes a joiner-mover-leaver problem rather than a simple workflow problem.
Key questions
Q: How should teams govern provisioning when some applications do not support SCIM?
A: Teams should treat SCIM as the preferred standard but plan for a mediation layer where native support is missing. The key is to keep policy, approval, and audit control in one place rather than letting each downstream system handle identity changes differently. That approach reduces manual exceptions and makes provisioning behaviour easier to govern across mixed application estates.
Q: Why do helpdesk workflows create access governance risk?
A: They sit at the point where user identity, entitlement approval, and provisioning intersect. If those workflows rely on email chains, informal follow-up, or broad approval rules, the organisation can grant access without a durable control record. That turns the helpdesk into an access decision layer rather than a service layer.
Q: How do API-based provisioning workflows affect offboarding?
A: API-based provisioning workflows make offboarding faster and more reliable because they can automatically remove accounts, revoke API keys, disable tokens, and clear group memberships across connected systems. They also create a control point for deprovisioning logs and failed revocations, which matter when service accounts, bots, or contractor access still exist after HR exit or application closure.
Q: What is the best way to compare SCIM and custom provisioning?
A: SCIM is a standard provisioning protocol, while custom provisioning is application-specific automation built with APIs, scripts, or middleware. Compare them by coverage, attribute mapping, error handling, lifecycle events, and who owns maintenance. SCIM usually suits common joiner-mover-leaver flows, whereas custom provisioning is often needed for non-standard entitlements, service accounts, or systems that do not support SCIM.
Technical breakdown
Why SCIM stops short in real provisioning estates
SCIM automates a defined provisioning contract between an identity provider and a target app, but many enterprise systems do not expose that contract cleanly. When a platform lacks SCIM, the provisioning path shifts to API calls, vendor-specific connectors, or manual action. That creates variation in identity lifecycle handling, because the grant mechanism changes from one system to the next. The practical challenge is not just connecting systems, but ensuring the same role, approval, and revocation logic survives those different execution paths. See the SCIM and Automated Provisioning Guide.
Practical implication: Treat SCIM as one provisioning pattern, not the whole control model.
Why help desk workflows become the control point for access
Help desk tooling becomes the control point when employees request access in Slack, Teams, or a ticketing portal and approvers decide whether access exists, how long it lasts, and what evidence is logged. That means the workflow is not just intake. It is the effective entitlement decision layer for systems outside the identity provider’s native reach. If that layer is inconsistent, provisioning, expiration, and deprovisioning diverge even when the upstream identity source is stable. See the Account Recovery and Help Desk Security Guide.
Practical implication: Design help desk workflows so approvals, expiries, and removals are enforced as one lifecycle path.
How custom API provisioning changes offboarding risk
Custom API provisioning extends automation to applications that do not support SCIM, but it also increases governance dependence on the quality of the workflow and the API surface. A request that grants access through one method and removes it through another can leave residual access if the removal path is not equally mature. The same is true when one role uses a group sync and another uses a direct API call. Consistency matters because offboarding failures usually emerge at the weakest path, not the strongest one. See the Joiner-Mover-Leaver (JML) Guide.
Practical implication: Map every grant method to an equally explicit removal method before it enters production.
Breaches seen in the wild
- Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.
- 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 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Provisioning is now a lifecycle governance problem, not a connector problem. The core issue in this topic is that access paths split across SCIM, APIs, help desk workflows, and manual tasks create uneven control states. Identity teams may believe they have one provisioning process, but they often have several different enforcement models with different failure modes. That is why the real question is whether every grant path has the same revocation, logging, and approval discipline.
Manual exceptions are where offboarding discipline weakens first. When an app sits outside the identity provider’s native reach, teams are tempted to treat the exception as operational rather than structural. That is a mistake because the exception becomes the place where removal is easiest to miss and hardest to audit. The practitioner lesson is to identify which access paths depend on humans to finish the lifecycle and then treat those paths as first-class governance objects.
Request systems are effectively entitlement policy engines when access is time-bound. Once approvals, time limits, and role mapping live in the help desk, the tool is no longer just a queue. It is the system that decides who gets access, for how long, and under what evidence. That makes policy consistency more important than interface convenience, especially where GitHub teams, AWS roles, and other non-SCIM targets are involved.
Joiner-mover-leaver control should be judged by removal quality, not request volume. A provisioning programme can appear efficient while still leaving stale access behind if offboarding logic is weaker than onboarding logic. The field should measure whether the same identity event that grants access also reliably removes it across the full application estate. That is the point at which governance moves from process volume to lifecycle integrity.
From our research library:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
- Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
- Read next: SCIM and Automated Provisioning Guide
What this signals
Manual access paths create a governance blind spot: the more provisioning depends on exceptions, the more likely revocation, evidence, and approval handling will diverge between systems. Identity programmes should watch for the point where workflow convenience begins to outrun lifecycle control.
When access requests move through help desk tooling, the real control question becomes whether the same role definition governs onboarding, temporary elevation, and removal. That is the difference between a ticketing workflow and a usable entitlement control plane.
The evidence already shows that secrets and access controls often break outside the main repository. According to the State of Secrets Sprawl 2026, 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
For practitioners
- Define a grant-and-removal matrix List each application, the method used to grant access, and the exact method used to remove it. Require a matching offboarding path for every provisioning route before it is accepted.
- Separate SCIM coverage from exception handling Document which systems are covered by native SCIM and which depend on API calls or manual tasks, then apply different governance checks to the exception set.
- Make approval and expiry policy role-specific Set approvers, justification requirements, and access durations per role rather than per ticket type, so the lifecycle logic follows the entitlement instead of the request channel.
- Audit manual provisioning for offboarding gaps Review the long tail of access tickets, especially GitHub teams, AWS roles, and custom applications, to confirm that removal is logged and actually executed when access ends.
Key takeaways
- User provisioning becomes brittle when grant methods, approval paths, and removal paths differ across systems.
- Manual and exception-based access flows are where lifecycle control most often weakens, especially for offboarding.
- The control objective is symmetry: every access path needs a matching removal path and auditable evidence.
Related NHI Mgmt Group resources: Joiner-Mover-Leaver (JML) Guide · Workforce Identity Security Guide · SCIM and Automated Provisioning Guide · Account Recovery and Help Desk Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Manual provisioning paths are most likely to fail when access must be removed after the request ends. |
| NHI-05 — Overprivileged NHI | Role-based provisioning across APIs and groups can over-assign access when entitlement scope is not controlled. | |
| NHI-07 — Long-Lived Secrets | Custom API provisioning often depends on credentials that persist longer than the access they create. | |
| Recommendation — Map every grant route to a tested offboarding route and verify removal evidence before closing the request. Limit each provisioning path to the minimum role or group assignment needed for the business task. Rotate and inventory the credentials used for custom provisioning workflows so they do not become standing access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The topic is about governing entitlements across multiple provisioning mechanisms. |
| Recommendation — Apply entitlement governance to each provisioning path and verify that permissions match approved access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Provisioning and deprovisioning are core account management activities across help desk workflows. |
| Recommendation — Track account creation, modification, and removal across all systems and reconcile exceptions promptly. | ||
Key terms
- User Provisioning: User provisioning is the process of creating, changing, and removing access rights across systems. In practice, it includes account creation, role assignment, permission updates, and deprovisioning. The security value comes from keeping access aligned to current business need throughout the identity lifecycle.
- Scim: System for Cross-domain Identity Management is the standard used to exchange user and group lifecycle data between an identity provider and an application. In production, the protocol only solves part of the problem. The harder issue is whether the implementation preserves attributes, order, and tenant scope consistently across real directory sources.
- Joiner Mover Leaver: Joiner Mover Leaver is the identity lifecycle process for creating, changing, and removing access as people enter, change roles, or leave an organization. It governs provisioning, modification, and deprovisioning across systems, ensuring access matches current job needs and reducing orphaned accounts, privilege creep, and residual access risk.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
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.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org