IAM vs CIAM: what is the difference, and which platform to choose when you manage both employees and end customers

Workforce IAM manages an organisation's internal identities — employees and contractors — with priority on control, federation with the corporate directory and immediate revocation; CIAM manages the identities of customers and end users, with priority on self-service registration, frictionless login, privacy consent and large volumes. If you need both you do not need two products: a platform like LoginMaster separates employees and customers into distinct tenants or projects, each with its own policies, 2FA and branding, at a flat price per tenant and project with unlimited users, so customer-base growth does not grow the bill.

IAM and CIAM in one sentence each

Workforce IAM: the system that decides which employees and contractors can access which business applications, starting from an identity the organisation creates, owns and revokes.

CIAM: the system that lets customers create an identity on their own to use a digital product, sign in with minimal friction and control their own data and consents.

The difference is not technological — both use OAuth 2.0, OpenID Connect, MFA and tokens — but about who owns the identity. In workforce the identity belongs to the organisation; in CIAM it belongs to the user, who can delete it, export it and withdraw consent. Every other difference follows from this one. For the basics see what IAM is and the CIAM page.

Before comparing: classify who needs access

Almost no organisation has only "employees" and "customers". Before choosing, write the full list of populations, with the 3-year volume and the identity source:

The "grey zone" is where two-product architectures break: the external consultant is not in the corporate directory, yet must access internal applications under the same rules as employees. The same goes for non-human identities, covered in the guide on AI agent governance.

IAM vs CIAM: compared on 14 dimensions

Managing employees and customers: the three architectures

Architecture 1 — One platform, separate contexts

A single identity system, with employees and customers in isolated contexts (tenants, realms, projects or organisations, depending on the product's vocabulary). Each context has its own policies, login method and branding.

• Pro: one contract, one audit model, one SDK to integrate; external consultants and partners fit without exceptions.
• Pro: common rules (credential hashing, logs, session policies) are applied once.
• Con: if isolation is only logical, a configuration error can expose one context to another; how the platform separates contexts matters.
• Con: the platform must cover both workforce federation and self-service registration: not every solution built for one case covers the other well.

Architecture 2 — Two distinct products

A workforce IdP (typically Microsoft Entra ID or Okta Workforce) for employees and a separate CIAM for customers.

• Pro: each product is optimised for its case; clean separation between internal and external identities.
• Con: two contracts, two pricing models (per seat + per MAU), two consoles, two log formats to correlate for audit.
• Con: applications used by both populations (a customer portal with access for internal support) must trust two token issuers.
• Con: the grey zone (consultants, partners) lands in one of the two systems by convention, not by design.

Architecture 3 — Workforce IdP federated into the CIAM

The corporate directory remains the source of employee identities, but application authentication always goes through the CIAM platform, which federates Entra ID or Google Workspace via OpenID Connect for employees and handles registration and login for customers.

• Pro: applications talk to a single token issuer; employees keep using corporate credentials and their MFA.
• Pro: when IT disables the account in the directory, access through federation stops without touching the CIAM platform.
• Con: the workforce directory licence is still needed (for employees it usually already exists: Microsoft 365 or Google Workspace).
• In practice it is the architecture that best covers companies that sell digital products and already run Microsoft 365 or Google Workspace.

How it maps in LoginMaster

LoginMaster combines architectures 1 and 3: one platform with cryptographically isolated tenants and projects, which federates the corporate directory for employees and manages customer identities directly. Applications integrate through the TypeScript and .NET SDKs and the REST API; OAuth 2.0 / OpenID Connect is used for SSO to Google Workspace and Microsoft Entra ID, which are the two directories that can be federated today (other IdPs, such as Okta or SAML-only ones, are on the roadmap).

• Cryptographic, not just logical, isolation: every tenant and project has its own keys and every token is signed twice (Tenant and Cloud). A token issued in the customer project is not valid in the internal project.
• Personal data on the tenant: with the Tenant-Cloud architecture the Cloud only processes encrypted and pseudonymised data; not even LoginMaster can access your employees' or customers' data. Details in vendors that cannot read credentials.
• Per-project TOTP 2FA: disabled, optional or required, so mandatory for employees and optional for customers on the same platform.
• Per-tenant white-label: login page, emails and domain with the product brand, with no reference to the vendor. See white-label authentication.
• Flat pricing: licensing per tenant and project, unlimited users, no per-user or per-MAU fee, no plan that unlocks SSO, 2FA or white-label. Details on pricing.
• Integration: official TypeScript and .NET SDKs and REST API, the same for the internal app and the customer-facing product.

Cost as customers grow

Here is how spend behaves in the three architectures when the customer base grows from a few thousand to hundreds of thousands of users, at constant headcount. We do not quote competitor figures because price lists change; the point is what drives cost.

Decision matrix by scenario

Product categories on the market

An orientation by category, not a ranking:

• Workforce IAM: Microsoft Entra ID, Okta Workforce Identity, JumpCloud. Built for employees, directories and business applications; per-user pricing.
• Managed CIAM: Auth0 (now part of Okta), Frontegg, Firebase Authentication, Amazon Cognito. Built for customer identity; pricing typically tied to active users.
• Self-hosted open source: Keycloak covers both cases with realms, but you operate infrastructure, upgrades and security yourself (see Keycloak self-hosted vs managed IAM).
• LoginMaster: a European platform, designed and built in Italy, covering workforce (Entra ID / Google Workspace federation, mandatory 2FA) and CIAM (registration, white-label, multi-tenant) with personal data on the customer's tenant and flat pricing.

For direct comparisons see the best CIAM platform for multi-tenant B2B, European alternatives to Cognito, Firebase and Auth0 and Keycloak self-hosted vs managed IAM.

Security: same principles, different controls

Running employees and customers on the same platform does not mean applying the same rules. The principle is least privilege for both, with calibrated controls:

• Employees: mandatory 2FA, minimal application roles, periodic access reviews (see access governance), revocation on the day they leave.
• Customers: strong credential hashing against mass theft (Argon2 with split-salt), 2FA offered and required on sensitive operations, minimisation of data collected at registration.
• Both: access logs usable as audit evidence and clean separation between contexts, so an incident on one project does not become an incident on all of them.

For periodic permission reviews see access governance; for SSO with the corporate directory the SSO page and the guide to SSO with Entra ID and Google Workspace.

What ships today and what is on the roadmap

A sound choice requires knowing what you can use today. Available in LoginMaster: SSO with Google Workspace and Microsoft Entra ID via OAuth 2.0 / OpenID Connect, per-project TOTP 2FA, TypeScript and .NET SDKs with REST API, multi-tenant with cryptographic isolation and double-signed tokens, per-tenant white-label, device subjects and API keys.

Checklist before choosing

1. 1Have I listed every population, including consultants, partners and non-human identities?
2. 2Do I know where each one's identity comes from (directory, registration, customer directory)?
3. 3Have I modelled the 3-year cost with expected customer growth, not just headcount growth?
4. 4Does the platform isolate contexts cryptographically or only logically?
5. 5Can I have mandatory 2FA for employees and optional 2FA for customers?
6. 6Can customer login, emails and domain carry my brand?
7. 7Where does personal data live, and who at the vendor can read it?
8. 8Which features I need are on the roadmap and not yet available?