Birthright access via role still appears for app approval in certifications

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi all,

We are seeing unexpected behaviour during user access review certifications.

Our design is:

  • A role provides birthright access.

  • That role assigns an Entra security group.

  • The security group grants access to an application.

During a user access review, SailPoint correctly identifies the security group as birthright and does not require it to be reviewed.

However, SailPoint still requires the reviewer to make an approve or revoke decision on the application assignment itself.

It appears that SailPoint understands the group is birthright but does not understand that the application access is downstream of that group and fully dictated by the role.

From a reviewer’s point of view, this is confusing. The app access cannot be meaningfully revoked without breaking the role-based birthright model.

Is this expected behaviour?

If not, is there a way to configure certifications so that application access inherited solely via a birthright role and security group is also excluded from review?

image
image1013Ă—441 59.3 KB

Cheers,

Sean

2

Hey Sean,

This is interesting. I did some digging through the docs and here’s what I found.

This is expected behavior. What the reviewer is calling “application access” is the access profile ISC detected on the AD account, not the role item itself.

Here’s what’s happening under the hood. Your role assigns the Entra group, the group lands on the AD account, and during identity processing ISC looks at what’s on that account. If the entitlements on the account match every entitlement that makes up an access profile, ISC marks that AP as detected on the identity. Once detected, the AP is treated as standalone access that needs a review decision, even when the same access is also coming from a birthright role.

Two rules I found in this SailPoint doc are in play here. One says access profiles granted through a role don’t appear individually. The other says detected access profiles can be certified. In this case, the detected-access path is what appears to be causing the AP to show up for review.

image
image1396Ă—233 15.1 KB

So this isn’t a role configuration issue on your end. The workaround is to keep that AP out of the campaign in the first place.

For Manager, Source Owner, or Uncorrelated Account campaigns, use a campaign exclusion filter:

Filter Type: Exclusion
Criteria Type: Access Profile
Operation: Equals
Value: <birthright AP name>

Filter on the access profile, not the entitlement under it. The cert item being shown is the AP, so an entitlement-level filter won’t catch it.

For Targeted or Identities campaigns, campaign filters don’t apply. Scope it at campaign creation using Search:

NOT @access(name:"<AP name>" AND type:"ACCESS_PROFILE")

Quick heads up though. Even if the reviewer revokes it, it may not stay gone. If the birthright role still applies, the role can provision/reassign the Entra group again when the assignment is evaluated, detection can pick up the AP again, and you may see it in a future cert. So I believe filtering it out upfront is the cleaner path.

Hope this helps.:slightly_smiling_face:

3

Hi,

Yes — this behavior is generally expected in SailPoint Identity Security Cloud.

ISC evaluates certifications at different layers:

  • It correctly identifies the group (entitlement) as birthright and excludes it

  • But application access is evaluated separately as an access item, even if it’s indirectly granted via that group

Right now, ISC doesn’t fully “collapse” that chain (Role → Group → Application) during certification. So even though the access is technically governed by a birthright role, the application itself is still presented for decision, which can feel redundant.

What you can do

  • Use certification scoping/filters to exclude application access where possible

  • Or rely more on role-based certifications instead of low-level access reviews

  • Some teams also add reviewer instructions to clarify that such access should not be revoked independently

So this isn’t a misconfiguration — it’s more a limitation in how ISC models and presents inherited access during certifications.

4

Thank you both for your time and effort for detailed explanations regarding this.

Glad to hear that it’s working as expected, even if it is unfortunate. Ideally I try to limit as much filtering as possible because once you begin, it can become a rabbit hole of what you do filter/don’t… I’ll look into what you both suggested regarding filtering/scoping.

Surprising that ISC cannot make the connection that it’s Role > SG > App isn’t linked, especially considering on Entra when you review the App - it specifically calls out the SG! Will raise it as an Idea.

Cheers,

Sean

5

https://ideas.sailpoint.com/ideas/GOV-I-5155