The short answer: no, SailPoint and IGA tools are not designed to manage customer identities. Customer identity management (CIAM) is a distinct product category, and the two solve fundamentally different problems despite both living under the broad "identity" umbrella.

Understanding why requires understanding what problem each category was built to solve.

What IGA Tools Are Actually Built For

Identity Governance and Administration tools — SailPoint, Saviynt, Zluri, and others — are built for workforce identity governance. They manage the identities of the people inside your organization: employees, contractors, consultants, and agency workers.

The core questions IGA answers are internal:

• Does this employee have the right access for their current role?
• Was that access granted through a documented approval process?
• Has anyone verified that the access is still appropriate since the last role change?
• When this contractor's engagement ended, was their access fully revoked?

The lifecycle that IGA manages — the joiner-mover-leaver framework — is anchored to employment events: hiring, role changes, and terminations. The source of truth for IGA is typically an HRMS that records these events. When SailPoint, Saviynt, or Zluri are deployed, they're governing the internal workforce population, not external customer accounts.

IGA tools do protect customer data — but indirectly. They ensure that only the right employees can access the internal systems (production databases, S3 buckets, Salesforce records) where customer data lives. The governance is applied to the internal user who accesses the data, not to the external customer whose data is being protected.

What CIAM Is Actually Built For

Customer Identity and Access Management (CIAM) manages the identities of your organization's customers — the millions (or billions) of external users who interact with your products, services, and applications.

The core questions CIAM answers are external:

• How do customers register, log in, and authenticate to your product?
• How do you manage consent, privacy preferences, and data subject rights (GDPR, CCPA)?
• How do you scale authentication to millions of concurrent sessions?
• How do you provide a seamless, branded authentication experience across web and mobile?
• How do you handle progressive profiling, social login, and federation with external identity providers?

CIAM tools are fundamentally different in their design priorities: they're built for scale (millions of identities rather than thousands of employees), for customer experience (the authentication flow is a product touchpoint, not an internal IT process), and for privacy compliance (consent management, data deletion requests, purpose-based data processing).

The leading CIAM platforms include Auth0 (now part of Okta), Ping Identity, ForgeRock, Stytch, and AWS Cognito, among others. These tools were built from the ground up for external customer populations.

Where IGA and CIAM Touch

The boundary isn't completely clean, and there are scenarios where the two categories interact:

Governing internal access to customer data. An IGA platform like Zluri or SailPoint can enforce which employees can access the customer identity database or the CIAM platform's admin console. This is workforce IGA applied to the system that holds customer identities — governing who inside your organization can see customer records, not governing the customers themselves.

Contractor and partner access to customer-facing systems. When an agency worker or third-party consultant needs access to a customer-facing application or its back-end data, IGA governs that access (external identity management for the workforce population). The customer accounts within that application are still outside IGA's scope.

Non-human identity governance at the CIAM layer. As IGA expands into governing non-human identities — service accounts, API keys, bot credentials — the service accounts that connect internal systems to the CIAM platform fall into IGA's expanding scope. The API key that your application uses to call the CIAM platform's authentication endpoints is a non-human identity that IGA can govern; the customer accounts managed by that CIAM platform are not.

Why IGA Tools Aren't Suited for Customer Identity

Even if you tried to use an IGA tool for CIAM, the architectural mismatch would surface quickly:

Scale. IGA tools are designed for thousands of identities with complex governance workflows. CIAM tools are designed for millions of identities with lightweight, low-latency authentication flows. The data models, performance characteristics, and infrastructure assumptions are completely different.

Lifecycle trigger. IGA lifecycle management is driven by employment events from an HRMS. Customer identities have entirely different lifecycle drivers — account registration, email verification, account deletion requests, consent changes. There's no HRMS equivalent for customers.

Compliance focus. IGA compliance is oriented toward SOC 2, ISO 27001, HIPAA access controls, and SOX — workforce access governance requirements. CIAM compliance is oriented toward GDPR, CCPA, and COPPA — privacy regulations that require consent management, data subject rights, and purpose-based processing at the customer level.

User experience requirements. IGA tools are used by IT teams, security teams, and managers for governance workflows. CIAM tools are used by customers interacting with your product — the authentication UX is a customer-facing experience requirement, not an internal IT process.

The Expanding Frontier: NHIs and Where IGA Is Heading

Modern IGA platforms including Zluri are expanding the governance scope beyond human workforce identities to non-human identities (NHIs): service accounts, API keys, OAuth tokens, bot credentials, and AI agent identities. This is where the boundary between IGA and other identity categories gets more interesting.

An AI agent that interacts with customer data on behalf of employees, a service account that connects internal systems to the CIAM platform, an API key that allows a third-party vendor's application to read from your customer database — these non-human identities are increasingly falling into IGA governance scope. Not because IGA is managing customer identities, but because it's governing the machine identities that interact with systems holding customer data.

This NHI expansion is one of the fastest-growing areas in identity governance, and it's where IGA's scope is likely to expand most significantly over the next few years.

Frequently Asked Questions

Does SailPoint manage customer identities?

No. SailPoint and other IGA platforms manage workforce identities — employees, contractors, and service accounts. Customer identities are handled by CIAM (Customer Identity and Access Management) platforms like Auth0, Ping Identity, ForgeRock, or AWS Cognito. IGA tools do protect customer data indirectly by governing which employees can access internal systems where customer data is stored.

What is the difference between IGA and CIAM?

IGA (Identity Governance and Administration) governs the internal workforce: who has access to what, whether that access is appropriate, and what happens when people join, move, or leave the organization. CIAM (Customer Identity and Access Management) governs external customer accounts: how customers register and authenticate, how consent and privacy preferences are managed, and how to scale authentication to millions of users. The two categories have different scale requirements, different lifecycle triggers, different compliance drivers, and different user experience requirements.

What is CIAM and which tools provide it?

Customer Identity and Access Management (CIAM) handles authentication, registration, consent management, and privacy compliance for the customers of a business rather than its employees. Leading CIAM platforms include Auth0 (Okta), Ping Identity, ForgeRock, Stytch, and AWS Cognito. These tools are designed for external user populations at scale, with emphasis on customer experience, privacy compliance (GDPR, CCPA), and performance at millions of concurrent sessions.

How does IGA relate to protecting customer data?

IGA protects customer data indirectly by governing internal access to the systems where customer data is stored. A company's IGA platform ensures that only authorized employees can access the production database containing customer records, that access is certified on a regular cadence, and that access is revoked when employees leave. The governance is applied to the internal user who accesses the data, not to the customer whose data is being stored.