SailPoint Identity Security Cloud (ISC, formerly IdentityNow) is a genuinely capable enterprise IGA platform. It has the broadest connector library in the market, the most mature access certification workflow, the deepest enterprise compliance track record, and the largest implementation partner ecosystem. If you're doing hands-on evaluation and finding gaps, you're not misunderstanding the product — you're finding real limitations that practitioners consistently encounter.

1. Implementation and Configuration Complexity

The most consistent pain point across SailPoint practitioners: the implementation is complex and the ongoing maintenance surface is large.

Tedious role and access profile setup. SailPoint's foundational architecture is built around access profiles — administrators define upfront what permissions a role entails, and the platform enforces those definitions. Building a complete role structure that accurately reflects your organization's access patterns requires significant upfront analysis and manual configuration. For organizations with complex org structures or frequent role changes, keeping role definitions current is an ongoing maintenance commitment.

Configuration is at the resource level, not centralized. Unlike platforms that manage configuration at a tenant or platform level, much of SailPoint's configuration is maintained at the individual source, application, or workflow level. When something breaks or needs updating, the troubleshooting surface is distributed rather than centralized, which makes maintenance harder for small teams.

Connector configuration and maintenance. Connecting a new application requires configuring the connector, mapping attributes, defining correlation rules, and testing provisioning and deprovisioning flows. For standard applications with mature SCIM connectors, this is manageable. For non-standard applications, the configuration effort is significant and ongoing — when the application's API changes, the connector configuration may need to be updated.

2. Static Governance vs. Real-Time Activity Intelligence

SailPoint's governance model is fundamentally state-based: it manages what access exists according to what has been provisioned. What it does less well is dynamic, behavior-based governance.

Access profiles don't adjust based on behavior. A user can have "Senior Analyst" access assigned and governed correctly by SailPoint while never using 60% of the applications in that role's access profile. SailPoint knows they have the access; it doesn't automatically surface that the access isn't being used or recommend right-sizing based on actual usage patterns.

Limited activity and usage monitoring. SailPoint knows who has access to what and when that access was provisioned or certified. What it does less well is answering "what is this user actually doing with their access" or "which of this role's permissions has this user exercised in the past 90 days." Dormant account detection exists but requires configuration and doesn't use real-time behavioral signals as naturally as platforms that were built on usage data from the start.

Role mining is improving but not yet native to ISC for all use cases. AI-driven role mining — analyzing actual usage patterns to generate role recommendations — is being added to the ISC platform, but practitioners evaluating it find that it works better for straightforward role structures than for complex enterprise environments with many role overlaps and exceptions.

3. Shadow IT and Discovery Gaps

SailPoint's visibility scope is the applications it has been configured to govern. For the applications outside that perimeter, it has limited native discovery capability.

Shadow IT outside the connector catalog. Applications that employees use but that IT hasn't formally onboarded to SailPoint are invisible to its governance. SailPoint doesn't have a native multi-source discovery engine that uses browser agents, financial transaction analysis, or expense system data to surface unmanaged applications. Discovery of the full SaaS footprint requires either integration with a separate CASB or SaaS management platform, or manual inventory work.

Shadow AI governance. AI tools adopted by employees without IT approval — ChatGPT, Claude, Gemini, and many others — often authenticate through OAuth or social login rather than corporate SSO. SailPoint has no native mechanism to discover and classify these tools. For organizations concerned about data exposure through employee-used AI tools, this is a gap that requires additional tooling.

Non-human identity management. SailPoint was designed around human identities — employees, contractors, external users. Service accounts, API keys, OAuth tokens, and AI agent credentials represent an expanding identity surface that SailPoint's data model and governance workflows handle less naturally. NHI governance in SailPoint typically requires significant custom configuration rather than being a built-in capability.

4. Reviewer Experience and Access Certification UX

Access certification is a core IGA function, and the reviewer UX is where SailPoint ISC draws consistent criticism from end users.

Technical role names without human-readable context. When a reviewer sees "IDC-IAM-User" or "Group-Admin-Prod" in a certification campaign, they often don't know what that permission enables. SailPoint's native certification interface doesn't consistently surface human-readable descriptions of what a role or entitlement allows unless the configuration explicitly includes those descriptions. Without context, reviewers default to approving everything — which defeats the governance purpose of the certification.

Limited AI-assisted decision support. Modern IGA platforms are adding AI layers that recommend actions — flagging dormant accounts for revocation, surfacing accounts that are unusual relative to department peers, highlighting high-risk entitlements that warrant closer review. SailPoint's AI capabilities are developing but are not yet as integrated into the certification workflow as platforms that built AI-assisted reviews as a core feature.

