Should a startup build or buy CIAM?

Buy for almost every greenfield product. Authentication looks simple but carries a long tail of security, compliance, and edge-case work: password hashing, breach monitoring, MFA, account recovery, session management, bot defense, and audit logging. A managed customer identity platform covers that on day one, and free tiers usually cover early-stage volume. Self-host open source only if you have the team to patch it, and build only if identity is your actual product.

What does a minimum viable CIAM include?

A first version covers signup, sign-in, password reset, email verification, at least one social login, a basic profile, session management, MFA enrollment, and an account deletion flow for privacy compliance. Federation with enterprise identity providers, SCIM provisioning, and custom authorization can wait until a customer requires them.

How long does it take to build customer login?

As a rough planning estimate, with a managed CIAM platform a small team can ship a production-ready first version in about eight weeks: two weeks to pick a vendor and wire signup and sign-in, two weeks for verification, reset, and social login, two weeks for profile and MFA, and two weeks for audit logging, deletion, rate limiting, and hardening.

Where should you store session tokens in a web app?

Use an HttpOnly, Secure cookie with SameSite set to Lax or Strict rather than browser localStorage. OWASP's session management guidance says not to store session IDs, tokens, or JWTs in localStorage or sessionStorage, because any script on the origin can read them and one cross-site scripting flaw exposes every session. A backend-for-frontend pattern is the alternative for single-page apps.

Should a new product launch with passkeys?

Offer them from launch if your platform supports them, alongside a fallback. WebAuthn Level 3 became a W3C Recommendation on 25 August 2026, and NIST SP 800-63B-4 requires at least one phishing-resistant option at AAL2. Most consumer products still keep email or password sign-in as a fallback in the first version, then promote passkeys at sign-in and after recovery.

Do I have to offer Sign in with Apple on iOS?

Not by name. Apple's App Store Review Guideline 4.8 says that an app using a third-party or social login for the primary account must also offer an equivalent login service that limits data collection to name and email, lets users keep their email private, and does not track for advertising without consent. Sign in with Apple meets that; apps using only their own account system are exempt.

Greenfield CIAM: how to ship the first version in 8 weeks

Greenfield CIAM means building customer identity and access management for a new product with no existing users to migrate. The verdict for almost every team: buy a managed CIAM platform, ship a scoped first version in about eight weeks (a planning estimate), and defer enterprise features until a customer asks. This guide is the week-by-week plan, the 2026 baselines it must meet, and the line on what to defer.

Build, buy, or open source: decide first

Customer identity looks like a login form, but the work that matters is invisible: password hashing that survives a database leak, credential stuffing defense, MFA, account recovery that is not itself phishable, session management, audit logging, and privacy-compliant deletion.

Option	Right when	Wrong when	Examples
Managed CIAM	You want to ship in weeks and identity is not your product	Data residency or per-MAU pricing rules it out at your scale	Auth0, Clerk, Stytch, Descope, Amazon Cognito, Microsoft Entra External ID
Self-hosted or open source	You need full control or self-hosting and have someone to patch and operate it	Nobody owns upgrades and on-call	Keycloak, FusionAuth, Better Auth
Build	Identity is the product you sell	Anything else	Your own team, forever

Check ownership before you sign: Auth0 is part of Okta, Stytch was acquired by Twilio (closed 2025-11-14), and Better Auth was acquired by Vercel (2026-07-07) while the library stays free and MIT licensed. For picking a platform, use the how to evaluate CIAM buyer guide, the best CIAM for startups ranking, CIAM pricing models explained, and the identity pricing transparency index. For a wider capability view, Deepak Gupta's CIAM Compass maps 40-plus platforms against a capability matrix.

What "first version" means

Signup, sign-in, password reset, email verification, social login, basic profile, session management, MFA enrollment, and account deletion. Anything beyond that is phase 2. Scope discipline is what makes the eight weeks realistic.

The 2026 baselines your first version must meet

