New Capability: Delete Accounts on Termination via Lifecycle Management

Announcements Product News
, , , ,
1

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

Description

With this release, we’ve added the ability to automatically delete accounts through Lifecycle Management on supported downstream connectors. This highly requested capability (323+ votes in the Ideas Portal) eliminates the need for custom BeforeProvisioning rules. All lifecycle state changes and account deletion operations are fully audited, ensuring security and compliance.

Problem

When an identity is terminated, disabling accounts may not be enough. Many organizations require true deletion of accounts to meet compliance requirements and prevent identity reuse.

Today, admins must rely on BeforeProvisioning rules to perform deletions. This creates deployment friction, increases reliance on services or partner resources.

Solution

Admins can now configure Lifecycle States to delete accounts in addition to enabling and disabling them. This option is intentionally restricted to inactive long-term identity state to reduce risk and ensure deletions are deliberate. The configuration can be found under:
Admin → Identity Management → Identity Profiles → [Select Identity Profile] → Lifecycle Management → [Select Lifecycle State]

Delete Accounts
Delete Accounts3370×2194 423 KB

For disconnected sources, the system generates a manual task and sends an email notification so the source owner can complete the deletion.

Delete an Account - Task
Delete an Account - Task3368×1396 284 KB

When an account is deleted, any associated entitlements that are linked to account are removed from the identity. If the identity still has a role assigned that includes entitlements on sources that selected for deletion, ISC will delete the account, but it will be recreated on the next identity refresh because of the active role assignment. To avoid this, we recommend removing any related Roles from the identity before deleting its accounts. Accounts are not deleted if the source also has Access Profiles listed under the Access Profiles tab.

All account deletions and configuration changes are fully auditable. Auditors can see who enabled account deletion, when it was enabled, and which sources were selected. Identity Security Cloud emits Delete Account events, recording key attributes such as the source, account identifiers, timestamp, actor, entitlements, and any error messages if the action fails.

Scope of this release:

  • Most sources are supported for account deletion via Lifecycle Management in this release, with additional source coverage planned for next quarter.
  • To see which sources currently support account deletion, please refer to this page: Identity Security Cloud Connectors (publish date: September 16th). > On this date, the Account Operations column will include D (Delete), indicating which connectors support account deletion.
  • The All Sources option in UI will remain disabled until delete is supported across all applicable connectors.
  • Supported sources will display “delete” in their feature array when calling the List All Sources endpoint.

List All Sources Endpoint
List All Sources Endpoint904×704 55.3 KB

:warning: Important

Accounts deleted through Lifecycle Management cannot be restored. Once an account is permanently removed, the only way to regain access is for the identity to be re-provisioned through standard access requests or role assignments. Administrators should carefully review lifecycle configurations before enabling deletion to ensure this action aligns with organizational policies and compliance requirements.

Who is affected?

All Identity Now and Identity Security Cloud customers.

Action Required

To take advantage of this new capability, we recommend that administrators review their Lifecycle State configurations under:

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

From there, you can:

  • Enable Delete Accounts for termination lifecycle states.
  • Review which sources currently support deletion by using the Specific Sources chooser.
  • Test the configuration in a sandbox environment before applying changes to production.

Important Dates

Calendar

:bangbang: By RSVP’ing to this event you will be reminded of this release prior.

  • Sandbox Rollout: September 15th, 2025
  • Production Rollout: The week of September 22nd, 2025.
22 Likes
2

Will we be getting the APIs for deleting a target account like we have for disable? Or will the current ones expand their support for true deletions?

3

Hi @adunker ,

We started with lifecycle management, and in the upcoming quarter we will add support for deleting accounts via the UI and API.

2 Likes
4

RemindMe! The upcoming quarter

5

@NataliaYunusov are there plans to make this available to other identity states? We have customers who wish to have accounts deleted outside of that identity state.

6

Hi @NataliaYunusov,

Fantastic news on the new Delete Accounts capability! :tada:

This is exactly the kind of thoughtful enhancement that shows the product team truly listens to the community. It’s clear this was a major pain point, and the solution delivered goes above and beyond expectations.

I particularly appreciate: restricting deletions to inactive long-term identity states. Excellent risk management while still solving the core compliance need.

Question:

I’m not seeing the DELETE feature available for the most commonly used existing sources of SailPoint projects (Active Directory, Entra ID, Okta Directory, .etc.). If possible could you please share which specific sources currently support account deletion? The connector documentation link unfortunately do not call-out delete feature of accounts.