Campaign completion friction. Reviewers who receive certification tasks outside their normal workflow — via email rather than an integrated portal they already use — have higher abandonment rates. The campaign management functionality for tracking completion, sending reminders, and escalating non-responses works, but the reviewer experience of completing a certification is more friction-heavy than purpose-built alternatives.

5. Integration Limitations

Write access sensitivity for critical applications. Provisioning and deprovisioning in SailPoint requires write access to connected applications. For security-sensitive applications like Okta itself, giving SailPoint write access creates a governance concern: the IGA platform that's supposed to audit access also has the ability to modify it. SailPoint has made progress on granular permission scoping for some integrations, but this remains a concern for security teams reviewing the integration design.

Non-API applications. Legacy IGA platforms including SailPoint use pre-built connectors that require application APIs. For applications without APIs — older SaaS tools, custom internal applications, applications at licensing tiers that don't expose APIs — SailPoint's governance coverage is limited. Manual processes, CSV-based provisioning, or custom development are the typical workarounds.

AI-powered browser automation (agentic AI) represents an emerging alternative that allows governance actions to be taken directly in application UIs without requiring a formal API, but SailPoint's implementation of this capability is in earlier stages than purpose-built platforms that developed it as a core feature.

Connector maintenance when applications change. When a connected application updates its API, the SailPoint connector may need to be reconfigured. In a large implementation with dozens or hundreds of connected applications, API changes that break connectors are an ongoing operational concern. The connector maintenance responsibility may fall on the customer's team, the implementation partner, or SailPoint Professional Services depending on the connector type and support agreement.

6. The IIQ-to-ISC Migration Tension

For practitioners coming from SailPoint IIQ (the on-premises platform), evaluating ISC reveals meaningful capability gaps relative to the mature IIQ feature set. ISC is a newer platform with faster development velocity, but some IIQ features — particularly around complex provisioning rule customization and certain connector types — aren't yet fully replicated in ISC.

Organizations being encouraged to migrate from IIQ to ISC need to audit their current IIQ configuration against ISC's feature set before committing to a migration timeline. Gap analysis often surfaces IIQ customizations that require rethinking on ISC or that extend the migration timeline beyond initial estimates.

Where SailPoint ISC Is Genuinely Strong

To be useful as an evaluation resource rather than just a list of criticisms:

Connector breadth and ecosystem. SailPoint's connector catalog is the broadest in the market. For large enterprises with complex application stacks, this reduces custom connector development and implementation overhead for standard applications.

Compliance depth. SOX, ISO 27001, SOC 2, HIPAA — SailPoint's certification campaign engine and audit trail capability are mature and produce the evidence format that enterprise auditors expect. For regulated industries, this depth is well-established.

Enterprise implementation partner ecosystem. Finding experienced SailPoint implementation partners is easier than for most alternatives. This matters for large, complex deployments that require partner involvement.

Scalability. At 50,000+ users and hundreds of connected applications, SailPoint's underlying architecture scales. Platforms that perform well in mid-market implementations may show performance and complexity issues at enterprise scale.

Frequently Asked Questions

What are the biggest pain points in SailPoint ISC?

The most consistently cited pain points are: implementation complexity and maintenance burden (especially for teams without dedicated SailPoint expertise), the static access profile model that doesn't adapt based on actual usage patterns, limited native discovery for shadow IT outside the configured application set, reviewer fatigue from certification UX that doesn't provide adequate context for non-technical reviewers, and limitations around non-API applications that require manual or custom integration approaches.

How does SailPoint ISC compare to modern mid-market IGA platforms?

SailPoint ISC has broader connector coverage, deeper compliance certification track record, and a more mature enterprise partner ecosystem. Modern mid-market platforms deploy faster, cost less, typically include real-time usage monitoring as a native capability, handle shadow IT discovery through browser agents and financial data analysis, and offer better reviewer UX in access certification workflows. For organizations under 5,000 employees, the modern platforms often provide better total value. For large enterprises with complex on-premises and hybrid infrastructure, SailPoint's depth may justify the additional overhead.

What is the difference between SailPoint IIQ and SailPoint ISC?

SailPoint IIQ (IdentityIQ) is the mature on-premises platform that most large enterprise customers historically deployed. SailPoint ISC (Identity Security Cloud) is the cloud-native SaaS version that SailPoint is actively developing and encouraging customers to migrate to. ISC has faster feature development velocity but hasn't yet replicated all of IIQ's mature features. Organizations currently on IIQ face a migration decision on SailPoint's timeline rather than their own.