Customer identity and workforce identity both authenticate people and grant access, but treating them as the same problem produces either a customer sign-in nobody completes or an employee directory that cannot be governed. Workforce IAM manages known employees, contractors and their access to internal systems; customer identity and access management (CIAM) manages self-registered consumers and business customers who reach your products over the internet. The two differ in who the users are, how many there are, which threats dominate, which laws apply and what success looks like. This guide gives the short answer, a side-by-side comparison, guidance on when to use each, the security trade-offs and how the two should connect. It is for identity architects, product security teams and CISOs deciding whether one platform can serve both populations.
Key takeaways
- The user relationship is the real difference. Workforce users are hired, vetted and managed by you; customers arrive anonymous, choose whether to stay and can leave at any time.
- Scale and friction budgets point in opposite directions. Workforce IAM can mandate phishing-resistant MFA for everyone; CIAM has to win millions of sign-ins with risk-based, mostly invisible controls.
- The dominant threats differ. Workforce attacks target privilege, help desks and federation trust; customer attacks are high-volume credential stuffing, fake accounts and recovery abuse.
- Governance changes shape. Workforce governance is joiner-mover-leaver and access reviews; customer governance is consent, preferences and data subject rights.
- Keep the populations separate but connected. Run separate tenants or directories for customers and staff, then link them deliberately for support access, partner portals and shared detection.
The short answer
Use workforce IAM for anyone you employ or contract and for the internal applications they use. Use CIAM for anyone who signs up to your product, service or partner portal and for the public applications and APIs they use. The two share protocols (OpenID Connect, SAML, OAuth 2.0, FIDO2) and many building blocks, but they optimise for different outcomes: workforce IAM for control and productivity, CIAM for conversion, trust and privacy at internet scale.
NIST SP 800-63-4, which supersedes SP 800-63-3, applies its digital identity guidance regardless of constituency, naming the public, business partners, and government employees and contractors, and it primarily addresses services that interact with external users. Its Digital Identity Risk Management process is a useful shared method: define the online service, assess impact, select initial assurance levels, tailor, then continuously evaluate. The same process run for a staff portal and a customer app produces different answers, and that is the point.
CIAM and workforce IAM side by side
| Dimension | Workforce IAM | CIAM |
|---|---|---|
| Who the users are | Employees, contractors, sometimes partners; identity established by HR or a sponsor | Consumers and business customers; self-registered, identity claimed rather than known |
| Source of truth | HR system feeding the directory (joiner-mover-leaver) | The user themselves, plus optional identity proofing or KYC for regulated services |
| Typical scale | Hundreds to hundreds of thousands of accounts, steady load | Thousands to hundreds of millions of accounts, seasonal and campaign spikes |
| Devices | Often managed, with device compliance signals | Unmanaged and shared; device signals are probabilistic |
| Authentication baseline | Mandatory MFA; phishing-resistant MFA for admins and increasingly for all staff | Passkeys offered and encouraged; passwords plus risk-based step-up remain common |
| Authorisation model | Roles, groups, entitlements across many internal apps | Plans, subscriptions, account ownership and delegation within your own product |
| Governance | Access requests, certifications, segregation of duties | Consent records, preference management, account deletion and export |
| Success measure | Access correct, least privilege, audit evidence | Sign-up and sign-in completion, account takeover rate, fraud loss, privacy compliance |
| Support channel | Internal service desk that can verify staff against HR records | Customer service, often outsourced or automated, with little to verify against |
| Federation | Inbound to SaaS apps; outbound trust with partners | Social login, B2B customer federation, OAuth for third-party apps and AI agents acting for customers |
| Key NIST SP 800-53 control | IA-2 Identification and Authentication (Organizational Users) | IA-8 Identification and Authentication (Non-organizational Users) |
The live Customer IAM (CIAM) Guide covers customer identity controls in depth; this page concentrates on where the two disciplines diverge and where they must meet.
When to use each
Use workforce IAM when
- You employ or contract the person: staff, contractors and temporary workers belong in the workforce directory so leaving the organisation ends their access. See the Joiner-Mover-Leaver Guide.
- The application is internal: HR, finance, engineering tooling, admin consoles of your customer platform and anything that needs access reviews.
- You need device and network context: conditional access tied to managed devices is a workforce pattern. See the Conditional Access Guide.
Use CIAM when
- People sign themselves up: retail, media, banking, healthcare portals, citizen services and any self-service registration.
- Business customers manage their own users: B2B SaaS where each customer organisation federates its own IdP or invites its own staff. See the B2B CIAM and Organisation Management Guide.
- Consent and privacy shape the flow: progressive profiling, marketing preferences and deletion requests are CIAM features, not workforce ones.
- Customers delegate access: family members, carers, financial advisers or AI agents acting for a customer. See Delegated and Proxy Access in CIAM.
The grey zones
| Population | Usual home | Why |
|---|---|---|
| Partner staff using your partner portal | CIAM (B2B) with federation to the partner's IdP | You do not manage their lifecycle; the partner does |
| Contractors with internal system access | Workforce IAM with an expiry date and a sponsor | They touch internal systems and need reviews |
| Franchisees, dealers, agents | CIAM (B2B) unless they access internal systems | Large, external, self-managing populations |
| Employees who are also customers | Two separate identities | Merging them lets a customer-side compromise reach staff access |
| Support staff acting on customer accounts | Workforce identity with a controlled, logged path into CIAM | Support access is privileged access to customer data |
Security trade-offs
Authentication strength versus completion
Workforce teams can follow CISA's guidance to implement phishing-resistant MFA (FIDO/WebAuthn or PKI-based), starting with system administrators, help desk staff and other high-value targets. NIST SP 800-63B-4 goes further for federal systems: agencies shall require staff, contractors and partners to use phishing-resistant authentication. CIAM teams usually cannot mandate a method, so the same guideline's requirement that AAL2 verifiers offer at least one phishing-resistant option is the realistic baseline: offer passkeys, prompt adoption at moments of trust, and step up on risk.
- Passkey type: synced passkeys suit customers because they survive device loss. SP 800-63B-4 places syncable authenticators at AAL2 or below, so workforce roles needing AAL3 use device-bound keys. See Device-Bound Passkeys.
- Passwords that remain: both populations follow the same SP 800-63B-4 rules: at least 15 characters when the password is the only factor, at least 8 when used with another factor, a blocklist of compromised passwords, no composition rules and no forced periodic change.
- Lockout: the guideline caps consecutive failures at 100 per authenticator. In CIAM, aggressive lockout becomes a denial of service against customers, so OWASP recommends counting failures per account and avoiding lockouts attackers can trigger at will.
Account recovery and support
The workforce help desk can check a caller against HR records, manager approval or a video call; customer support usually has only what the customer typed at registration. Both channels are prime targets. In the MGM Resorts breach, attackers reportedly talked a help desk into resetting access and reached identity administrator control. On the customer side, the Meta AI Instagram account takeover showed an AI support assistant linking attacker email addresses and sending recovery links without verifying the requester. The control is the same in both worlds: support staff and support bots trigger verified recovery flows; they never change credentials or contact details directly.
Threat volume and shape
| Threat | Workforce pattern | Customer pattern | ATT&CK |
|---|---|---|---|
| Credential stuffing | Lower volume, aimed at VPN and SSO | Very high volume, automated, on login and API endpoints | T1110.004 Credential Stuffing |
| Password spraying | Common against IdPs and legacy protocols | Common where usernames are email addresses | T1110.003 Password Spraying |
| MFA fatigue | Push bombing of staff | Less common; SMS one-time code interception and SIM swap more so | T1621 Multi-Factor Authentication Request Generation |
| Session theft | Infostealer cookies for SSO and admin consoles | Stolen session cookies for retail and banking apps | T1550.004 Web Session Cookie |
| Abuse of valid accounts | Privilege escalation and lateral movement | Fraud, loyalty theft, data scraping | T1078 Valid Accounts |
| Fake accounts | Rare | Promotion abuse, spam, money mule accounts | Business logic abuse |
The 23andMe breach is the reference CIAM case: reused passwords opened more than 18,000 accounts while MFA was optional, and a relative-matching feature let those logins expose data on almost 7 million people. A workforce directory rarely has that fan-out from one ordinary account to millions of other people's data. For defences, OWASP's Credential Stuffing Prevention Cheat Sheet lists MFA and step-up, CAPTCHA on suspicious attempts, IP reputation, device and connection fingerprinting (for example JA3), non-email usernames, multi-step login, breached password checks and notifying users of unusual events. See the Account Takeover Prevention Guide and the Bot Management Guide.
Privacy, consent and enumeration
- Lawful basis and consent: customer identity data is personal data held for your purposes, so consent records (purpose, time, version), withdrawal and data protection by design and by default under GDPR Articles 7 and 25 shape the registration flow. NIST SP 800-53 PT-4 Consent is the control reference. See the Consent Management Guide.
- Account enumeration: workforce sign-in pages can reveal little because usernames are internal; customer sign-up, sign-in and reset flows must return generic messages and similar response times, as the OWASP Authentication Cheat Sheet advises, or attackers learn which emails hold accounts.
- Identity proofing: workforce identity is proofed through hiring; CIAM proofs only when the service needs it, using NIST IAL levels. See the Identity Proofing and KYC Guide.
Tokens and APIs
Customer apps are mostly public clients: browser single-page apps and mobile apps that cannot keep a secret. RFC 9700 (BCP 240, January 2025) requires PKCE for public clients, says the implicit grant should not be used and the resource owner password credentials grant must not be used, and requires refresh tokens for public clients to be sender-constrained or rotated. Workforce apps are more often confidential server-side clients behind SSO, where token theft from managed devices and admin consoles is the bigger concern. See the Device-Bound Session Credentials (DBSC) Guide.
How CIAM and workforce IAM work together
Most organisations need both, and the risk sits in the seams between them.
- Separate the directories: run customer identities in their own tenant, realm or platform instance, with separate signing keys and admin roles. A customer-side breach must not yield staff credentials, and a staff compromise must not quietly list every customer account.
- Treat CIAM administration as privileged workforce access: the people who configure the CIAM platform, edit flows or impersonate customers sign in with workforce identities, phishing-resistant MFA and just-in-time elevation. See the JIT Access Guide.
- Design support impersonation explicitly: "log in as customer" features need a ticket reference, customer consent where possible, time limits, read-only defaults and a full audit trail visible to the customer.
- Govern non-human identities in both: CIAM platforms carry management API tokens, signing keys and machine-to-machine clients for partners. These are workforce-owned NHIs and need owners, rotation and vaulting. See the Human vs Non-Human Identity page.
- Share detection, not accounts: send both platforms' sign-in, recovery and admin events to the same SIEM so analysts can see an attacker move from a customer account to a support tool or from a staff account into CIAM configuration.
- Align policy, differ in defaults: one identity standard can define assurance levels for both, with different defaults per population. See the Identity reference architecture for workforce, customer and non-human identities.
Can one platform do both?
Many identity products can technically host both populations. The deciding questions are whether you can isolate the populations (separate tenants, keys and admin roles), whether the product meets CIAM scale and branding needs, whether it supports workforce governance features such as access reviews and HR-driven provisioning, and whether licensing per active user makes customer volumes affordable. Smaller organisations with a few thousand customers often run both on one product in separate tenants; large consumer businesses usually run a dedicated CIAM platform. Either way, separation of tenants is the security requirement; the number of vendors is a commercial decision.
Detection and measurement
| Metric | Workforce IAM | CIAM |
|---|---|---|
| Strong authentication coverage | Percentage of staff and of admins on phishing-resistant MFA | Percentage of active customers with a passkey or second factor |
| Attack pressure | Password spray and MFA fatigue attempts per week | Credential stuffing attempts blocked per day; bot share of login traffic |
| Compromise rate | Confirmed compromised accounts per quarter | Account takeovers per 100,000 active accounts |
| Recovery risk | Help desk resets for privileged users and how they were verified | Recovery requests that change email or phone; takeovers that started with recovery |
| Hygiene | Leaver accounts still enabled after 24 hours | Dormant accounts with stored payment data; deletion requests closed within the legal deadline |
| Experience | Sign-in failures and help desk tickets per user | Sign-up and sign-in completion rates after each control change |
Log in both: sign-in success and failure with reason, MFA enrolment and removal, recovery initiation and completion, contact detail changes, new sessions on new devices, admin configuration changes and token issuance to third-party clients. In CIAM, watch for one device or network touching many accounts; in workforce IAM, watch for one account touching many systems. See the Identity Security Metrics Guide.
Framework mapping
| Framework | Workforce IAM | CIAM |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-2, AC-2 Account Management, AC-6 Least Privilege | IA-8, IA-5 Authenticator Management, PT-4 Consent |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03, PR.AA-05 | PR.AA-02 (proofing in context), PR.AA-03, DE.CM-03 |
| NIST SP 800-63-4 | AAL2 or AAL3 with phishing-resistant authenticators; FAL for federation to SaaS | IAL chosen per service; AAL2 with a phishing-resistant option offered |
| ISO/IEC 27001:2022 Annex A | 5.16 Identity management, 5.18 Access rights, 8.5 Secure authentication | 5.16, 5.17 Authentication information, 8.5, plus 5.34 Privacy and protection of PII |
| CIS Controls v8.1 | Control 5 Account Management, Control 6 Access Control Management | Control 6 for MFA on externally exposed applications |
Common mistakes
- Putting customers in the workforce directory: customer accounts then inherit internal app visibility, licence costs and directory enumeration risk, and a customer credential stuffing wave becomes a workforce incident.
- Applying workforce friction to customers: mandatory hardware keys or monthly re-verification drive abandonment and push customers to recovery flows, which are weaker.
- Applying customer leniency to staff: optional MFA and long remembered sessions are reasonable defaults for a shopper, not for an employee with admin rights.
- Forgetting the support path: human or AI support that can change a customer's email or phone without verification bypasses every authentication control, as both the MGM and Meta cases show.
- Leaving CIAM admin access unmanaged: management API tokens and admin accounts for the customer platform sit outside workforce reviews and PAM because "it is a customer system".
- Ignoring fan-out features: sharing, family, relative-matching and organisation features multiply the impact of one taken-over customer account, as the 23andMe case shows.
Practitioner checklist
- Decide, per population, whether it belongs in workforce IAM or CIAM using the grey zone table, and document exceptions.
- Keep customer and staff identities in separate tenants with separate signing keys and admin roles.
- Require phishing-resistant MFA and just-in-time elevation for everyone who administers either platform.
- Offer passkeys to customers and measure adoption; apply risk-based step-up rather than blanket friction.
- Apply SP 800-63B-4 password rules in both: length minimums, compromised password blocklist, no composition rules, no forced periodic change.
- Harden recovery and support flows so humans and bots trigger verified flows and never edit credentials or contact details directly.
- Use PKCE and rotated or sender-constrained refresh tokens for customer public clients, per RFC 9700.
- Record consent with purpose, time and version, and support deletion and export from the CIAM platform.
- Stream sign-in, recovery and admin events from both platforms to one SIEM and track the metrics above.
Standards and references
- NIST: SP 800-63-4 Digital Identity Guidelines
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- CISA: Implementing Phishing-Resistant MFA
- FIDO Alliance: Passkeys
- OWASP: Credential Stuffing Prevention Cheat Sheet
- OWASP: Authentication Cheat Sheet
Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · CIAM Buyer's Guide · Passwordless and Passkeys Guide · Identity reference architecture for workforce, customer and non-human identities