Passwords (NIST SP 800-63B-4, final July 2025). At least 15 characters when a password is the only factor, at least 8 when used within MFA. Check new passwords against a blocklist of common and compromised passwords. No composition rules and no forced periodic changes, but force a change on evidence of compromise. Limit consecutive failed attempts to no more than 100.
Hashing (OWASP Password Storage Cheat Sheet). Argon2id with at least 19 MiB memory, 2 iterations, parallelism 1. scrypt if Argon2id is unavailable. bcrypt for legacy only, with a work factor of at least 10 and a 72-byte input limit. PBKDF2-HMAC-SHA256 at 600,000 iterations if you need FIPS-140. A managed platform should document which it uses.
Phishing resistance. NIST requires at least one phishing-resistant option at AAL2. Passkeys on WebAuthn (Level 3 a W3C Recommendation since 25 August 2026) are the practical way to offer it to consumers.
Sessions (OWASP Session Management Cheat Sheet). HttpOnly and Secure cookies with SameSite Strict or Lax; never tokens in localStorage or sessionStorage.

Week-by-week

Weeks 1-2: foundation. Pick the vendor. Spin up a free tier. Wire signup and sign-in with the SDK, using OpenID Connect with authorization code and PKCE rather than a custom token flow. Decide the session strategy early, because it is hard to change later. Configure separate tenants for staging and production so redirect URLs and keys never cross.

Weeks 3-4: trust and reach. Email verification, so fake accounts do not pollute your data. Password reset with expiring single-use links. Social login, typically Google and Apple. On iOS, App Store Guideline 4.8 requires that an app using a third-party login for the primary account also offers an equivalent privacy-preserving login (name and email only, private email option, no ad tracking without consent); Sign in with Apple is the usual way to meet it. Send transactional email from a domain you control with SPF, DKIM, and DMARC set.

Weeks 5-6: profile and step-up. Profile screens and password change. MFA enrollment with TOTP and passkeys where your platform supports them. Make MFA available to all users and required for any account that touches money or sensitive data, and add step-up authentication for changes to email, phone, or payout details.

Weeks 7-8: production hardening. Structured audit logging for every identity event. Account deletion and data export flows for GDPR and CCPA (see GDPR for identity systems). Rate limiting, bot detection, and breached-password checks on login, reset, and verification endpoints. A load test against expected launch traffic. A runbook for the two incidents you will eventually have: account takeover reports and a locked-out founder.

How greenfield CIAM fails in production

Reused passwords, no MFA. At 23andMe, about 14,000 accounts accessed with reused passwords exposed data on about 6.9 million other users through an opt-in sharing feature. Roku saw about 576,000 accounts hit in a second wave and then turned on two-factor authentication for all accounts. Chick-fil-A was hit again in June 2026. Lesson: breached-password checks, bot defense, and MFA offered at launch, not after the incident. See account takeover prevention.
Weak recovery. The Coinbase SMS recovery flaw let attackers with stolen passwords obtain the SMS codes needed to take over accounts. Recovery must not be easier than sign-in; watch for OTP relay social engineering.
Unauthenticated endpoints. Authy phone numbers were enumerated through an unauthenticated endpoint, and an Optus API returned customer data without valid authorization. Every identity API needs authorization and rate limits, including lookup and "does this account exist" endpoints.
Stolen sessions. Infostealers lift cookies, so bind sessions to devices where supported and re-authenticate on sensitive actions; see session cookie theft.

What to defer

Federation with enterprise identity providers (only when the first enterprise prospect asks), using OIDC or SAML
SCIM provisioning (only when a first enterprise deal requires directory sync); see B2B vs B2C CIAM
Custom flows and journey orchestration (default flows handle most cases)
Migration tooling (you have no users yet; when you do, see CIAM migration)
Fine-grained authorization (role-based access is enough until it is not)

Common pitfalls

Building auth in-house "because it is just a login form," then owning its security forever
Storing passwords with anything other than Argon2id, scrypt, bcrypt, or PBKDF2 at current parameters
Putting session tokens in localStorage where a single cross-site scripting bug drains every session
Skipping email verification "for conversion" and accepting a wave of fake accounts
Hardcoding redirect URLs so staging cannot work, then loosening them so open redirects can
Treating account recovery as an afterthought, when it is the most-attacked path in the whole system

Ship the eight-week version, watch real usage, and let phase 2 be driven by what your users and first enterprise buyers need.