For organizations with BeforeProvisioning rules for account deletion, is there a recommended migration path?

Thank you,

Amar Sheriff

7

There are legitimate use cases for account deletions outside of that identity state.

Ever have someone go on leave and have to continue to pay for a subscription service where the only way to free up a license is to delete an account?

1 Like
8

That’s an excellent point about legitimate use cases beyond inactive states.

I suppose my appreciation for the restrictive approach was more from a “better safe than sorry” perspective for this initial release, but you’re right that real-world scenarios often require more flexibility.

Perhaps this could be a great follow-up enhancement request - allowing deletion in other identity states but probably with safeguards.

9

Thank you, we truly appreciate the kind words. This has been a key pain point for many of our customers, and it’s rewarding to see this enhancement making a positive impact.

This page will be updated with an additional Delete column in the table on September 16th. Support has been added for around 80 connectors, including some of the most commonly used ones such as Active Directory, SAP, and Web Services.

We recommend reviewing your current setup to see if the existing BeforeProvisioning rule is still needed, or if the same outcome can now be achieved using the new account deletion functionality.

If someone goes on leave, would you delete an account rather than disable? With your use case, you’d want to allow account delete via lifecycle management to be extented to inactive (short-term)?
Would you delete an account rather than disable it if someone goes on leave?
In scenarios like yours, it sounds like you’d need account deletion via Lifecycle Management also be applicable to inactive (short-term) states?

With the upcoming work, when we support account deletion via the UI and API, there will be no restriction based on the identity’s state, however, deletions will go through an approval flow to provide additional safeguards and prevent misuse.

Thank you,
Natalia

2 Likes
10

I suppose I’m not understanding the guardrails that are being built around this when there are other operations without such guardrails that can be just as impactful.

For example, if you have “remove all access” set on a lifecycle state and someone gets accidentally terminated because of bad data entry (which happens more often than you think), then you can have someone’s access completely removed without an easy way to revert that back.

Something like that is just as impactful, so why doesn’t it have the same guardrails put up that you’re doing for account deletion?

You give people enough rope to hang themselves in some situations, but not others

1 Like
11

Thanks for the update. Will there be any delay function for account delete? Let’s say the account gets deleted after x days post user termination.

1 Like
12

One other use case to consider for SailPoint making the account delete function more widely available is for companies that wish to implement a Zero Standing Privilege (ZSP)/Just-In-Time (JIT) access model.

They may prefer that you only have an account that exists during the time period you requested access, so the account is created when your session starts and is deleted when it ends.

CyberArk does this with their Secure Infrastructure Access (SIA) tool through its creation of “ephemeral” accounts that only exist for that user session.

13

Amazing! This is one of the better announcements. We have been asking and waiting for this for years. Happy to see this get into effect! :slight_smile:

I fully disagree here, and I specifically don’t appreciate this. SailPoint should allow customers to make these decisions themselves. An “Are you sure!?” warning is fine, but no need to treat customers as if they can’t make conscious security decisions themselves.

One example to give here is that we have several leaver phases based on end date. One to immediately disable accounts (allowing easy enabling for rehires or end dates that did not get updated in time), one to revoke roles and access (to prevent recreation of accounts when we delete them), one to delete accounts and then one to strip identity attribute data to sync them with the accounts that should not be deleted. Deleting before stripping is to ensure the delete operation works properly and we don’t get race conditions with attribute sync. And after stripping we could have a final lifecycle state which would be inactive long-term. We can’t put the lifecycle state triggering deletions in inactive long-term in this case as that identity state would prevent identity refreshes which means it will not properly get put in the next leaver phase.

Another example is for cases where disable account is not supported for that source and we need to directly delete the account of that source on the first leaver phase, while keeping it as Inactive (short-term) as it has more phases to go to. Or cases where license costs are also paid for disabled accounts and we required immediate deletion instead to save costs.

These would be examples of requiring this for the identity state Inactive (short-term), but there are also use cases where you require it for identity state active. For example if you have a source where having accounts in considered high privileged, where you can have lifecycle state “active” on an identity profile for contractors and a lifecycle state “active” on an identity profiles for employees. If someone was an employee with an account on this high privileged source and leaves the organization to become a contractor, their lifecycle state will stay ‘active’ and many accounts and access should be kept. It just requires deletion of that specific source due to the lifecycle state change.

