Ownership of Applications just got more flexible and resilient. Admins can now assign multiple owners to each Application and rely on automated succession planning if a primary owner leaves. This ensures accountability, reduces the risk of orphaned Applications, and provides clear visibility into ownership responsibilities.
This update also introduces subtypes for Machine Identities, starting with Applications. All existing machine identities have been migrated to the Application subtype, laying the groundwork for additional subtypes in the future.
New Capabilities
Applications (Machine Identities) now support multiple owners.
Automated succession planning ensures continuity when owners leave.
Ownership visibility on Human Identity detail pages.
Problem
Previously, Applications could only have a single owner. If that owner left the organization, responsibility became unclear, creating orphaned Applications with no accountable owner. Admins also had no easy way to see which Applications a person owned, slowing down troubleshooting and succession planning. In addition, machine identities were treated as a single broad category, without subtypes to distinguish between different use cases.
Solution
Applications can now have multiple owners. The first selected owner is designated as the Primary Owner, while additional owners are added as Secondary Owners (up to 10). In the Application grid view, owner names are displayed directly. When multiple owners are assigned, the first owner’s name is shown along with a count, and selecting it reveals the full list of owners with access to each person’s Human Identity details.
Succession planning keeps ownership up to date:
If a Primary Owner leaves and Secondary Owners exist → the next active Secondary Owner becomes Primary.
If no Secondary Owners exist, the owner’s active Manager is promoted to Primary.
If neither are available, the Primary Owner field is left blank until updated manually.
If a Secondary Owner leaves, they are automatically removed from the list.
Admins can always make changes manually using the Update Identity action.
All changes are audited, allowing admins to track when the owner changed and the reason for the change.
We’ve also improved ownership visibility. On the Human Identity detail page, admins can now see which Applications a person owns, either as Primary or Secondary Owner. This makes it easier to understand responsibilities at a glance and proactively plan for succession.
Customers who have licensed Machine Identity Security.
Action Required
We encourage admins to review Application ownership and assign secondary owners to maintain clear ownership and reduce the risk of orphaned Applications.
Important Dates
Sandbox Rollout: September 2nd, 2025
Production Rollout: The week of September 8th, 2025.
That looks like a nice update. However I think the naming is a bit unfortunate, since I thought we are talking about “Applications” as in where we assign our Access Profiles to
This change made the most sense for MIS customers. We acknowledge there is an existing application construct in use. We’re investigating how we can consolidate them in the future. For now, this particular new application is exclusive to MIS customers. Additionally, we’ll be moving the Application object used for Access Requests into the Access nav, to further distinguish the unique use cases for both.
I fully agree with @adamslamena that this is an unlucky chosen name here.
It is already difficult to talk to customers about applications because we need to clarify that there are 2 types that are being called applications in SailPoint ISC context. First of all target applications that we integrate with using sources. (In general when one talks about application onboarding, we are talking about creating a new source). But also that there are ISC objects that are called applications required for password management.
Now you are about to introduce a third interpretation of the word application in ISC context.
I already thought it was unlucky that Pass Through Authentication and Privileged Task Automation are terms being used by SailPoint as the both have the same acronym PTA. But now we are about to have three interpretations of literally the same term.
If I now quote you on “Applications can now have multiple owners.”, customers can be disappointed twice, thinking it first applies to the source, and then to the application, or vice versa, when it turns out it is neither.
Please note that you still have time to update this term before people get fully used to this newly introduced interpretation. Please reconsider doing this sooner rather than later, when it becomes more difficult to get away from this term and it causes more confusion on the forum, in slide decks, in code, et cetera.
Also, I don’t understand why you didn’t use an existing concept for multiple owners, being governance group members. That would allow for a more easy way of grouping ownerships of multiple <<new_name_here>> objects.
Thank you for raising this, we completely understand the concern. You are right that Application is already overloaded in ISC. For MIS customers this naming made the most sense, but to avoid confusion you can start referencing them as Application Identities. In the UI these sit under Machine Identities and only licensed MIS customers will see them. Longer term, we’re also looking at ways to consolidate the constructs and reduce overlap.
On ownership, we began with direct owners because customers told us ownership often varies app by app or account by account, which would have resulted in one governance group per object. The feature was designed so we can extend governance groups as additional owners in the future if that turns out to be the stronger pattern.
@NataliaYunusov Are there any plans to extend this capability to source owners & access item owners (entitlement, access profiles, roles) as well? We’ve been having this problem from quite a long time where if the sole owner of these objects leaves the firm, there’s no other way to:
Route the manual work items received by the source owner in case of delimited apps
Route the approvals stuck on entitlement owner, access profile owner or role owner
Hence, manual overhead is inevitable in such cases.
Both are on the roadmap. Support for access item owners (entitlements, access profiles, roles) is on the shorter-term roadmap, while the ability to route manual tasks is planned for the longer-term roadmap.
Will machine identity owners be able to be referenced in processes like certification in the future? Right now you can only choose the account owner to certify, so not sure where the benefit in this change is right now.
I agree with Patrick, why wasn’t this at least built to allow multiple owners for machine accounts instead of application identities? We don’t want to have to map every machine identity to an application before we can assign an owner to it.
Ownership of Applications just got more flexible and resilient. Admins can now assign multiple owners to each Application and rely on automated succession planning if a primary owner leaves. This ensures accountability, reduces the risk of orphaned Applications, and provides clear visibility into ownership responsibilities.
