A customer identity (CIAM) platform goes live in front of every customer and every attacker at once, so security decisions left until after launch are decisions made under credential stuffing and account takeover pressure. This playbook covers rolling out a CIAM platform as a product class: the design decisions before build, how to configure the tenant and administrators securely, how to integrate applications, how to move existing customers in, how to launch with testing and rollback, and what to monitor afterwards. It is vendor-neutral and based on NIST SP 800-63B-4, OWASP cheat sheets, NIST SP 800-53 and CIS Controls v8.1. It is written for CIAM architects, product security teams and digital product owners. The security principles of customer identity are covered in the Customer IAM (CIAM) Guide; product selection is in the CIAM Buyer's Guide.
Key takeaways
- Decide assurance levels before screens. Map each customer journey to an authentication assurance level so MFA, passkeys and step-up are designed in, not bolted on after launch.
- Launch with abuse defences switched on. Breached-password checks, rate limiting and bot defences must be live on day one; attackers test new login pages quickly.
- The admin tenant is a high-value target. Whoever administers the CIAM tenant can change sign-in policies for every customer, so protect it like workforce tier 0.
- Customer migration is the riskiest phase. Choose bulk or just-in-time migration deliberately, protect password hashes in transit and keep a rollback route to the legacy store.
- Recovery is part of authentication. A strong login with a weak password reset or help desk path is still a weak login.
Phase 0: requirements and assurance design
NIST SP 800-63B-4 defines authentication assurance levels. At AAL2 verifiers must offer at least one phishing-resistant option; AAL3 requires a phishing-resistant authenticator with a non-exportable key, which excludes syncable authenticators. Most consumer journeys sit at AAL1 or AAL2, with step-up for sensitive actions.
| Journey | Typical assurance (our recommendation) | Design implication |
|---|---|---|
| Browsing, saved preferences | AAL1 | Password or passkey; offer MFA |
| Viewing personal data, order history | AAL2 or AAL1 with risk signals | MFA or passkey by default for new accounts |
| Changing email, phone, password or payout details | Step-up to AAL2 | Re-authenticate and notify the old contact channel |
| High-value payments, health or financial data | AAL2, phishing-resistant where possible | Passkeys preferred; step-up on each sensitive action |
| Business customer administrators (B2B) | AAL2 phishing-resistant | Federation to the customer's own identity provider where offered |
Also decide in this phase: password rules (SP 800-63B-4: minimum 15 characters for single-factor passwords and 8 when used within MFA, at least 64 permitted, no composition rules, blocklist of compromised values, no forced periodic change), consent and privacy requirements, data residency, and B2B needs. See the B2B CIAM and Organisation Management Guide and the Consent Management Guide: Cookies, CMPs and GPC.
Phase 1: tenant design and administration
- Separate tenants or instances per environment: development, test and production with no shared administrators or signing keys. Production customer data stays in production.
- Restrict tenant administrators: a small group with dedicated admin accounts and phishing-resistant MFA (CIS safeguards 5.4 and 6.5), administering through the workforce identity provider where the platform supports it. Split roles: configuration, application registration, support (read customer profiles, trigger resets) and audit.
- Protect support roles: customer support staff who can reset MFA or change email addresses hold a takeover capability. Limit those actions, require a second person for high-value accounts, and log every one. See the Account Recovery and Help Desk Security Guide.
- Manage the management API: management API clients used by back-end systems get the narrowest scopes, their own credentials and an owner; they can usually read or change any customer profile.
- Signing keys and custom domains: know how token signing keys are rotated, use a custom domain you control for the login pages, and protect the DNS records behind it.
- Configuration as code: export or manage tenant configuration through the platform's API or infrastructure-as-code tooling, with peer review and drift detection (NIST SP 800-53 CM-3 and CM-6).
Securing the platform's administration is shared responsibility: the provider secures the service, and the customer owns admin accounts, policies, application registrations and API clients.
Phase 2: application integration
- Standards-based flows: integrate applications with OpenID Connect authorisation code flow with PKCE. Browser applications should use a back-end-for-frontend so tokens are not held in JavaScript. See the OAuth for Browser-Based Applications and the BFF Pattern Guide and the OAuth 2.0 Security Best Current Practice (RFC 9700) Guide.
- Register redirect URIs exactly: no wildcards, one client per application and environment.
- Token lifetimes and sessions: short access tokens, rotated refresh tokens, and re-authentication periods set per journey. SP 800-63B-4 recommends reauthentication at AAL2 within 24 hours overall and after 1 hour of inactivity. See the Token Lifetime Policy Design Guide.
- Native and mobile apps: use the system browser and platform authenticators; see the OAuth for Native and Mobile Apps Guide.
Phase 3: abuse defences before launch
Credential stuffing and fake account creation start as soon as a login page is public. The 23andMe Breach 2023 involved credential stuffing against more than 18,000 accounts where MFA was optional. Defences to have live at launch:
| Defence | Source | Rollout note |
|---|---|---|
| Compromised password blocklist at registration and change | SP 800-63B-4; OWASP credential stuffing cheat sheet (identifying leaked passwords) | Tell users why a password was rejected |
| Failed-attempt limits | SP 800-63B-4: no more than 100 consecutive failed attempts per authenticator | Combine with delays and risk signals rather than hard lockouts that attackers can abuse |
| MFA and passkeys | OWASP credential stuffing cheat sheet lists MFA first | Offer passkeys at registration; see the Passkey Rollout Guide |
| Bot detection and challenges | OWASP: CAPTCHA, device and connection fingerprinting, IP intelligence | Apply on risk, not on every login; see the Bot Management Guide |
| Security notifications | OWASP: notify users about unusual security events | New device, password change, MFA change, email change |
| Safe password reset | OWASP forgot password cheat sheet | Identical responses for existing and unknown accounts, single-use expiring tokens, rate limits, notification after reset |
ATT&CK lists this behaviour as T1110.004 Credential Stuffing; session theft after login is T1539 Steal Web Session Cookie.
Phase 4: migrating existing customers
| Approach | How it works | Choose when | Security points |
|---|---|---|---|
| Bulk import with hashes | Export password hashes and profiles; import if the platform supports the hash algorithm | Hashes are in a supported, strong algorithm | Encrypt the export, limit who handles it, delete it after import, verify counts |
| Just-in-time migration | On first login the platform validates against the legacy store and creates the account | Weak or unsupported legacy hashes, or a phased cut-over | Protect the legacy validation endpoint; set an end date; inactive users go through recovery |
| Forced reset | Import profiles without passwords; users set a new credential | Legacy hashes are untrusted or exposed | Highest friction; a natural point to enrol passkeys |
Detailed migration between platforms is in the Customer identity (CIAM) platform migration playbook.
Phase 5: launch, testing and rollback
- Security testing: test login, registration, recovery, step-up and logout against OWASP ASVS authentication and session requirements, including account enumeration through registration and reset.
- Load and abuse testing: load test login and registration at expected peak plus a margin, and confirm rate limits and bot controls trigger as designed without blocking real users.
- Phased exposure: release to a percentage of traffic or one market or application first, watching error rates, abandonment and attack signals.
- Rollback: keep the legacy login path deployable behind a feature flag until the new platform has run through a peak period. With just-in-time migration, accounts created on the new platform must sync back or be re-migrated if you roll back; plan which.
- Incident readiness: agree the response for a credential stuffing wave or mass takeover before launch; see the Credential Stuffing Attack Response Playbook.
Decision guidance
- Software as a service or self-hosted: a hosted platform gives managed scale and abuse defences; a self-hosted platform gives control over data and customisation, and makes availability, patching and bot defence your job.
- Passkeys first or passwords plus MFA: passkeys remove credential stuffing and phishing for enrolled users; keep a fallback and design recovery so it is not the weak link.
- Small versus large organisations: smaller organisations should rely on platform defaults for bot and breached-password protection and keep customisation minimal; larger organisations need a CIAM product owner, fraud team integration and per-market policy.
Detection and measurement
Stream CIAM logs to the SIEM and fraud tooling. Watch for: login failure spikes and spikes in successful logins from new devices, logins from many accounts per IP or device, registration bursts, recovery and MFA reset spikes, admin and support actions on accounts, and policy changes in the tenant.
| Metric | Why it matters |
|---|---|
| Share of active customers with MFA or passkeys | Direct measure of takeover resistance |
| Account takeover reports per 10,000 active users | Outcome measure for the whole programme |
| Credential stuffing attempts blocked versus reaching password check | Effectiveness of bot and rate controls |
| Recovery completion rate and recovery-related takeovers | Recovery must be usable and safe |
| Login success rate and abandonment | Friction that drives users and the business to weaken controls |
| Tenant admin and support actions reviewed | Insider and support-path abuse |
Framework mapping
| Rollout element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Customer authentication | IA-8 Identification and Authentication (Non-organizational Users), IA-5(1) Password-based Authentication | PR.AA-03 | 6.3 |
| Failed login handling | AC-7 Unsuccessful Logon Attempts | PR.AA-03 | 6.3 |
| Sessions and re-authentication | AC-12 Session Termination, IA-11 Re-authentication, SC-23 Session Authenticity | PR.AA-03 | No direct safeguard |
| Tenant administration | AC-6(5) Privileged Accounts, IA-2(1) Multi-factor Authentication to Privileged Accounts | PR.AA-05 | 5.4, 6.5 |
| Monitoring | SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting | DE.CM-03 | 8.2 |
Common failure patterns
- MFA optional and unpromoted: few customers enrol, and takeover risk stays with passwords.
- Abuse controls deferred: bot and breached-password checks scheduled for "phase 2" after launch.
- Weak recovery: a strong login paired with a reset flow that reveals whether an account exists or lets support change email without checks.
- Over-powered support and API clients: management access that can change any customer's credentials, held by many people or services.
- Shared tenants across environments: test applications registered in production, or developers with production admin rights.
- No rollback plan: just-in-time migration with no way back once the legacy store is switched off.
Practitioner checklist
- Map every customer journey to an assurance level and step-up rule.
- Apply SP 800-63B-4 password rules with a compromised-password blocklist.
- Separate tenants per environment and restrict tenant and support administrators.
- Integrate applications with authorisation code and PKCE, exact redirect URIs and a BFF for browsers.
- Switch on rate limits, bot defences and security notifications before launch.
- Choose bulk, just-in-time or forced-reset migration and protect exported hashes.
- Load and abuse test, then release in phases with a feature-flag rollback.
- Track MFA and passkey adoption, takeover rate and recovery abuse monthly.
Standards and references
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- OWASP: Credential Stuffing Prevention Cheat Sheet
- OWASP: Forgot Password Cheat Sheet
- OWASP: Application Security Verification Standard 5.0
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CIS: Controls v8.1 Assessment Specification, Control 6 Access Control Management
- CIS: Controls v8.1 Assessment Specification, Control 8 Audit Log Management
- MITRE ATT&CK: Credential Stuffing
Related NHI Mgmt Group resources: Top 10 CIAM Security Risks · CIAM Maturity Model · Account Takeover Prevention Guide · CIAM RFP Template