If SailPoint is actively blocking us to delete accounts through the other identity states, then we still need to rely on those before provisioning rules which would be more prone to errors and it would be audited less well. For example if we change operation from disable to delete and the account was already disabled, it would not delete it properly.

If anything, you can have a global setting allowing customers to configure whether LCS account deletions should only occur for Inactive (long-term) or if it may also be applied to other identity states. Then you have your “SailPoint offers security guardrails”, without preventing customers to meet their own security requirements.

I once heard that entitlement requests are also “sticky”. Is this still the case? If you have requested an entitlement or access profile with an end date, and the corresponding account is deleted, will recreation still occur? Or only for assigned roles as you mentioned?

It is 2 days since September 16 and Web Services does still not have a D in this link in this documentation, even though it supports the delete operation if you go to edit source → HTTP operations → add delete account. Why is the documentation not mentioning this D here in this case?

Wouldn’t it make sense to have an option that says “Delete accounts in all sources whose features contain DELETE”?

We can technically add or remove this feature by editing the sources. Can we remove this feature flag for all sources where we definitely don’t want to delete accounts from? For Web Services related sources we can simply choose to not add the Delete Account operation in the HTTP operations bit on the source, but out of the box sources might support delete even when we don’t want to use it. It would be nice if we can remove this through here as safeguard as source admin to ensure admins having access to lifecycle states can’t configure deletion of those accounts.

I think you can’t say this here as it may depend on the target application on how it treats account deletions. Perhaps deletion triggers archiving an account, which could be different to disabling. Or perhaps they have nice back-up mechanism et cetera. Perhaps this warning can be rephrased to keep the “You need to be really sure when deleting accounts” message whilst staying correct. Maybe something like “Restoration of deleted accounts is outside of the scope of ISC, it could cause permanent effect”.

Looking forward to this. I can’t wait to use this delete account functionality in workflows as well.

Kind regards,
Angelo

14

For this, we recommend using a different lifecycle state, such as “deletedAfter30days.”

Thank you! Happy to hear it :slightly_smiling_face:

The feature was built in a way that it can be extended to other identity states, like Inactive (short-term). If we receive enough feedback and signal that it’s needed, we’ll consider it. Thank you for providing these use cases. For the Active state, it sounds like this would be better handled by doing single account deletion instead of using a lifecycle state. The good news is that this feature is coming soon and is on the short-term roadmap.

Entitlements, as well as Access Profiles with an end date (or without), will be removed and accounts will not be recreated. It’s only assigned Roles that will cause the accounts to be recreated if the identity is refreshed. Keep in mind that identities in the Inactive (long-term) state are excluded from the 8am/8pm identity refresh.

This may have been an oversight. I’ve reached out to the team to ensure that the table is updated accurately.

Yes, you can do this by making a PATCH call on the source to update its supported features if you want to remove DELETE.

Thank you,
Natalia

1 Like
15

This is a great announcement and feature. I have been reading the responses which provide great insight. I was wondering if this could be incorporated using a Workflow. I would like to put a timer on the deletion. Example - if the account is in the Terminated LCS for more than 30 days then the workflow executes the deletion to the downstream system. Does this feature allow us to control deletion through a workflow?

16

Thank you! Not yet, but we will add support to delete accounts via Workflow in the near future. Stay tuned for updates.

17

I have an access profile in AD source and tried deleting the account through terminated lifecycle state and the accounts are getting deleted. Can you explain more on this because this line is not making any sense.

18

Hi @npandey ,

Did you add that Access Profile to the Access Profiles tab within the same lifecycle state where you configured your accounts to be deleted?

Screenshot 2025-09-30 at 7.48.39 PM
Screenshot 2025-09-30 at 7.48.39 PM3152×1008 229 KB

19

Very elegant! Thank you for creating this awesome capability, Natalia & Team! :star_struck:

1 Like
20

Love this feature.

Is there any way to trigger one Lifecycle State based on how long a user has been in a different Lifecycle State? For example, I would love to be able to create the lifecycle state: “inactive long-term” and have this trigger if and only if a user has been in the “inactive” lifecycle state for 30 days or more. This is more desirable than relying on an End Date from our authoritative source seeing as it is possible for users to have back dated end dates. Is this type of logic possible in determining a lifecycle state?