To further improve security around personal access tokens (PATs), we have added the ability for admins to see and manage all of the PATs in their environment, not just ones they have created. Admins can view tokens, edit them, and change their expiration dates. Tokens can be modified individually, or in bulk.
Problem
Before this release, admins could only view and manage personal access tokens they created. This left them unable to see any integrations or API access client IDs being created by another user and when making a change to a token they did not create, required them to identify the user, contact that user, and walk them through the required changes. This opened potential security risks, and made it impossible for admins to completely manage all aspects of their environment.
Solution
With this release, we have added a new screen under Admin → Security Settings → Personal Access Tokens to let admins see all of the tokens in their environment. They can also edit them, and change expiration dates. Changes can be made on individual tokens, or on several tokens at once. A new API, Bulk update PAT expiration API has also been added to let admins manage PATs programmatically as well.
Who is affected?
ISC Admins
Action required
IMPORTANT: To further improve security, with this release any Personal Access Tokens created before we released the PAT expiry support on February 5, 2026, that has not had an expiration date added or removed, will automatically be assigned an expiration date 6 months (180 days) from the release date of this new admin management feature. Admins can use the new feature to edit or remove (not recommended) those new expiration dates. Any tokens created after February 5, 2026 will not be changed.
Important dates
Sandbox availability: 7/21/2026 Production rollout: 7/28/2026
It does not show it’s usage. We do have other features coming to show usage when used for making API calls. That should be available in the next few months.
Please note that a message like this might have the opposite effect to what you expect. You might mention this to showcase that we as a community are being heard. That the idea portal is working as expected and that our ideas are being developed.
But when clicking the link I see this:
It was created around 2 years ago and in all this time it has received a total of 2 votes, with one comment.
Yet multiple ideas that exist since the creation of the idea portal in 2021, with hundreds of votes are not shipped yet. (for example the most voted idea in ISC is having “read only admin access”)
So to me, a message like “This new capability is brought to you by idea X” when the idea has only 2 votes sounds more as if independently of the idea portal, SailPoint decided to build this and afterwards searched on the idea portal if it happened to have been mentioned before, to then link it here.
And I understand that there are different teams in SailPoint and you can only work in a small domain, or that some ideas take more time/alignment to build. But also when it comes to PATs there are ideas with more votes out there. For example if you search for https://ideas.sailpoint.com/ideas/search?query=personal+access+token&sort=popular, you will see that the idea to stop showing the PAT secret in plaintext, which currently has 33 votes (which is 15.5 times as many as 2) and is way easier to implement as it only involves a UI change.
So even though I agree that this is a good feature, although I am not sure yet if admins should actually have the power to increase the PAT scope of PATS belonging to other identities, and I also wonder if making such changes are already resulting in clearly documented events in search, I do also think that this feature should not have been prioritized over other features for which we are still waiting.
This one may have gotten in under the heading of “low-hanging fruit” vs a lot of the older and much more complex requests and ideas. I get what you’re saying about the optics, though.
Angelo, thank you for that feedback. We did actually add hiding the client secret in the personal access token screen under preferences. We’ll be adding it to this admin page as well soon.
I do understand that, but as mentioned, there are “low-hanging fruit” ideas with way more than 2 votes that are pending longer to be implemented.
Ahh yes, I see it looks nice under the preference tab now. Since a new feature like the admin page doesn’t have this yet. It seems that “security by design” is not being followed. Instead first the functionality is released and later an enhancement is required to address the security issues. Would it be possible to only release functionality that already has the expected security controls in it? (Please note that in workflows, external triggers also have credentials where the secret is shown in plain text)
Description
Problem
Solution
Who is affected?
Action required
Important dates
