New Capability: Personal Access Token Expiration Support

This Capability is brought to you by :aha: Idea GOV-I-4087

:sparkles: Description

Personal Access Token expiration support reduces potential security risks from compromised tokens and makes it easier to manage appropriate access to Identity Security Cloud.

:red_exclamation_mark: Problem

Personal access tokens that never expire create a potential security risk if compromised, giving bad actors ongoing access to sensitive identity information.

:light_bulb: Solution

With this release, personal access tokens will be created with an expiration date, giving them a default 6-month lifespan, reducing risk. Token owners can choose a shorter or longer expiration period, or even make it never expire. (Not recommended)

:busts_in_silhouette: Who is affected?

All Identity Security Cloud customers.

:date: Important dates

Sandbox availability: January 26, 2026
Production rollout: February 2-4, 2026

2 Likes

Thanks for the update. Will this default settings be applied to the existing tokens generated prior to the release?

1 Like

Rahul, thank you for the question. No. With this release, only tokens created after the update have a default expiration date. Exsisting tokens are unchanged.

2 Likes

Thank you for the quick response. This is helpful information.

1 Like

I like the flexibility in expiration date. This will help a lot

Thanks

1 Like

Hi @BobCrosley,

This flexibility helps, because many endpoints still don’t support API tokens. Once the API tokens start supporting all the API endpoints, then @SailPoint can plan on a mandatory end date for the expiry of PATs.

1 Like

Hi @BobCrosley

Thank you for sharing the information and I do feel it is good step forward.
Just couple of questions from my end regarding this feature;

  1. Is it possible to extend the expiring access token. Lets say my PAT is expiring next week and i want to extend this token instead of creating new one, will that be supported ?

  2. Will ISC automatically send any email notification regarding the expiring PAT or should we build it by own using workflow or using some other option.

Thank You.
Regards
Vikas.

3 Likes

You can edit any token, even up to 3 months after it has expired, and give it a new expiration date. This is for situations where a token in a process may have expired and you don’t know until after the expiration.

We are working on a notification system for tokens. If you would like to share your thoughts on what that notification should look like, please feel free to schedule a call.

3 Likes

Just wanted to commend the team for taking the community feedback on this one and reworking the feature. Thank you!

1 Like

hi @BobCrosley

I see this change is affecting my client sandbox tenant. I generated my PAT yesterday with a future expiration date. I see that is vanished from the screen today. It seems to be happening to couple of my colleagues. Do you think it is because of this change. Also I need to have PAT which were generated before this new policy has been implemented. Now i do not see those PAT which were generated long ago. What do you suggest?

1 Like

I’m sorry for the delay in getting back to you Uday. I want to make sure I understand correctly. You have created PAT tokens in your sandbox tenant, and they disappeared? If that is the case, I’d suggest reaching out to support as that is definitely not expected behavior.

Thanks Mark! I have shared your feedback with the engineering team. Much appreciated.

1 Like

Thank You Bob! Will reach out to support.

I am late to the party, but thank you @BobCrosley for reworking the feature!

Please note that after the update the created client secret is still visible in plain text.
This is a :red_exclamation_mark: security risk :red_exclamation_mark: due to shoulder surfing. And also this makes giving Demo’s a bit awkward.

Could you please update this such that the secret is not visible in plain text, perhaps with an eye icon next to it in case people want to see it anyway, and keeping that clipboard icon next to it. This would mitigate this security risk.

Please see this corresponding idea for more details:
https://ideas.sailpoint.com/ideas/GOV-I-3447

1 Like