User reviewing IdentityIQ dashboard with sticky entitlement warning indicators.

Sticky Entitlements in SailPoint IIQ: Causes and Fix

Date Posted:

12 Feb 2026

Category:

Security

Author:

Malarvanan

User reviewing IdentityIQ dashboard with sticky entitlement warning indicators.

Sticky Entitlements in SailPoint IIQ: Causes and Fix

Date Posted:

12 Feb 2026

Category:

Security

Author:

Malarvanan

User reviewing IdentityIQ dashboard with sticky entitlement warning indicators.

Sticky Entitlements in SailPoint IIQ: Causes and Fix

Date Posted:

12 Feb 2026

Category:

Security

Author:

Malarvanan

Introduction

In SailPoint IIQ, whenever entitlement is removed in Target and some issues in Entitlement we would see sticky entitlement error, Let’s see what is this entitlement and why it is in SailPoint

What is sticky entitlements?

“Sticky” entitlements are usually IdentityIQ AttributeAssignments created from LCM requests or certifications, so you end up with two representations of the same group: one coming from aggregation (normal entitlement) and one “assigned/sticky” coming from the AttributeAssignment on the identity.

The key point is that even though the account and entitlements are provisioned through SailPoint LCM provisioning successfully to the target system, the "sticky entitlement" you see in IIQ is not the direct reflection of provisioning success or failure on the target. Instead:

  • The "sticky entitlement" is an AttributeAssignment created and stored in IIQ itself when the LCM request provisions the entitlement with assignment=true in the provisioning plan. This AttributeAssignment persists on the identity object until explicitly removed by a revoke or request cleanup.

  • On the other hand, the "normal" entitlement view in IIQ comes from aggregation during account refresh, reflecting the current state of the account/entitlement from the target system. This shows what is actually present on the target account.

So broadly: the sticky entitlement is an internal IIQ state marking the entitlement as assigned by LCM; the aggregated entitlement is the actual data sensed from the account on the target system.

This means the sticky entitlement may still exist if:

  • The revoke or removal request hasn't yet triggered to remove the AttributeAssignment;

  • There was partial failure or delay in cleanup after provisioning, even though provisioning itself succeeded;

  • Or IIQ has not yet performed an identity refresh to reconcile and remove the sticky assignment.

Therefore, sticky entitlements are not necessarily an indication that the provisioning failed, but rather that IIQ still retains an internal record of assignment needing cleanup or synchronization. This explains why you see the same entitlement twice: one "sticky" from the LCM assignment record, and one normal from the aggregation reflecting the actual target account state.

You can confirm this by checking the status of the Identity Requests and if revokes have run successfully to clean up those sticky AttributeAssignments. Running a refresh identity task also helps IIQ re-sync and clear sticky entitlements that no longer apply.

In summary:

  • Sticky entitlement = AttributeAssignment stored in IIQ from LCM request (assignment=true flag), persists until explicitly revoked or cleaned.

  • Aggregated entitlement = Target system's current entitlement state from account aggregation.

  • Both can appear simultaneously if provisioning succeeded but cleanup or refresh has not happened yet.

Reference

https://developer.sailpoint.com/discuss/t/sticky-entitlement/2026

Rule to clean up sticky entitlements

https://community.sailpoint.com/t5/IdentityIQ-Wiki/Remove-unused-attribute-assignments-for-an-identity-to-stop-auto/ta-p/82403


Stay tuned to our blog to see more posts about

Sailpoint products implementation and its related updates.

Stay tuned to our blog to see more posts about

Sailpoint products implementation and its related updates.

Category:

Security

Stay tuned to our blog to see more posts about

Sailpoint products implementation and its related updates.

Stay tuned to our blog to see more posts about

Sailpoint products implementation and its related updates.

Category:

Category:

Security

Security

Get your

Tailored Quote for your

Organisation

Get your

Tailored Quote for your

Organisation

Introduction

In SailPoint IIQ, whenever entitlement is removed in Target and some issues in Entitlement we would see sticky entitlement error, Let’s see what is this entitlement and why it is in SailPoint

What is sticky entitlements?

“Sticky” entitlements are usually IdentityIQ AttributeAssignments created from LCM requests or certifications, so you end up with two representations of the same group: one coming from aggregation (normal entitlement) and one “assigned/sticky” coming from the AttributeAssignment on the identity.

The key point is that even though the account and entitlements are provisioned through SailPoint LCM provisioning successfully to the target system, the "sticky entitlement" you see in IIQ is not the direct reflection of provisioning success or failure on the target. Instead:

  • The "sticky entitlement" is an AttributeAssignment created and stored in IIQ itself when the LCM request provisions the entitlement with assignment=true in the provisioning plan. This AttributeAssignment persists on the identity object until explicitly removed by a revoke or request cleanup.

  • On the other hand, the "normal" entitlement view in IIQ comes from aggregation during account refresh, reflecting the current state of the account/entitlement from the target system. This shows what is actually present on the target account.

So broadly: the sticky entitlement is an internal IIQ state marking the entitlement as assigned by LCM; the aggregated entitlement is the actual data sensed from the account on the target system.

This means the sticky entitlement may still exist if:

  • The revoke or removal request hasn't yet triggered to remove the AttributeAssignment;

  • There was partial failure or delay in cleanup after provisioning, even though provisioning itself succeeded;

  • Or IIQ has not yet performed an identity refresh to reconcile and remove the sticky assignment.

Therefore, sticky entitlements are not necessarily an indication that the provisioning failed, but rather that IIQ still retains an internal record of assignment needing cleanup or synchronization. This explains why you see the same entitlement twice: one "sticky" from the LCM assignment record, and one normal from the aggregation reflecting the actual target account state.

You can confirm this by checking the status of the Identity Requests and if revokes have run successfully to clean up those sticky AttributeAssignments. Running a refresh identity task also helps IIQ re-sync and clear sticky entitlements that no longer apply.

In summary:

  • Sticky entitlement = AttributeAssignment stored in IIQ from LCM request (assignment=true flag), persists until explicitly revoked or cleaned.

  • Aggregated entitlement = Target system's current entitlement state from account aggregation.

  • Both can appear simultaneously if provisioning succeeded but cleanup or refresh has not happened yet.

Reference

https://developer.sailpoint.com/discuss/t/sticky-entitlement/2026

Rule to clean up sticky entitlements

https://community.sailpoint.com/t5/IdentityIQ-Wiki/Remove-unused-attribute-assignments-for-an-identity-to-stop-auto/ta-p/82403