With this release, ISC now supports assigning multiple people as the owners of a Role, Access Profile, or Entitlement.
Problem
In order to comply with various regulations and internal security policies, many organizations are required to designate a group of people as the owners for each of their access control. Prior to this release, only a single user could be assigned as the owner for an access item. This made it difficult for organizations to manage governance processes effectively.
Solution
With this release, ISC now supports the ability to assign ownership of roles, access profiles, and entitlements to more than one individual. Each ISC access item can now have a primary owner and an optional set of additional owners.
A single primary owner is required for Roles and Access Profiles but is optional for Entitlements.
Additional owners are always optional and may be assigned to a list of up to 10 Identities or to a single Governance Group.
Also with this release, additional owners can participate in access approval processes. Access request reviewers may now be specified to be an item’s owner, additional owners, or all owners. When the reviewer is specified as an item’s additional or all owners, all owners are notified however only one of the owners is required to approve the request.
Who is affected?
This feature is available to all ISC customers.
Important dates
Sandbox availability: March 9th 2026 Production rollout: March 16th 2026
Great news! Has the Role Importer script also been updated to support the Primary Owner and the Additional Owners, both Individual and Governance Group? We’ve been using a workaround, but with the addition of Governance Groups, we’ll definitely want to update all of our existing Roles and AP’s.
This is a great addition, but it’s functionally useless for any kind of certifications. There still is no option to mark certifier by access object owner, despite some posts and acknowledgement from SailPoint about adding that feature over 5 years ago.
This will help with day to day operations but certifications are still a nightmare without the access object owner available as an option for certifier.
Although it looks nice on first glance, I do have several doubts/concerns on the chosen solution path for the given idea. Please see my feedback below:
One of the comments in the corresponding idea is:
..each and every time the IDN GUI currently allow to selection one identity it should also be possible to select a governance group. We cannot spend hours upon hours updating the ownership of objets in IDN each time a position changes hands
The issue mentioned in this comment is not addressed in the given solution as roles and access profiles still require a primary owner, which then needs be an identity. It does not refer to a position such that if someone takes over the position, the ownership immediately changes on all related access items since they don’t refer to the actual person, but only to the position. If the actual owner could be a governance group, this would have been addressed.
The (albeit limited) description of the idea mentions:
Currently only identities can own objects. Allow ownership to be a group of identities to support delegates participating in approval and certifications.
the approval bit of this ask is actually already supported. As you can choose a governance group as approval step instead of the access items owner. And for certifications you can choose as owner: a given identity, the manager of the identity to be certified or a governance group. It is not possible currently to even select the owner of the access item as certifier when certifying several identities (meaning one certification campaign for one identity could trigger certifications for several reviewers depending on the identities access). Only if you certify on specific items with the same owner and then choose that identity as manual certifier. But if you do this, you can also just choose governance group as reviewer. As such this change will also not impact this bit of the idea. Only for role composition certification can you only choose role owner and hardcoded governance group, but here it seems this update will also not address that since the update does not mention certification.
I think this will add more chaos to access item ownership (and updating it) rather then fix it. Can identities now be both primary owner and additional owner at the same time? (either because you add them to both manually, or because they are also member of the governance group)? If I now want to make an export of all owners of a role, would I now need to check both lists and concatenate them together in a script? I have seen an application where they had a list of all entitlements each account had, but on top of that there was also an account attribute containing a single attribute which resembled being a primary entitlement. And this primary one did not have to be in the other list. Meaning there was no single source of truth. For ISC managing this application is also weird since a single entitlement could now be visible on two different locations. And adding a primary entitlement would overwrite the original one.
I wonder why wouldn’t you make it possible to make the actual owner field a governance group like this?
By doing this, you can do everything you want. Certification → take owner which can be either a group or an identity. Access Request → Similar.
Even if you want to be able to distinguish a primary owner to still refer to one identity, and view the rest as delegates, you could still use a governance group because a governance group also has both 1 owner and 0 or more members. As a bonus, all customers which are currently already using functionality to ensure ownership is removed/changed when the owner leaves do not need to update their logic as you solely rely on governance group membership and ownership, which are already existing objects. Now they would need to take a look at this additional field (additional owner) to see if they should be removed from there.
I am noticing this enhancement has already been deployed to our Sandbox environment (rollout started 3/9) and the notification that it been deployed was this morning (3/10). I would really prefer those 2 things to be in the reverse order - we need to know these things are coming, be able to ask tons of questions, get a peek under the hood, understand how things truly work, get our arms wrapped around how changes may potentially impact current processes.
I agree regarding the comments made prior about this functionality being included in Certifications. It’s one thing to be able to set various owners on an object., it’s another thing altogether to be able to use those settings. I’m glad to see Access Requests accommodating this functionality, I eagerly wait for Certifications to do the same.
One gap I’m already noticing with this - the “Additional Owner” assignment is not showing up in an Identity’s “owns” object in Search. In other words, I’m not seeing a way to look at an Identity and determine that they are an additional owner somewhere. This creates a maintenance gap for us because we have current processes looking at Owners of things who are terminated (“inactive” LCS) and replacing them with a more suitable owner. It doesn’t seem like this can be done in the same way with additional owners. I would have to export all Entitlements, Roles and Access Profiles … grab all the additional owners … and cross-reference their LCS values to make such a process work.
Will the OOTB Identity Cloud Governance connector be updated to accommodate this change and reassign ownership for additional owners also, or will it continue to look only at the primary owner?
I agree with Angelo’s comment: “I think this will add more chaos to access item ownership (and updating it) rather than fix it.” This appears to be a completely unannounced feature release and could introduce significant overhead for some of the custom scripts we have built to support processes that are still not handled OOTB by ISC.
This is great. I have the same question as @mcalder . Can you please confirm if Role importer script has been updated to handle additional owners? Thank you.
@PGookin - the API docs for accessRequestConfig.approvalSchemes are still out of date for this enhancement. Any ETA when those will flow in? Because without them the SDKs don’t get updated by @tyler_mairose and team.
Enhancement
Aha! Ideas Portal
Description
Problem
Solution
Who is affected?
Important dates