New Capability: Remove All Access on Termination

Announcements Product News
, , , ,
1

This enhancement is brought to you by :aha: Idea GOV-I-880

Description

We’ve made it easier to ensure that access is fully and automatically revoked when an identity is terminated, across all sources. This has been one of the top customer requests with 320+ votes in the Ideas Portal. The new enhancements reduce reliance on complex rules and manual updates, saving time and minimizing risk.

This post outlines the new capabilities available for Lifecycle State configuration, including access removal, smarter source selection, and auditing.

New Capabilities

Admins can now:

  • Choose “Remove All Access” when a user hits a termination state, revoking all requested and detected access.
  • Automatically bypass approval flows for access removal during termination.
  • Audit and trace access revocations tied to Lifecycle State changes.
  • Use a new out-of-the-box LCS for faster onboarding of new identity profiles.
  • Select “All Sources” for enable/disable account actions, ensuring new sources are automatically included.
  • Exclude specific sources from All Sources logic (e.g. skip Workday).

Problem

When a user is terminated, two critical things need to happen:

  1. Accounts must be disabled on all connected sources.
  2. Access must be removed across roles, access profiles, and entitlements.

Currently, these actions are handled in a somewhat fragmented and manual way.

For account disablement, administrators configure Lifecycle States to define which sources should be included. However, as new sources are added over time, these configurations aren’t always updated, meaning some accounts may remain active after a user leaves.

For access removal, admins put significant effort into managing both requested and detected access. Some implement BeforeProvisioning rules to remove entitlements, while others use access certifications to review and revoke access after the fact—often introducing delays due to approval requirements.

While these methods are functional, they can be inconsistent and difficult to maintain at scale, potentially creating audit gaps and increasing risk exposure over time.

Solution

Admins can now configure Lifecycle States to automatically remove all access from terminated users without relying on rules or manual certifications. When “Remove All Access” is selected, the system will revoke all requested access items, including roles, access profiles, and entitlements, along with detected entitlements and associated access profiles. Approvals for these revocations are bypassed, ensuring fast and consistent deprovisioning. Access provisioned by the current Lifecycle State or birthright roles will not be removed.

This option can be found under:
Admin → Identity Management → Identity Profiles → [Select Identity Profile] → Lifecycle Management

Remove All Access
Remove All Access2708×772 215 KB

We’ve also introduced a new All Sources option, allowing admins to enable or disable actions across all sources, including newly onboarded ones, without needing to update the configuration each time. Admins can exclude specific sources if needed, maintaining control while automating the bulk of the work.

All Sources - Excluded Sources
All Sources - Excluded Sources2880×1490 288 KB

In addition, admins can now select IdentityNow/ISC as a source when configuring account enablement and disablement.

Source Name - IdentityNow
Source Name - IdentityNow2334×1490 229 KB

Who is affected?

All IdentityNow and Identity Security Cloud customers.

Action Required

No immediate action is required. However, to take advantage of the new capabilities, we recommend reviewing your current Lifecycle State configurations under:

Admin → Identity Management → Identity Profiles → [Select Identity Profile] → Lifecycle Management

From there, you can:

  • Enable Remove All Access
  • Use the All Sources option for account disablement or enablement
  • Include IdentityNow as a selectable source

Important Dates

  • Beta Rollout: June 16, 2025
  • Sandbox Rollout: June 23, 2025
  • Production Rollout (All Customers): The week of June 30th
17 Likes
2

Sounds great - Is it possible to have exceptions for individual Entitlements on Sources?
Accounts in e.g. AD/Entra will have many apps that require some pre/post processing outside of SailPoint, so will require some group membership to be maintained, perhaps until a second post termination lifecycle state.

2 Likes
3

@sbuk1 To ensure access is not removed from specific sources, you’ll need to list the relevant Access Profiles in the Access Profile tab for those sources. When Remove All Access is set to true, entitlements that are part of Access Profiles listed in that tab will be excluded from removal.

3 Likes
4

Hi @NataliaYunusov - so are you saying “Remove ALL access” only removes entitlements and roles but NOT access profiles from a source?

This contradicts what’s mentioned in the solution section of the post

When “Remove All Access” is selected, the system will revoke all requested access items, including roles, access profiles, and entitlements, along with detected entitlements and associated access profiles.

5

Simply awesome announcement!

1 Like
6

Shail, I believe Natalia just gave us a workaround in case we have a few entitlements to keep, just create an access profile for them and add it to the provisioning of the lifecyclestate to exclude from removal.

Example: I want terminated users to always keep 2 entitlements then I would create an Access Profile for them and add it to the “terminated” lifecycle state.

1 Like
7

Thanks for the announcement and the great explanation as well :+1:

1 Like
8

@TheOneAMSheriff is correct. “Remove All Access” removes all entitlements, Access Profiles, and Roles (except for birthright roles). If you need to make an exception and retain certain access, you must include the entitlements in an Access Profile and list that Access Profile in the Access Profile tab for the current lifecycle state.

