What is the expected behavior when an authoritative account is removed and the Identity becomes inactive?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hi Experts,

I would like to confirm the expected behavior in SailPoint Identity Security Cloud for the following scenario.

Scenario:

  1. An identity exists in ISC. The identity has one or more assigned Roles.
  2. Those Roles have provisioned Access Profiles / Entitlements to target source accounts.
  3. During aggregation of the authoritative source, the authoritative account is removed or no longer returned.
  4. As a result, the identity becomes disabled / inactive in ISC.

In this case, which behavior is expected?

  • Roles and provisioned entitlements are automatically removed / de-provisioned.
  • Roles are removed, but target source accounts / entitlements are not automatically de-provisioned.
  • The Identity becomes inactive, but existing Roles and provisioned target source access remain unchanged.
  • De-provisioning only happens if Lifecycle State actions such as Remove All Access, Account Disable, or Account Delete are configured.
  • It depends on Role assignment criteria, Lifecycle State configuration, and source provisioning settings.
  • Other / please explain in the comments.
0 voters

I would like to understand the expected behavior and implement the correct de-provisioning process based on that behavior.

Thanks in advance.

2

Based on the expected ISC behavior, if an account is no longer returned by the authoritative source during aggregation, the associated identity will eventually be removed from Identity Security Cloud.

When the identity is removed/deleted, any target accounts that were previously correlated to that identity become uncorrelated accounts in ISC. However, the access that was previously provisioned to those target accounts (such as Access Profiles, Entitlements, or Role-based access) is not automatically removed simply because the identity no longer exists in ISC.

3

Hi @jwshin

My experience is different than the options you put out there.

If an identity is no longer aggregated from the authoritative the source the identity is basically left in a incomplete state. This doesn’t update the lifecycle state and leaves them in whatever state they were previously left in thus not triggering any deprovisioning actions. However, if the roles you mentioned have criteria that are based on identity attributes that are now NULL, the user will drop out of that criteria and be removed from the access inside the role.

In an ideal world, identities should not be deleted from the authoritative source so you can always track them and not have any issues like above.

4

Hi @jwshin Your options are reductive because:

It depends…

Have you enabled Account Deletion (checkDeletedDisabled) on the Auth Source?
How have you configured Cloud Lifecycle States (and associated Identity States)?
How are your Roles configured?

Basically, you can pretty much configure any outcomes you may want.

5

Hi @trettkowski

Thank you for the clarification.

I observed similar behavior in my implementation environment.

The HR source does not provide an explicit cloudLifecycleState change. Instead, the authoritative account is returned as deleted or missing during aggregation.

As a result, the Identity State appears to become Inactive, and the identity is removed from the assigned roles because the role membership criteria depend on cloudLifecycleState being Active.

However, from the access history, it looks like the role removal happened only within ISC, and no de-provisioning action was triggered for the target account or entitlements.

So your explanation seems consistent with what I observed.

6

Hi @j_place

Thank you for your comment.

To answer your questions first:

  1. Account Deletion on the authoritative source is not enabled.
  2. Cloud Lifecycle States and associated Identity States are configured.
  3. The roles are configured with membership criteria based on identity attributes, including cloudLifecycleState being Active.

The scenario I am looking at is that the HR source does not send an explicit cloudLifecycleState change. Instead, the authoritative account simply no longer appears in the aggregation result.

In this case, the Identity State appears to become Inactive, and the identity seems to be removed from the roles because the role membership criteria are no longer satisfied. However, from the access history, I do not see de-provisioning being triggered for the target account or entitlements.

Given this configuration, what approach would you recommend if the goal is to trigger de-provisioning when the authoritative account is no longer aggregated, even though cloudLifecycleState itself does not change?

Would you handle this through Role membership criteria, Account Deletion settings, Lifecycle State configuration, or another approach?