Customer identity and access management (CIAM) sits at the intersection of security, user experience, privacy and revenue. It controls how customers and partners register, sign in, recover accounts, consent to data use and connect their accounts to other services. Every extra step costs conversions; every weak step invites account takeover and fraud. CIAM also increasingly involves non-human actors: partner integrations, API clients and AI agents acting on behalf of customers. This guide covers how CIAM differs from workforce IAM, the main threats, and the controls that protect customers without driving them away.
Key takeaways
- CIAM must scale to millions of self-registered users with no IT department behind them, so security has to be largely invisible and risk-based.
- The biggest threats are credential stuffing, account takeover, fake account creation, recovery abuse and fraud, increasingly automated with AI.
- Passkeys, risk-based authentication and strong recovery flows give the best balance of security and usability.
- Treat APIs, partner integrations and customer-authorised AI agents as first-class identities with scoped, revocable delegated access.
- Privacy and consent requirements shape CIAM design as much as security does.
How CIAM differs from workforce IAM
| Workforce IAM | CIAM | |
|---|---|---|
| Users | Employees and contractors, known and managed | Customers and partners, self-registered, anonymous until proven otherwise |
| Scale | Thousands to hundreds of thousands | Millions, with traffic spikes |
| Devices | Often managed | Unmanaged |
| Priority | Security and productivity | Conversion, experience, security and privacy |
| Governance | Access reviews, joiner-mover-leaver | Consent, preference management, data subject rights |
| Support | Internal help desk | Customer service, often outsourced |
Threats to customer identity
- Credential stuffing: reused passwords from other breaches tried at scale against your login.
- Account takeover leading to fraud, loyalty point theft, data theft or resale.
- Fake and synthetic accounts for promotion abuse, spam or money laundering.
- Recovery abuse: SIM swap, email compromise and social engineering of support channels. The Meta AI support chatbot account takeover showed how an AI support agent can become the weak link in recovery.
- API abuse: unauthenticated or weakly authenticated APIs used to enumerate accounts or scrape data, as in the T-Mobile API breach.
- Session hijacking through stolen tokens on compromised devices.
Registration and sign-in
- Offer passkeys at registration and prompt existing users to add them. See the Passwordless and Passkeys Guide.
- Where passwords remain, check them against known breached password lists and do not impose arbitrary complexity rules, in line with NIST SP 800-63B-4.
- Use bot detection and rate limiting on registration, login and recovery endpoints.
- Apply risk-based step-up: challenge only when device, network, behaviour or transaction risk is elevated.
- Verify email and phone before trusting them for recovery.
Account recovery
- Recovery is often the weakest point. Avoid relying on SMS alone or on knowledge-based questions.
- Prefer recovery through a second registered passkey, verified email with additional risk checks, or identity verification for high-value accounts.
- Notify users of recovery attempts and credential changes on all registered channels.
- Apply a cooling-off period or extra verification before sensitive actions after recovery.
- Constrain what support staff and support chatbots can do: they should trigger verified flows, not change credentials directly.
Sessions and tokens
- Use short-lived access tokens with refresh token rotation for apps.
- Bind tokens to devices where possible and detect token replay.
- Allow customers to see and end active sessions and connected devices.
APIs, partners and delegated access
- Use OAuth 2.0 with PKCE for customer-facing apps; avoid long-lived API keys in mobile or browser code.
- Give partners their own clients with scoped access and strong client authentication, and let customers see and revoke what they have authorised.
- Prepare for customers authorising AI agents to act for them: support narrow, time-bound, revocable delegation and step-up approval for purchases and changes. See the Agentic Commerce Identity Guide.
- Enforce object-level authorisation on every API. See the OWASP API Security Top 10.
Privacy and consent
- Collect the minimum data needed, progressively rather than all at registration.
- Record consent with purpose, time and version, and let customers change it.
- Support data subject rights such as access, correction and deletion.
- Consider data residency requirements for identity data.
Practitioner checklist
- Offer passkeys and prompt adoption; check passwords against breach corpuses.
- Deploy bot protection and rate limits on login, registration and recovery.
- Use risk-based step-up rather than blanket friction.
- Harden recovery flows and constrain support staff and chatbots.
- Use OAuth with PKCE and short-lived tokens; let customers manage sessions and connected apps.
- Scope and govern partner and AI agent access to customer accounts.
- Build consent and privacy controls into identity flows.
Standards and references
- NIST SP 800-63-4 Digital Identity Guidelines
- OWASP API Security Top 10
- OWASP Credential Stuffing Prevention Cheat Sheet
- RFC 7636: PKCE
- FIDO Alliance: Passkeys
Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · IAM and IdP Buyer's Guide · Human vs Non-Human Identity · Agentic Commerce Identity Guide
