SailPoint is proud to present the new Privilege Classification feature in Identity Security Cloud (ISC). This features allows customers to use new classifications levels to assign privilege indicators on entitlements. These new levels will replace the existing privilege boolean flag on entitlements, providing more granular insight into risk on entitlements.
New Capabilities
Privilege Classification introduces new levels of privilege that can be assigned to entitlements. Assigning High, Medium or Low level of Privilege allows a more granular approach to privilege classification within ISC. This allows more focus on High privilege access first, then followed by medium and low risk entitlements etc.These privilege levels can be assigned automatically through building criteria. Criteria can be configured for each of the High, Medium and Low levels. The privilege level can also be manually overwritten on individual entitlements, allowing the level to be increased, decreased or set to none, allowing complete control.
Problem
The current entitlement boolean flag is no longer adequate reflection of privilege in the current complex world of privileged entitlements. Also, the boolean flag can only be set manually which is a huge manual effort to utilize.
Many source vendors publish lists of privilege entitlements. These aggregated entitlements are not automatically set to privileged in ISC, which causes significant friction.
Classification of entitlements as privileged is a manual process in both the UI and API.
Solution
The privilege boolean flag on entitlements will be replaced with a new Direct Privilege Classification level. These privilege levels can be assigned automatically through building criteria. Criteria can be configured for each of the High, Medium and Low levels. The privilege level can also be manually overwritten on individual entitlements, allowing the level to be increased, decreased or set to none, allowing complete control.
Below is a screenshot of a source with the setting selected to assign the High privilege level to all entitlements on that source.
All IdentityNow and ISC suites customers will have access to Privilege Classification
Pending final packaging decisions. Post will be updated once final decisions are confirmed.
Action Required
No action is required. This is not a breaking change.
As part of the migration, all existing entitlements that currently use the privilege boolean flag will automatically be mapped to the High Privilege Classification level. Customers can then adjust classifications as needed using criteria or manual overrides.
Important Dates
Rollout will begin in early Feb 2026 and will end in March 2026.
So a rollout has already begun? That seems like very little notice for people to adapt to this breaking change.
If I were a customer that relied on the privileged flag returning a Boolean value to determine the approval flow in something like servicenow or sailpoint workflows as part of my access request process, I wouldn’t be very happy with the fire drill I’m suddenly finding myself in.
I find it odd that something like the API versioning strategy gives you YEARS to adapt to potential breaking changes, but this group has given customers DAYS.
I know @angelo_mekenkamp has given this feedback so many times without much movement, but product groups need to get behind a unified roll out schedule for any breaking changes so your customers have adequate time to adapt.
The first time I heard about this feature was a couple of weeks ago when an ASC was presenting about it. When I asked if the plan was to create a new field with these values or replace the existing field, the answer was “I don’t know, I’ll have to check with the product team on this”
I disagree with the ‘no action required’ part - I assume we’re not the only customer who actually uses the current’ ‘privileged’ flag outside of the visible UI. For example, all our privileged accesses are certified differently through scripts to leverage governance groups instead of managers.
All of these processes will need to be updated.
Is it possible to get a more concrete rollout date? If not rescheduling this at a later quarter so customers have more time to prepare and documentation to be ready to support this change.
Also echoing previous sentiments - it’s jarring that this is is announced in the middle of February with rollout starting ‘early Feb’ and is just assumed to not be a breaking change for any customer. The API docs are not even updated with this change that could theoretically already be present on our tenant so I have no way of preparing for this in advance.
Please let me reassure you this is NOT a breaking change.
We are introducing the new Privilege Levels, but we are maintaining 100% backward compatibility with the existing boolean flag.
All existing entitlements with privileged=true will be migrated to privilegeLevel.direct=high, and then internally all privilegeLevel.direct=high entitlements will map back to privileged=true.
Any API calls, saved searches, certification campaigns etc that utilise the ‘privileged’ boolean attribute will continue to work correctly because any privilegeLevel.direct=high will map back to privileged=true.
We are committed to supporting all API calls for 2 years, so the internal mapping of high->true will still work as expected for the next 2 years.
Like I say, this is NOT a breaking change.
You can continue to use, without any changes:
{
"privileged": true
}
And you can also, in parallel (using a new API version), use the new levels with:
{
"privilegeLevel.direct": "high"
}
or
{
"privilegeLevel.direct": "medium"
}
etc.
So to be clear, filtering on privileged=true or privilegeLevel.direct=high will return the exact same results.
The same applies to any POST/PATCH API calls that use privileged=true, they will set privilegeLevel.direct=high and also map back to privilged=true.
This is NOT a breaking change.
Pending final packaging decisions. Post will be updated once final decisions are confirmed.