Topic starter
22/06/2026 3:43 pm
TL;DR: SCIM can standardise cloud provisioning, but many enterprise applications still lack native support, forcing organisations to bridge Azure to legacy and custom systems through an intermediary layer, according to EmpowerID. The governance issue is not automation itself but where policy, approval, and lifecycle control sit when identity changes must flow across non-SCIM applications.
Editorial analysis by NHI Mgmt Group, based on content published by EmpowerID: “Revolutionizing Azure integration with EmpowerID's SCIM Virtual Directory!”.
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 non-SCIM applications create governance risk in Azure provisioning?
A: Because the control point shifts away from a single identity workflow and into application-specific handling.
Q: What breaks when provisioning is treated as a fire-and-forget integration?
A: Governance breaks first.
Practitioner guidance
- Map every non-SCIM application in scope Inventory custom, legacy and vendor applications that cannot consume native SCIM and document which identity lifecycle events still need a mediation path.
- Separate transport from policy enforcement Define which provisioning rules must execute in the intermediary layer rather than inside the target application so workflow, approval and naming logic stay consistent.
- Route joiner-mover-leaver events through one governed path Make the mediation layer the default control point for provisioning, updates and removals so each lifecycle change follows the same approval and logging model.
Bottom line: SCIM can standardise provisioning, but it does not remove the governance burden when applications cannot consume it natively.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/06/2026 3:48 pm
SCIM mediation is now a governance pattern, not just an integration pattern: When Azure provisioning has to reach systems that do not natively support SCIM, the real issue becomes control placement. The article shows that the intermediary is where policy, naming conventions, approval and workflow logic can be enforced before identity changes land downstream. For IAM teams, the architectural question is where the authoritative decision is made, not whether the target system can accept a SCIM payload.
A few things that frame the scale:
- 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: When should teams use workflow mediation instead of direct SCIM provisioning?
A: Use mediation when the target application cannot speak SCIM natively, when policy must be evaluated before the change lands, or when multiple repositories need one consistent lifecycle process. Direct provisioning only makes sense where equivalent governance already exists.
👉 Read our full editorial: SCIM workflow mediation changes how Azure provisioning is governed