Entra ID's native SCIM provisioning is a solid foundation for managing user lifecycle in SSO-connected applications. For many organizations, it handles the bulk of provisioning and deprovisioning cleanly. But as environments grow more complex — more applications, more business units, more compliance requirements — the specific limitations of native Entra ID SCIM become operationally significant. Understanding what they are and why they exist is the first step to deciding whether to work around them or add a governance layer on top.

Limitation 1: Deprovisioning Doesn't Trigger Immediately on User Deletion

This is the most consequential limitation for offboarding workflows. When you delete a user from Entra ID, the account moves to a soft-deleted state and is retained for 30 days before permanent deletion. The SCIM DELETE payload to downstream applications is only sent at hard deletion — up to 30 days after the user was removed from the directory.

The practical implication: deleting a user from Entra ID does not immediately revoke their access in SCIM-connected applications. The account stays active in the downstream application until either the hard deletion occurs or an admin manually triggers removal.

The correct offboarding trigger in Entra ID is disabling (deactivating) the user, not deleting them. Disabling sends a SCIM PATCH with active: false to connected applications, which most applications process as immediate access revocation. Deletion should be treated as a cleanup action after the retention period, not as the offboarding signal.

For environments where offboarding is triggered by HR system events rather than manual Entra ID actions, this behavior requires the provisioning architecture to respond to the employment status change (termination in the HRIS) rather than relying on someone remembering to disable rather than delete the Entra ID account.

Limitation 2: Provisioning Logs Generate Noise for Unassigned Users

Entra ID's SCIM provisioning engine evaluates all users in the directory when running a provisioning job, even when the provisioning configuration is set to "Sync only assigned users and groups." Users who aren't assigned to the application are processed, evaluated, and logged as "skipped" — which is technically correct behavior but creates significant log noise that makes it harder to identify actual provisioning events.

Microsoft support has confirmed this is expected behavior. The internal logic is a filter stack: the provisioning job starts with all users in the directory, applies the "assigned users and groups" filter, then applies any additional custom scoping filters. The skipped log entries represent users who passed the initial evaluation but were excluded by the assignment filter.

For administrators who aren't aware that this is expected, the logs appear to show provisioning attempts for users who should never have been evaluated — which creates confusion about whether the provisioning configuration is working correctly and makes genuine errors harder to spot in a log full of expected skips.

The operational workaround is treating the "skipped" entries as expected noise and using custom scoping filters to reduce the evaluation pool where possible. For large directories with many unassigned users, this log volume can become significant enough that meaningful events require deliberate filtering to find.

Limitation 3: No Native Coverage for Non-SCIM Applications

Entra ID's provisioning engine is built around SCIM. For applications in Microsoft's app gallery that have published SCIM endpoints, provisioning configuration is relatively straightforward. For applications that don't support SCIM — whether because the vendor hasn't implemented it, because SCIM support is gated behind enterprise pricing tiers, or because the application is a legacy or custom-built tool — Entra ID's native provisioning has no path to automated lifecycle management.

This gap is larger than it appears. A significant portion of the SaaS applications in any organization's stack don't support SCIM. The "SSO tax" phenomenon — vendors charging enterprise pricing to unlock SCIM and SAML — means plenty of applications that could support SCIM don't for the organizations that haven't paid for enterprise tiers. Legacy applications and internal tools with no API surface aren't candidates for SCIM provisioning regardless of vendor pricing.

For these applications, Entra ID native provisioning provides no deprovisioning signal. When an employee leaves, the Entra ID account is disabled and SCIM-connected applications receive the active: false payload. Non-SCIM applications receive nothing. The accounts remain active until someone manually revokes them — which requires knowing the account exists in the first place.

Limitation 4: No Built-In Access Review or Certification Capability

Entra ID includes some access review functionality through Entra ID Governance (formerly Azure AD Identity Governance), but it's a separate licensed feature rather than a native component of the provisioning engine. For organizations that need periodic access certification — quarterly reviews where application owners confirm or revoke user access — the native tooling requires additional licensing and configuration beyond the SCIM provisioning setup.

Access reviews matter for compliance frameworks including SOC 2, ISO 27001, and GDPR, which typically require documented evidence that access entitlements are periodically reviewed and that inappropriate access is revoked. Without a structured review mechanism, access accumulates over time as employees change roles, complete projects, and retain permissions that were appropriate at one point but aren't anymore.

The provisioning engine handles the initial assignment and the termination case. It doesn't handle the ongoing governance question of whether access granted six months ago is still appropriate for an employee who has since changed roles.

