Topic starter
06/11/2026 6:37 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Serval: “The best user provisioning tools for IT teams, for apps with or without SCIM”.
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.
Q: Why do helpdesk workflows create access governance risk?
A: They sit at the point where user identity, entitlement approval, and provisioning intersect.
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.
Practitioner guidance
- Define a grant-and-removal matrix List each application, the method used to grant access, and the exact method used to remove it.
- 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.
Bottom line: User provisioning becomes brittle when grant methods, approval paths, and removal paths differ across systems.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: User provisioning beyond SCIM: what help desk teams still need