9

Awesome ! looking forward to this !

I would have one question tho, how does it work with Direcotry Synced entitlements ?
So if we have an On-prem AD source and an Entra ID source that holds directory synced entitlements, will ISC try to remove the dirSynced entitlements as well ? Because that would throw a lot of errors.

3 Likes
10

Great question, @adamslamena

Directory synced entitlements will not be removed by the “Remove All Access” feature. While ISC will still attempt to remove them, Microsoft Entra ID does not allow dirSynced entitlements (those originating from on-prem AD) to be removed via API. So even though the removal request is made, the entitlements will remain unchanged.

To avoid this scenario, the Entra ID connector now supports a recent capability called Group Membership Filters, which lets you define the scope of group memberships to include during account aggregation. Using this can prevent dirSynced entitlements from being aggregated in the first place.
You can read more here:

1 Like
11

Does this option address some of challenges I have faced with Termination cleanup
1/ Is this an alternative for manage Account (disable) or Manage access (revoke access) or both?
2/ Does it disable all accounts linked to the identity? Or does it disable linked accounts that it is able to disable? Sometimes disable fails on an application.
3/ Does it remove access for remote entitlements or only entitlements that are obtained via the ISC access request channel? Example suppose user was assigned AD group membership directly in AD or Entra, will that be removed?
4/ Does it remove user from Role group membership that was assigned to the user directly not via the access request. That is Admin went to the Role and added the user as a member
5/ Does this revoke entitlements/access profiles that are listed as unrevokable or only the ones listed as revokable?

12

Sounds interesting! I read the whole announcement including the comments below, but I think it is unfortunately not useful, for several limitations it currently has, for lack of clarity on how it will behave and for several key points it seems to ignore.

I have got some questions and remarks on this announcement.

  1. @sbuk1 seems to ask if you can prevent individual entitlements from getting deprovisioned if using the Remove all access. The workaround clarified by @TheOneAMSheriff to create an access profile for them and add it to the provisioning of the lifecyclestate is not feasible. If we have 2 identities that have this entitlement that should not be revoked, and because of this we add this access profile to the lifecycle state, we are instead provisioning the entitlement to every identity in this lifecycle state. Preventing removal of entitlements is not equivalent to adding these entitlements to those who don’t have it. Using this suggestion causes privilege creep.
  2. The UI has a limit of how many sources you can add in the ‘disable account’ list (I believe it was 40 or 50). Will this update fix this issue by any chance? Or will the same error occur on the exception list of sources.
  3. Since the beginning of IdentityNow, now Identity Security Cloud, SailPoint is not allowing us to add “Delete Accounts” to a lifecycle state. Only Enable accounts and Delete accounts. Why is this not added as part of this update, or even before it? Many connectors support the delete account operation, but it is still not possible to call and API or use the lifecycle states to trigger this operation, meaning we still have to resort to the before provisioning rule. But how can you guarantee that the BPR will even trigger?
  4. Can we only remove the assigned roles and/or access profiles (while ignoring the approval flow), but keep the loose entitlements? We currently rely on workflows to achieve this, which automatically generate and complete certification campaigns, where we then per source determine whether to remove the loose entitlements or not, based per source and per identity attributes. This all (roles, AP and entitlements) or nothing approach can make it difficult to work with.
  5. Will there be an API allowing admins to revoke access while bypassing the approval flow?
  6. What will happen with sources that don’t support enable/disable. Will these trigger errors or will they be skipped?
  7. If a connector is temporarily down, will it perform these deprovisioning activities once it is available again?
  8. If you choose to disable and remove access simultaneously, and the source is a web service connector. Which operations will it trigger in which order?
  9. SailPoint Supports entitlement hierarchy, how does this behavior relate to this? For example if I have a birthright role pointing to a parent entitlement, for which I inherit a child entitlement. Will ISC know that it should not try to deprovision the child entitlement since it is part of the parent environment? Or will it trigger errors, adding chaos to the account activities audit logs?
  10. Suppose I have a birthright role which is granted with membership criteria which includes the mention of a specific lifecycle state. I now leave this livecycle state and enter a lifecycle state which says it will disable the account and revoke all access. Will the birthright role be deprovisioned first or will the other access be deprovisioned first, or is there a race condition that gets introduced?
  11. You have introduced the native IdentityNow/ISC source as being configurable in here. If using Remove all access. WIll it also revoke the launchers and user levels you might have through this source?
  12. You mention a new out-of-the-box LCS, and this immediately makes we worried that you are introducing limitations instead of enhancements. Just like how sources have a default correlation step to make it easier, while we are not able to delete this correlation step, causing wrongly correlated accounts. Just like how new identity attributes have been created out of the box, without allowing us to delete them, meaning that before we could choose to have them or not have them, now we are limited and stuck with identity attributes which we don’t use, but which are visible creating confusion. I hope that this is a LCS that we can also delete? Having preconfigured lifecycle states can speed up customers who plan to use this lifecycle state, but if this comes at a cost of other customers not being able to get rid of them, it is not a good enhancement. If we can delete it ourselves, I think it is fine.

