CIAM Launch Checklist: 30-Day Pre-Production Playbook

The 30 days before flipping a CIAM into production are the difference between a launch that works and one that generates customer-visible incidents. This playbook is the readiness checklist for any CIAM going live, whether it's a brand-new product launching authentication for the first time or a migration from one CIAM to another. It assumes the integration code is already working in dev; the goal here is to validate everything else.

Phase 1, Functional verification (7 days)

Before security or operations, confirm the auth flows themselves work end-to-end against production-like configuration.

Sign-up flow. New user registration via every supported method: email/password, magic link, OAuth (each provider), passkey enrollment. Verify the post-signup state, email verification, account creation, default permissions.

Sign-in flow. Existing user sign-in via every method. Verify token issuance, claim correctness, redirect handling.

MFA enrollment and challenge. Each MFA factor (TOTP, push, passkey, SMS), enrollment from settings, challenge at sign-in, challenge at step-up actions.

Password reset. Email delivery, reset link expiry, reset completion, post-reset session invalidation.

Account recovery. Lost password, lost MFA, lost device. Each path should resolve without engineering escalation.

Federated sign-in. Each OAuth/OIDC/SAML provider, first-time binding, repeat sign-in, account linking when the user has multiple providers.

B2B Organization flows (if applicable). SSO connection setup via embedded admin portal, SCIM provisioning round-trip, per-Org admin operations, audit log query.

Session management. Sign-out, idle timeout, absolute timeout, refresh token rotation, multi-device sessions.

Negative cases. Invalid credentials, expired tokens, rate-limited requests, suspended accounts. Verify the failure messages are user-friendly and don't leak implementation details.

Phase 2, Security review (7 days)

Once functional flows are confirmed, validate the security posture.

Token configuration. Access token lifetime (5-15 min), refresh token lifetime (days to weeks), refresh token rotation enabled, ID token short-lived. See the token lifetime guide for defaults.

Cookie security. Session cookies marked Secure, HttpOnly, SameSite=Lax or Strict, with appropriate domain/path scope.

CSRF defenses. State parameter validated in OAuth flows, double-submit cookie or synchronizer token for non-OAuth POST endpoints.

CORS configuration. Origin allowlist matches the application domains; no wildcard *; credentialed CORS only where needed.

Password policy. Minimum length 12+, breached password check (HaveIBeenPwned), no maximum length cap below 64. See the breached credentials best practice for the broader context.

MFA configuration. Strong factors offered (passkey, TOTP), SMS positioned as fallback only, MFA enrollment encouraged at signup.

Bot defense. Rate limits at network edge and application, CAPTCHA on high-risk flows, breached credential check on password sign-in. See bot defense and rate limiting.

Audit logging. Every authentication event, admin operation, and policy change logged with user, IP, timestamp, action, outcome. Retention configured for compliance (typically 365 days minimum).

TLS configuration. TLS 1.3 enabled, hybrid post-quantum key exchange where the CDN supports it (Cloudflare, Akamai), HSTS header.

Secret rotation plan. API keys, OAuth client secrets, signing keys all have documented rotation cadence and runbook.

Penetration test or security review. External or internal security review of the auth surface. Address findings before launch.

Phase 3, Operational readiness (7 days)

The auth system is a 24/7 critical surface. Confirm the operational posture.

Monitoring dashboards. Sign-in success rate, sign-in failure rate (by reason), MFA challenge rate, MFA failure rate, token validation error rate, latency percentiles. Visible to the team.

Alerting. Pages on: auth service down, sign-in success rate drop >X%, abnormal failure rate, token validation error spike, audit log ingestion failure. Routes to on-call rotation.

Runbook. Documented procedures for: vendor outage response, signing key rotation, OAuth provider outage, suspected breach, mass session invalidation.

Vendor support contacts. Account managers, support tier level, escalation path, SLA. For self-hosted, the equivalent is the team's own escalation paths.

Backup and disaster recovery. For self-hosted, automated database backups, tested restore procedure, multi-region failover. For managed, vendor's DR posture documented.

Capacity planning. Expected MAU at launch, projected growth, vendor pricing tier, headroom for traffic spikes.

Status page integration. CIAM status reflected in product status page; transparent communication during incidents.

Compliance readiness. Data export endpoint working (GDPR/CCPA), data deletion endpoint working, consent management connected to data processing, see the GDPR and CCPA guides.

Phase 4, Soft launch and observation (9 days)

Don't flip the switch all at once. Stage the launch with observation windows.

Internal dogfood. Team uses the production CIAM for internal authentication for at least 3 days. Catches issues that test environments miss.

Limited customer rollout. 5-10% of new sign-ups go through the new CIAM. Monitor metrics. Two-day observation. If clean, ramp.

50% rollout. Half of new sign-ups. Monitor metrics. Two-day observation.

100% rollout. Full launch. Monitor metrics. Final observation.

Post-launch metrics review. Sign-in success rate, sign-up conversion, support ticket volume related to auth. Compare to baseline; anomalies investigated.

Documentation handoff. Customer-facing help articles (sign-in problems, MFA enrollment, password reset, account recovery), internal runbook, on-call training.

Anti-patterns to avoid

• Big-bang launch without observation. No staged rollout means a launch incident hits 100% of users immediately.
• Skipping the security review. "We'll fix it post-launch" is how token theft and credential stuffing land in week one.
• No alerting at launch. Discovering issues via customer support tickets instead of dashboards.
• Underestimating support load. Sign-in problems are the most common support category; staff for the launch wave.
• Compliance afterthought. Data export, consent, and audit log retention need to be working at launch, adding them later is more expensive.

What success looks like at day 30

• Production CIAM is live with all functional flows working.
• Security posture validated by review and test.
• Monitoring and alerting operational with on-call rotation aware.
• Soft launch progression from dogfood to 100% rollout with clean metrics.
• Documentation handoff to support, ops, and customer-facing teams.

For broader context, see the build vs buy guide and the account takeover defense guide.