B2B SaaS Identity From Scratch: A 60-Day Playbook

A new B2B SaaS that wants to land $30-50k enterprise contracts within 12 months needs identity right from day one. The cost of fixing identity later, when the first enterprise customer asks for SSO and the application's user model can't accommodate Organizations, runs into multiple engineering quarters. This playbook covers the 60-day path to launching a B2B SaaS with identity primitives that scale through the first enterprise customer.

Phase 1, CIAM selection and Org model design (7 days)

Don't write your own auth. Don't build your own Organization model. Pick a B2B-focused CIAM that ships these as primitives.

CIAM evaluation. The 2026 short list for B2B-from-scratch:

• Frontegg, Tenant model is first-class, embedded admin portal, fast time-to-SSO.
• WorkOS, Strong at SSO/SCIM/Directory Sync, more developer-platform than full CIAM.
• Auth0 Organizations, Mature but separately licensed; expensive at scale.
• SSOJet, Organization-centric model with focused B2B feature set.

Evaluate against three criteria: per-Org SSO + SCIM, embedded admin portal for customer self-service, audit logs accessible per-Org. Rule out CIAM that don't ship these as first-class primitives, see the Organizations guide.

Org model design. On paper, sketch:

• Organization (the customer): id, slug, name, domains[], plan
• Membership: user_id × org_id × role × status
• Multi-Org users: a single user can belong to multiple Organizations
• Active Org: which Organization is the user "in" right now

This is your application's foundational data model. Your CIAM provides the auth primitives; your application persists the Org-scoped business data.

Phase 2, Authentication primitives and self-service signup (14 days)

Stand up the public sign-up and sign-in flow.

Sign-up flow. Email + passwordless (magic link) or email + passkey as the default. Don't make password the only option for new users in 2026; the migration cost when you later add passkeys is significant.

Email verification. Verify email at sign-up before granting access. Standard CIAM feature; ensure it's enabled.

Passwordless or password choice. Modern CIAM let users pick their factor, passkey, magic link, password + TOTP. Default to the strongest available; let users choose only as needed.

Sign-in flow. Email-first sign-in (the user enters email; the CIAM resolves which auth method applies, passkey, magic link, password). Conditional UI shows passkey credentials in the autofill if available.

Email-domain Org routing prep. Even at signup, capture the email domain. Customer admins can later "claim" a domain to enable per-Org SSO routing, see Phase 4.

Phase 3, Organization, members, and roles (14 days)

The Org primitive becomes the load-bearing structure of the application.

Organization creation. When a user signs up without an Org context, create an Organization for them as part of onboarding. Customer admin role assigned by default.

Member invites. Customer admin can invite team members by email. Invited users sign in via magic link (or set up their auth on first arrival). The invite carries the role.

Roles. Start with admin and member. Add finer roles (viewer, billing, owner) as customers ask. Don't over-design the role model on day one, RBAC with 2-3 roles meets the first-customer needs; expand to ABAC/ReBAC later if collaboration semantics warrant. See RBAC vs ABAC vs ReBAC.

Multi-Org user model. A user can belong to multiple Organizations. The active Org is part of the session; switching Orgs is a UI action that re-issues the session with the new Org context.

Active Org enforcement. Every API request resolves the active Org from the session and scopes data access. RLS, query filters, or middleware, pick the tenancy enforcement pattern early. See multi-tenant architecture.

Phase 4, Enterprise SSO readiness (14 days)

The first enterprise contract typically requires SSO. The CIAM should make this self-service for the customer.

Per-Org SSO connection. The CIAM exposes a per-Org SSO config, SAML metadata exchange, OIDC discovery URL, IdP-specific templates. The customer's IT admin uploads their config via the embedded admin portal.

Email-domain SSO routing. When a user signs in with user@customer.com, the CIAM resolves the Org from the email domain and routes to that Org's IdP. The customer's IT admin claims their email domain in the Admin Portal.

Test connection. Before enabling SSO in production, the customer admin signs in via SSO as a test. Verifies the assertion arrives, attributes map correctly.

Attribute mapping. Per-Org mapping config so the customer's IdP claim names map to your application schema. Group/role mapping converts IdP groups to your application's roles.

JIT provisioning. First SSO sign-in auto-creates the user record in the Org. SCIM (Phase 4-extended) covers the lifecycle for larger customers.

For the deeper SSO onboarding, see the B2B Enterprise SSO onboarding playbook and the Enterprise SSO guide.

SCIM endpoint. The CIAM exposes a per-Org SCIM endpoint for Customer's IdP to push user lifecycle events. Customer admins above ~1000 seats will require SCIM as a contract dependency.

Phase 5, Audit log, admin portal, and launch (11 days)

The customer's security team will ask about audit logs and admin operations. Have answers ready.

Audit log. Every auth event, admin operation, and config change logged with user, IP, timestamp, action, outcome. Per-Org filter so customer admins see their data only.

Customer admin portal. Embedded in your dashboard or hosted separately, the portal lets customer admins:

• Manage members (invite, remove, change role)
• Configure SSO connection
• Configure SCIM provisioning
• Query their Org's audit log
• Manage their Org's branding

Most B2B-focused CIAM (Frontegg, Auth0 Organizations, SSOJet) ship this as embeddable; integration is hours, not weeks.

Launch. Soft launch to early customers; iterate on the admin portal UX based on feedback. Most rough edges surface in the first 5-10 customers; address them before broadening.

Documentation. Customer-facing help articles for SSO setup, member invites, role management, SCIM configuration, audit log queries. The customer's IT admin debugs at 2 AM; runbooks reduce support load dramatically.

Anti-patterns to avoid

• Single-tenant CIAM. Auth0 Free, Cognito User Pool, fine for B2C, painful for B2B. The Organization model is an architectural choice, not a feature you bolt on later.
• Org as a column on the user table. Works at 1-5 customers, collapses at 20+. Make Org the load-bearing primitive from day one.
• Single shared SSO connection. Forces you to manage every customer's IdP centrally. Per-Org connection is the only sustainable pattern.
• No customer admin portal. Every customer config change becomes an engineering ticket. Embed the CIAM's admin portal or build the equivalent.
• Skipping audit log access for customers. Enterprise security teams ask about this in the first week of evaluation. Have it ready.
• Password as the only auth method. Migration cost to passkeys later runs into months. Default to passkey or magic link from launch.

What success looks like at day 60

• Self-service signup with passkey or magic link as default.
• Multi-Org user model with role-based access and active Org switching.
• Per-Org SSO configurable via embedded admin portal, the customer's IT admin can set it up without your engineering team.
• SCIM endpoint ready for the first 1000+ seat customer.
• Audit log accessible per-Org for customer security teams.
• First enterprise contract candidate can be onboarded via the playbook in B2B Enterprise SSO onboarding without architectural changes.

For broader context, see the B2B SaaS identity guide, the Organizations guide, and the build vs buy CIAM guide.