Happy to join you in a call to go over the challenges we face with real-life examples! :slight_smile:

Kind regards,
Angelo

2 Likes
13

Hi @ugochuik

  1. If you’re referring to the workflow actions, then yes with *. Disable account per LCS isn’t new; we’re just introducing a way to select all sources. For Manage access (revoke access), yes, this is an alternative.
  2. When “All Sources” is selected, the system checks whether the source supports the Enable/Disable feature. If the source does not support the Enable / Disable, then it is skipped from the provisioning plan.
  3. It will remove all access (including detected entitlements from sources like AD), except for birthright roles and access provisioned via the current LCS using an Access Profile.
  4. This is considered a birthright role, so no, the Role won’t be removed in this case.
  5. By unrevokable, do you mean if it’s part of a role? We don’t have a concept of making a standalone entitlement or access profile not revocable, unless the entitlement or access profile is granted through a role assignment.
14

Hi Angelo,

Thank you for the thoughtful feedback and detailed questions. Below are responses to each of your points:

  1. The goal of the Remove All Access feature is to streamline access removal by revoking all access roles, access profiles, and entitlements, without requiring approval. However, we recognize that this may not fit every use case. Currently, we do not support direct exceptions within Remove All Access. For more selective deprovisioning needs, we recommend continuing to use certifications or workflows, which allow more granular control. We will consider the ability to support exceptions in future enhancements.
  2. Yes, the limit has been removed. Admins can now select more than 40 sources in UI when configuring to enable or disable account actions.
  3. We’re excited to share that support for ‘Delete Accounts’ through lifecycle management is on our 2025 roadmap. Stay tuned for more updates as we make progress.
  4. See answer #1.
  5. There is no public API at the moment that allows bypassing approval flows. Remove All Access bypasses approvals automatically but only within the lifecycle state configuration.
  6. When “All Sources” is selected, the system checks if the source supports the enable or disable feature. If it does not, the source is skipped in the provisioning plan. The UI also restricts adding such sources when selecting specific sources from the list (that’s existing behavior).
  7. If the connector is down, existing provisioning retry logic applies and hasn’t changed with this feature. The system retries up to 3 times by default, or up to 10 times if the identity is locked. Connector-specific retries may also apply.
  8. If disable and remove access are selected together, provisioning logic combines both into a single AccountRequest with op=Disable and AttributeRequests to remove entitlements. Execution order depends on the connector’s implementation.
  9. ISC will not deprovision child entitlements in this example.
  10. The birthright role will be de-provisioned first, and then the other accesses will be de-provisioned as part of the “Remove All access” setting.
  11. If a user has access (such as launchers or user levels) not tied to a birthright role or current lifecycle state, that access will be removed.
  12. The default lifecycle states are meant to help customers get started quickly, but are fully editable and removable. You are not required to use them and can delete them easily via the API Delete lifecycle state endpoint.

Thank you,
Natalia

1 Like
15

This is a great announcement! :raising_hands:t2:

1 Like
16

Hello All,

Quick question, is it expected that this feature will remove roles that have been assigned via the Identity option on a role? In my testing it doesn’t, just wanted to clarify here. I assume it won’t remove it and wasn’t planned to as its kind of a “criteria” assignment.

Regards
Brendon

17

Hi @brendonmurphy ,

You’re correct, if the role was assigned via the Identity List option, it’s treated as a birthright role, since it uses criteria-based assignment. These roles are not removed by this feature.

18

Unfortunately point #1 here marks this as yet another feature that is really useful in theory but we will be unable to actually make use of it due to lacking functionality on release that is unlikely to be fixed anytime soon.

Really looking forward to #3 here though, that would be awesome!

Point #5 is also very disappointing as there is no way for me, as an Admin, to programmatically remove access that requires approval for revoke requests. Not via workflows, not via API, not at all.

19

hi @NataliaYunusov , I was testing this new feature as you said birthright roles are not getting removed which is correct but the entitlements what are part of birthright roles are getting removed.

20

Hi @NataliaYunusov,

I see some functionality loss in the latest UI change.

Before it was possible to preview the attributes of an identity where the attributes are visible in a single column.

Now it has enforces it to be visible in matrix view with no option to mark it as a single column again.

Please compare this to the identity page, where we are able to select single column mode. Before this update, the single column mode was on the preview side as well.

Matrices make sense if you have multiple columns. Here it adds chaos to the screen, making it more difficult to find the right attributes I am interested in. Also there is less space now for the values. Some identity attributes can have many characters.

Kind regards,
Angelo