New Capability: Multiple Owners and Succession Planning for Applications (Machine Identities)

[NataliaYunusov]

Description

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.

Create Application – Assigning Owners

Application Grid View with Multiple Owners

Update Identity – Editing Owners

Human Identity Detail Page – Owned Machine Accounts and Applications

Succession Planning – Audit event when the primary owner leaves

Who is affected?

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 1st, 2025
• Production Rollout: The week of September 8th, 2025.

Calendar

[adamslamena]

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

[NataliaYunusov]

Hi @adamslamena ,

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.

[angelo_mekenkamp]

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.

Kind regards,
Angelo