New Feature: Management of inactive identities

We are beyond excited to announce the release of our “Management of inactive identities” feature. This feature, which was the #2 most voted in the SailPoint Ideas Portal will allow you to mark identities as “inactive.”

What are the benefits?

You will have a more accurate view of your managed identities, more customization in your tenants, and better security in your systems. This mitigates risk significantly and gives confidence that you are giving access to an active identity.

How do I set up identity states?

Identity state configuration is part of lifecycle states, which are configured under identity profiles.

When creating or enabling new lifecycle states, you will now be required to denote the identity state for identities in that lifecycle state. Any identities not set up in a lifecycle state will be defaulted to an “Active” identity state.

All identities in pre-existing lifecycle states will be set to an “Active” identity state by default. To change the status, you will have to edit pre-existing lifecycle states and denote the identity state that should be assigned to identities in that lifecycle state.

Again, any identities not set up in a lifecycle state will be defaulted to an “Active” identity state. In addition, any pre-existing lifecycle state that has not been updated with an identity state designation will also be defaulted to an “Active” identity state.

Why are we releasing this feature?

As we mentioned above, this has been a top feature request from customers (#2 most voted in the SailPoint Ideas portal) because customers do not want to see inactive identities in certain areas of the product, such as Access Requests.

Until now, inactive identities have shown up for selection in various parts of the product. For instance, an end user submitting an access request on behalf of others can select inactive identities. Allowing inactive identities to be selected or displayed in various governance tasks creates risk (e.g., adding access to a terminated user), introduces delays (e.g., assigning tasks to an “inactive” user), and causes unnecessary confusion (e.g., showing a manager direct reports who are no longer with the organization).

When is this feature available?

It is now available to all Identity Security Cloud (Standard, Business, and Business Plus) and SailPoint IdentityNow customers.

What are the identity states and where are they found?

A configuration option on the lifecycle state UI will enable admins to map identities to three identity state options:

• Active
• Inactive (short-term)
• Inactive (long-term)

Administrators will see the options below when creating and updating their lifecycle states:

How are the identity states defined?

Active

Identities joining or working for the customer organization and who have access to Identity Security Cloud services should be mapped as Active.

Active identities are identities that will be included in all product functionality.

Here are some prevalent lifecycle states we recommend mapping into the “Active” state:

• Pre-Hire
• Active

Inactive (short-term)

Identities leaving or having a restricted relationship with the customer organization should be mapped as Inactive (short-term).

Inactive (short-term) identities will be removed from select functionality in the product, including:

• Identity Picklists in Request Center
• My Team UI for Managers

These identities will remain in aggregations and refreshes.

The goal of Inactive (short-term) is to provide a state that allows customers to transition identities out of the organization. For example, identities might move to "Terminated" when first separated and then moved to "To Be Deleted" when separated for 90+ days. Alternatively, this identity state allows customers to designate identities that are temporarily not active within the organization.

Here are some prevalent lifecycle states we recommend mapping into the “Inactive (short-term)” state:

• Leave of Absence
• Recent / Phase 1 Terminations

Inactive (long-term)

Identities that have separated from the customer organization should be mapped as Inactive (long-term).

There are several reasons for businesses to hold long-term inactive identities:

• For legal or compliance reasons, businesses are often required to hold identities for several years.
• For re-hire use cases, it is preferable to bring an employee back with their information, former messages, etc. intact.

Inactive (long-term) identities are identities that will be removed from select functionality in the product, including:

• Everything removed from Inactive (short-term)
• Scheduled Processing
• Apply Changes on Roles UI

These identities will be removed from aggregations and refreshes.

Inactive (long-term) will contain the same information we store about an active identity.

Some benefits to Inactive (long-term):

• It helps customers who have compliance requirements. Some businesses are not allowed to delete an identity for several years.
• If you re-hire / re-activate an inactive identity, all their accounts can be re-enabled, so they can continue working without losing everything.
• Validates the uniqueness of new identities you create. For example, if you hire your 104th John Smith, his account will not be confused with the other John Smiths. An Inactive John Smith will not get access to the 104th John Smith's Slack account, email account, etc.

Here are some prevalent lifecycle states we recommend mapping into the “Inactive (long-term)” state:

• Inactive
• Final / Phase 2 Terminations
• To Be Deleted

For more information, check out Developer Community announcement: Management of inactive identities. Also, reach out to your customer success manager with any questions or feedback.