Limitation 5: Limited Coverage for the Mover Scenario

Entra ID's provisioning engine handles the joiner case (new user created, provisioned into assigned applications) and the leaver case (user disabled, SCIM active: false sent to connected applications) reasonably well. The mover case — an employee who changes departments, roles, or locations — is handled less cleanly.

Dynamic groups in Entra ID can automate group membership changes based on user attribute updates, which in turn drives application assignment changes for applications provisioned via group membership. This works for the subset of applications that are assigned via dynamic groups and where the attribute mapping covers the relevant role changes.

For role changes that require simultaneously revoking access tied to the old role and provisioning access for the new role — without leaving a window where the user has both sets of permissions — the native provisioning engine relies on the group membership changes propagating correctly to each connected application in sequence. For applications where provisioning lag is significant, or where the transition needs to be atomic, this introduces risk that the mover scenario leaves the user with over-permissioned access during the transition period.

Why Teams Add an IGA Layer on Top of Entra ID Native Provisioning

None of these limitations are reasons to abandon Entra ID native SCIM provisioning — it provides real value for the applications it covers and reduces the manual provisioning workload significantly. They are reasons why organizations that have outgrown pure native provisioning add a governance layer above it.

An IGA platform like Zluri operates above Entra ID rather than replacing it. Entra ID continues to handle SSO and identity for the directory. Zluri adds the capabilities that native provisioning doesn't provide: event-driven provisioning that responds to HRIS events rather than directory-level triggers, direct API provisioning for non-SCIM applications, discovery-based offboarding that covers applications outside SSO coverage, mover workflows that atomically transition role-based access, and access certification campaigns that produce audit-ready compliance documentation.

The log noise limitation is resolved structurally: because Zluri triggers provisioning actions in response to specific events (a hire in the HRIS, a termination, a role change) rather than running batch evaluation jobs against the full directory, the run logs contain only the actions that were actually executed. There are no skipped entries for unassigned users because the provisioning logic doesn't evaluate unassigned users in the first place.

The soft-delete deprovisioning gap is addressed by monitoring Entra ID for status changes (account disabled) rather than deletion events, and by using direct API calls to downstream applications rather than relying on the SCIM DELETE payload to arrive at hard deletion time.

Frequently Asked Questions

Why does Entra ID SCIM provisioning log skipped entries for unassigned users?

Entra ID's provisioning engine evaluates all directory users when running a provisioning job, then applies the "assigned users and groups" filter as a secondary step. Users excluded by the assignment filter appear as "skipped" in the provisioning logs. Microsoft has confirmed this is expected behavior — the skipped entries represent users who were evaluated but excluded, not provisioning errors.

Why doesn't deleting a user in Entra ID immediately deprovision them in connected apps?

Entra ID uses a 30-day soft-delete model. Deleted users are retained in a recoverable state before permanent deletion, and the SCIM DELETE payload is only sent at hard deletion. To immediately revoke access in SCIM-connected applications, disable (deactivate) the user rather than deleting them — this sends a SCIM PATCH with active: false that applications process as immediate access revocation.

How do you provision users in applications that don't support SCIM in Entra ID?

Entra ID's native provisioning engine requires SCIM support in the downstream application. For non-SCIM applications, options include direct API calls via a provisioning platform (if the application has an API), tracked manual task routing (for legacy applications), or an IGA platform that handles both within the same provisioning workflow alongside SCIM-connected applications.

Does Entra ID include access review and certification functionality?

Yes, through Entra ID Governance (a separately licensed feature). For organizations that need structured periodic access certification as part of SOC 2, ISO 27001, or GDPR compliance, Entra ID Governance provides review campaigns. IGA platforms like Zluri include access certification as part of the core governance workflow rather than as a separate licensed add-on.

What is the difference between Entra ID native provisioning and an IGA platform?

Entra ID native provisioning handles SCIM-based provisioning for applications in the Microsoft app gallery and custom SCIM-enabled apps. IGA platforms extend that coverage to non-SCIM applications, provide HRIS-event-driven provisioning rather than directory-sweep-based provisioning, add access review and certification capabilities, and cover shadow IT and non-SSO applications in the offboarding scope.

See How Zluri Extends Entra ID Provisioning to Cover the Full Application Stack

Most Entra ID environments have a mix of SCIM-connected applications, non-SCIM SaaS tools, and legacy systems that native provisioning can't reach. See how Zluri's IGA layer handles the gaps in Entra ID's native SCIM provisioning — including non-SCIM apps, HRIS-triggered workflows, and access certification for compliance.