We have list of users assigned with Entitlement A. The entitlement is provisioned directly in Active directory(Source-Managed).
We have recently created a Birtright role for this entitlement in SailPoint ISC. Positive condition assigns the Role and Provision the entitlement for any new user in active directory.
For the users who were already provisioned with this entitlement in Active directory, Based on the condition, birthright role is assigned. Later once the condition become false, SailPoint ISC only revokes the role but AD entitlement is still present as it was source managed/Provisioned directly in AD.
Yes, I believe this behavior is expected, not a bug.
ISC only deprovisions what it provisioned. For your pre existing users, Entitlement A was already on their AD account before the birthright role existed. When the role got assigned to them, ISC didn’t push the entitlement (it was already there), it just associated the role with the existing access. There’s no “assigned by this role” link for ISC to act on when the criteria flips, so the entitlement stays as a source-detected one.
For new users it works correctly because ISC is the one that provisioned the entitlement, so it owns the lifecycle.
Fix for the existing users, one-time cleanup:
Revoke Entitlement A from those identities (certification campaign, Manage Access, or Submit Access Request API).
Let identity processing run. The birthright role will re-provision the entitlement since the criteria still matches.
From that point on, ISC owns the entitlement. When the criteria becomes false later, the role removal will also remove the entitlement.
Yes — this is actually expected behavior in SailPoint Identity Security Cloud.
Since the entitlement was originally source-managed and directly provisioned in Active Directory, SailPoint ISC does not have full lifecycle control over it. The birthright role only governs role assignment/unassignment, not the historical provisioning state of the entitlement in the target system.
Since the entitlement was originally provisioned directly in AD (source-managed), ISC doesn’t have ownership of that access. So even though the birthright role gets removed when the condition becomes false, ISC won’t revoke the entitlement from AD because it wasn’t provisioned through ISC.
In general, deprovisioning only works reliably for access that ISC has granted itself.
For existing users, you might need a one-time cleanup or bring those entitlements under ISC governance (for example via access profiles / managed entitlements) so that future changes are handled consistently.