Announcement: Personal Access Token Expiration Policy Update
To enhance security and align with industry best practices, personal access tokens now automatically expire after 6 months—regardless of usage. If you require long-term integration, we strongly recommend switching to API clients, which are more secure and better suited for persistent access.
These changes help protect your account and our platform. Please review your current tokens and update your integrations as needed. Thank you for your attention and ongoing commitment to best security practices.
What is happening with existing PATs… are you applying an expiration date to them retroactively, will it be six months from application, will it auto-expire them if they were made over six months ago? If so, when is that happening.
I also want to echo what Mark mentioned… we have to use PATs on a service account for applications we make available to users. (applications we create due to lack of IDN functionality, or the restriction of locking things like data segmentation behind a paywall…)
Yeah, this is really the crux of this. We’ve got a lot of consumers so we’re going to have to build automatic notifications and possibly see if we can set it up to rotate it for them.
Yes, I agree with the others on that this is a bad idea. Please view the my arguments why below. I hope this will get rolled-back quickly.
This functionality limitation was not announced in advance. I discovered this in production before the announcement and already explained to my team members in what ways this breaks our current processes.
This functionality limitation is not mentioned in the release notes.
This was also not covered in an in-discovery announcement, allowing us to raise our concerns on how this would negatively impact our way of working before SailPoint would even started building this.
Our CSM did also not warn us on this breaking change. Were they informed on this?
I haven’t seen this in non-production before I saw it in production. Meaning there was no or too little time between for partners/customers to raise the noticed issues when discovering in non-production.
We can’t modify the hardcoded max of 6 months, or even disable this functionality. We have build specific workflows to govern Personal Access Tokens. Think of things like only allowing those in a governance group to have them, deleting if not used for a long time. Those were our choices based on our policies. One could have chosen to build a workflow to delete PATs older than 6 months, but one could have chosen not to do this. With this functionality limitation, this flexibility has been removed.
The documentation now mentions that SailPoint recommends using the API Client method for long-term or Production integration use, but this is undesired for several reasons:
7.A. API Client Credentials can’t call the same APIs that you can call with a Personal Access Tokens, limiting what you can do with it. Many APIs don’t support calling with API Client Credentials.
7.B. API Client Credentials are not associated to an identity (human or Service Account) in the way Personal Access Tokens do, meaning it is more difficult to apply life-cycle management on it, which we can and are doing for Personal Access Tokens. In fact we want to only have API Client Credentials for cases where we absolutely have to due to out of the box SailPoint functionality (VA management and workflows with external triggers) and have a workflow automatically detect notify and delete different API Client credentials. Any other API Client Credential can’t be governed as securely as PATs.
7.C. API Client Credentials can only be limited on what they can do based on scope of the credentials. Personal Access Tokens allow more flexibility as on top of scope you can apply concepts like segmentation, user levels and governance group membership to determine what you can do with those credentials. We lose all of this if we choose to go with SailPoint’s recommendation.
Some security standards argue that having to rotate certain credentials every 6 months can even increase the risk of compromised credentials instead of solving it as you need to replace the secrets more often, and they suggest to only rotate those credentials if there is a suspicion of a compromised secret. By putting this functionality limitation in here, The choice of the customers is taken away and one opinionated decision is enforced.
Note that frequent recreating of PATs is extra insecure due to the fact that ISC shows the secrets in plain-text. If you search in the idea portal on Personal Access Tokens and sort by popularity, you will find this idea to fix this security vulnerability.
SailPoint Workflows require us to give the secret for every HTTP operation we use to ISC API’s, meaning that we have to update these credentials in a lot of places every time it gets expired for our workflows to keep functioning.
I might now cling on my current PATs that are still there without expiration date and will be more hesitant to replace them, knowing it will cause an enforced expiration. We should be able to recreate them ourselves when we think the PAT has been compromised without having to get badly effected on it.
So in summary this is a too late announced change, that enforces a questionable control that we can’t undo, and that will disrupt our way of working, while the recommended SailPoint approach is not feasible, limits flexibility and would break the security controls we currently have in place.
Please roll-back this functionality quickly. If you want you can consider the following:
Have a global configuration setting allowing customers to choose to have a max expiration day (and if so, what the max days should be, 6 months, 2 years? etc). In this way you add functionality for those tenants who requested it without enforcing this hard-coded limit on other tenants as well.
And please for the next time involve this community with breaking changes like these. We could have explained up front why this would not be ideal and why the alternative suggestion of using API credentials is not feasible and not the best practice.
Having to go back and switch the numerous workflows and scripts that rely on PATs to API clients (which as has been pointed out likely won’t work) is going to be a huge pain. Please re-consider.
I already opened a support case about this earlier this week when you guys pushed it before the announcement and emailed my CSM to try and get this rolled back so I’m voicing my concern again here to add fuel to the fire.
This needs to be rolled back full stop. The change is fundamentally flawed as the documentation itself justifies that we may need longer-term tokens for integrations, but as others have mentioned here the provided workaround of using API Client tokens is not even close to sufficient. The need for user context on like half of the API endpoints makes using API Client tokens basically useless in general, and we already have multiple specific integration cases where we have to use PATs because of this.
Also the announcement is supposed to come before you release the change in our production tenants, not after. C’mon guys.
so, how does this work with the to enhance security and align with industry best practices goal of this change?
i agree with the others (thanks to @mcheek and @angelo_mekenkamp for doing the heavy lifting here) that this change does not adequately reflect the nature of the ISC API endpoints, but it’s a little incongruous to say that this is being done for security, but everything that existed before will continue to work as-is with no way to see what PAT tokens exist.
will there be any way for org admins to see every identity that has PAT tokens, along with the expiry of those tokens and their descriptions and scopes?
@Mark - Thankfully, you can do that today with /personal-access-tokenslist-personal-access-tokens | SailPoint Developer Community. The end point lists the names, owners, last used, expiration, etc. I think we’ll have to build some automation to find tokens that are expiring soon and alert & remind the owners.
The tricky part will be for PATs where we generate them with specific scopes for the owners. AKA some endpoint needs Org Admin, but if we scope it down it’s safe for them to use. We control those accounts, not the person using that service account.
Extremely well put Angelo, I just want to add extra stress to the point you made about “By putting this functionality limitation in here, The choice of the customers is taken away and one opinionated decision is enforced.”
This seems to be a bit of a trend with recent SailPoint decisions and I’m begging you guys to stop treating your customers like they cannot make these kinds of decisions for themselves. I don’t know why you would ever take away security controls from SailPoint Admins like this.
I agree with others that automatically expiring PATs is not the right approach.
Customers have the option to set expiration dates and should be able to decide what works best for their environment and use cases, rather than being forced.
If the recommendation is to move to API Clients for long-term use, then all endpoints should support them before enforcing such a change.
One of the most common places that we consume PATs that will be operationally tedious with this change is in Workflows. Lots of them need to call back into SailPoint and consume the PATs in the HTTP Request Action. However, the action doesn’t support credential providers, which means every 6 months, we’ll have to update every action instance in each workflow.
I will chime in here as well, even though most of the important statements have already been made. I would say +1 to all of them.
First off, releasing such an impactful change to a critical part of the system without any pre-announcement, collection of feedback / ideas seems to me to be a very bad idea. As is clear from the responses already made, I think it is wise to learn from this situation and create a better strategy to tackle and introduce these features. Additionally, a roll-back / disable of this feature would be a good thing to do.
Then, more feedback on the content. This might be duplicating some of the points already made, but I think it is clear to get more opinions in here as well.
I think this is a way of saying “we know what is best for your use case”, and I think multiple cases can be made where this is not true. It needs to be configurable, either by the user themselves or by an admin or both. Additionally, enabling this doesn’t change the expiration of the existing PATs, which is good, but ultimately doesn’t address this issue for those!
As mentioned above, this doesn’t fit the bill as the API clients cannot be used on all (most?) API endpoints and are not ‘owned’ by any identity. This makes them not useful at all.
Tl;dr: We have rolled back this change and will re-approach the solution, taking in account the concerns that many of you have raised here. No prior or current PATs have been affected.
First, thank you all for your engagement on this issue. The response from this community was quick and unified- one of the many things we, here at SailPoint, love so much about our developer community.
A number of us on the product, engineering, support and professional services team have met internally to discuss the many facets to this problem and the solution to this problem. For the time being, we have immediately rolled back this change (thank goodness for feature flags, am I right?!).
With this community’s engagement and support, we are committed to delivering a solution to this problem that addresses both many of the concerns raised by you all and meets the high security bar we hold ourselves to here at SailPoint. We are working through a few different options now and I will let you all know what the path towards greater PAT security looks like in the near future.
Thanks again for y’all’s engagement on this issue.
Great, Thank you @jeremy_southerland for listening, for the swift response and for agreeing to roll-back for now! I am confident that the updated release will work well for everyone!
Jeremy, just wanted to thank you and the team for your quick response and rollback on this based on the community feedback. It’s great to see the Developer Community feedback be given such strong consideration in regards to changes like this, and I can confidently say that I speak for all of us when I say that it’s greatly appreciated.
It would be great to engage with the Community earlier on in the process in the future so that we can help guide some of these priorities and implementations and hopefully avoid situations where developers and PMs have to roll back their hard work. Maybe monthly open sessions with PMs to go over some of the things in the hopper with opportunities for feedback?