CIAM vs. Workforce IAM

Overview

CIAM offers cyber security professionals a unique challenge: In which other area in cyber security does one have a chance to protect customers' data whilst challenging oneself with near endless complexity?

Many other areas of cyber security – e.g., endpoint security, cloud security, threat and vulnerability management – are internally focused within an IT department. CIAM is externally focused on customers; specifically, how to securely identify, authenticate, and authorise customers, and hence there is a more direct impact to a improving an organisation's cyber security. Likewise, as more organisations move services online, customers must register and log in to access these services.

CIAM and Workforce IAM are different challenges with different characteristics. Workforce IAM is B2E users (i.e., internal employees) and B2B users (i.e., business partners), and CIAM is B2C users (i.e., customers or members).

CIAM tends to be more complex due to the number of users and hence scale required, multiple accounts for a single user, the requirement to support older devices, and the need to make user registration and authentication seamless not to scare away potential customers. CIAM is also about choice. Customers choose to interact with organisations, including choosing which subscription to use, additional MFA factors to enroll, when to close their account, etc.

Aspect	CIAM	IAM
Who's Responsible	Product teams, digital teams, often outside IT/cyber security/architecture.	Cyber security, IT operations, architecture.
User Type	External users (customers, members) who choose to engage, close accounts, or select subscriptions.	Internal users (B2E: employees, contractors, vendors, board members). External users (B2B: business partners such as vendors).
User Size	Scales to billions (e.g., Google).	Limited to employees plus onboarded partner accounts.
User Relationships	Users may be linked to other users (e.g., children to parents, family accounts, recovery contact).	N/A.
User Impersonation	Common that call centre staff, for example, can impersonate users to make changes on the user’s behalf.	Not generally available.
Regulations	May require ID verification or MFA (e.g., APRA’s MFA letter).	Typically unregulated, may be part of MFA requirements.
Identity Verification	ID checks for sign-up/profile updates/regulatory requirements (e.g., correcting contact details, certain financial transactions). Verifiable credentials becoming available.	Employees verified pre-employment. Account resets via managers/HR. Verifiable credentials becoming available.
Frequency of Sign In	Ranges from daily to once a decade.	Usually daily.
Device / Client	Unmanaged customer devices (mobiles, browsers), often older OS. Passkeys need iOS16+/Android 9+.	B2E: Organisation-managed devices. B2B: Partner-managed devices or organisation-managed VDIs.
User Registration / Sign Up	Online signup or digital channel activation.	Onboarding upon joining or as needed.
User Deregistration / Account Closure	Users can close accounts.	Accounts closed when users leave the organisation.
Number of Accounts	One or multiple (e.g., separate transaction and trading accounts for a single bank).	One account per user, except IT admins.
User Provisioning	Provisioned at registration/digital channel activation, with details in user directory and IdP.	B2E: Created in HR systems during onboarding, ideally via IGA to directories such as Entra ID. B2B: Created via requests (e.g., ServiceNow) or IGA integrations.
Identification	Self-chosen username, email, or customer ID, with automated retrieval. Users can often log in with multiple identifiers (e.g., customer ID or email address).	Organisation-issued username.
User Directory	Often loosely coupled with authentication services. Digital channel activation may provision IdP accounts. Integrations (LDAP, APIs, CSV) update user details (e.g., email address and phone number).	Often tightly coupled directories and authentication services (e.g., Entra ID). B2B may federate with partner IdPs.
Authentication Standards	OIDC on OAuth2 for API-based architectures.	OIDC, SAMLv2, LDAP, or local authentication.
Authentication Factors	Social login, passwords, OTPs, voice calls, security questions, passkeys. Flexible with risk/adaptive and step-up authentication. Browsers can be “trusted”.	Passwords, passkeys, certificates, smartcards. Risk/adaptive authentication with device threat data (e.g., EDR). Restricted to specific locations or compliant devices.
Birthright Access	Based on subscription choice.	Mandated by employment type (e.g., employees access performance sites, contractors do not).
MFA Factors	OTPs, passkeys, authenticator apps (e.g., Google, MS), or custom apps. User choice available.	Passkeys and authenticator apps, mandated by IT.
Authorisation Standards	OAuth2.	OAuth2.
Authorisation Approach	RBAC, ABAC, ReBAC. Complex relationships (e.g., staff as customers, customer-to-customer relationships like power of attorney).	RBAC, ABAC, MAC.
Credential Reset	Self-service reset via security questions, OTPs, magic links, or ID submission. Call centres available. Verifiable credentials becoming available.	Self-service reset with IT helpdesk support. Verifiable credentials becoming available.
User Access Reviews	May include if users are still eligible for a subscription/service.	Via IGA tools or manually.