Notifications
Clear all
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.
NHIMG editorial — based on content published by EmpowerID: SCIM workflow mediation for Azure provisioning and non-SCIM applications
Questions worth separating out
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 identity governance risk?
A: Non-SCIM applications create risk because they force organisations into custom integration patterns that are harder to standardise, review, and decommission.
Q: What breaks when provisioning is treated as a fire-and-forget integration?
A: Governance breaks first.
Practitioner guidance
- Map every non-SCIM dependency in the provisioning chain Document which Azure provisioning flows terminate in native SCIM targets and which rely on a mediation layer or custom connector.
- Define the approval boundary before fulfilment begins Require that any workflow mediation layer evaluates policy violations, naming rules, and approval gates before it writes changes to downstream systems.
- Treat the provisioning intermediary as a privileged system Apply tighter access scope, stronger logging, and change control to the intermediary service than to ordinary business applications.
What's in the full article
EmpowerID's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step deployment flow for the SCIM Virtual Directory Server in Azure tenants
- How the intermediary maps provisioning requests to registered applications without native SCIM support
- Workflow evaluation logic for approvals, naming rules, and policy violations before fulfilment
- Implementation context for integrating SAP, HR, and custom applications through the mediation layer
👉 Read EmpowerID's article on SCIM mediation for Azure provisioning →
SCIM provisioning in Azure: what changes for IAM teams?
Explore further
22/06/2026 3:48 pm
SCIM adoption has become a governance problem, not just an integration problem. When applications do not support SCIM natively, identity teams lose a uniform lifecycle path and fall back to bespoke connectors, manual exceptions, or vendor-dependent timelines. That fragmentation makes provisioning consistency harder to prove and harder to audit. The practitioner conclusion is that SCIM coverage should be treated as part of identity control design, not as an optional engineering convenience.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: How can IAM teams decide whether a virtual directory should be privileged?
A: If the intermediary can route identity changes to many applications, it should be handled as a privileged administrative path. IAM teams should review who can edit routing, which applications are registered, and whether service authentication is scoped tightly enough. The decision hinges on blast radius, not convenience.
👉 Read our full editorial: SCIM workflow mediation changes how Azure provisioning is governed
