Clarification on Machine Identity governance flow, governed items, and certifier behavior in ISC

Hi,

I am trying to understand the exact governance behavior for Machine Accounts and Machine Identities / Application Identities in SailPoint Identity Security Cloud.

I reviewed the following documentation:

I want to try and validate the machine identity governance flow end-to-end in ISC. Specifically, I want to identify:

  • What exactly is governed under a machine identity?
  • Whether governance is performed on the machine identity object, the correlated machine accounts, the access/entitlements, or a combination of these.
  • Who becomes the governance owner/certifier for the review?
  • How the machine identity owner and machine account owner are used during certification.

Any clarification on the expected product behavior, certification item structure, owner/certifier selection, and revocation behavior would be very helpful.

Thanks.

Hi @i_sethia

Based on the documentation, Machine Identities serve as governance containers that group one or more Machine Accounts. The certification process primarily governs the access and entitlements associated with those machine accounts rather than the Machine Identity object itself. Ownership of the Machine Identity and/or Machine Accounts drives accountability for reviews, while any access revocations follow the standard ISC certification remediation process.

So, is my understanding correct that there is no separate certification type specifically for Machine Identities?

Does the Machine Identity / Application Identity mainly act as a grouping or review container for correlated machine accounts and their access during a machine account certification?

Also, I noticed that Machine Identities can have user entitlements associated with them. I am trying to understand the role of those user entitlements.

  1. Yes, there’s no separate certification for machine identities.
  2. Yes, it depends on whether you create the machine identity individually or group them together.
  3. Yes, the machine identity has an associated service account with entitlements, and that’s exactly what we want to review during the campaign.

Please check this video for clarity on all type of certification.

Thank you for the clarification. That helps.

I have a follow-up question around the certifier/reviewer behavior for machine account certifications.

If the campaign is reviewing the service/machine account entitlements associated with a machine identity, who is expected to be the certifier/reviewer?

Is it:

  • The machine account owner?
  • Is the machine identity the primary owner?
  • Does the machine identity additional owner?
  • The source owner?

If the account owner is the same person responsible for the machine account or its access, would that be considered self-certification?

If yes, how should this be handled? Should the review be routed to another person, such as the machine identity primary owner, manager, source owner, or another configured reviewer?

Also, what is the exact role of the Machine Identity Primary Owner and Additional Owners during certification?

Are they only used for ownership and accountability of the machine identity/application identity, or can they also act as reviewers for the machine accounts and access associated with that machine identity?

Please guide me on the expected product behavior and best-practice configuration for choosing the correct certifier and avoiding self-certification.

Hello Isha,

For MIS, the Application Identity / Machine Identity is mainly the governance container. In a Machine Accounts certification campaign, the reviewer is really reviewing the access tied to that application identity, mainly the entitlements coming from the correlated machine accounts.

So in the review screen, you select the Machine Identity/Application Identity and review the Entitlements tab. It is not a separate “machine identity object certification” in the same way we think of a normal identity certification.

For reviewer routing, the important part is the reviewer option selected when the campaign is created. For machine account campaigns, Account Owner is usually the right reviewer. If the machine account owner is not mapped, ISC falls back to the Source Owner. So I would make sure the Machine Account Owner mapping is populated correctly if you want the actual application/service owner to review the access.

The Application Identity Primary Owner and Additional Owners are more for ownership, accountability, and succession of the application identity. Additional owners help if the primary owner becomes inactive. I would not assume the Application Identity Primary Owner automatically becomes the certification reviewer unless your campaign/reviewer configuration is set up to route it that way.

For the user entitlements on the application identity, those are entitlements that grant human users access to that application identity. I would keep that separate from the entitlements assigned to the correlated machine accounts, which are the main access items reviewed in the machine account certification flow.

On self-certification, I would not call it self-certification just because the reviewer is the machine account owner. That is normally the expected ownership review model. Self-certification in ISC is more about a human identity reviewing their own access. If your audit requirement needs independent review, then route the campaign to Source Owner, Individual reviewer, or a Governance Group instead of the account owner.

So the clean setup I would suggest is:

Map Machine Account Owner properly → correlate machine accounts to the correct Application Identity → run Machine Accounts certification → use Account Owner for ownership review, or Source Owner/Governance Group where independent review is needed.

Thank you for the clarification.