Multi-brand rollout: the scenario that breaks architectures.

This is the scenario that breaks the most CIAM architectures, because vendors' default tenancy models rarely match brand reality. The core design decision is shared versus separate identity across brands.

One shared identity means a customer registers once and is recognized everywhere, which is great for cross-sell and a single customer view, but it forces hard questions. Does logging into Brand A silently create a session for Brand B? Is that delightful or creepy? Consent notices are usually brand-scoped, so a shared profile needs per-brand consent partitions, and GDPR purpose-limitation makes sharing data across a portfolio something legal must explicitly design for, not inherit from architecture. Separate identity per brand stays clean legally and lets each brand move independently, but recreates fragmentation and doubles operational load: two password policies, two MFA configs, two breach-response surfaces per brand pair.

Most large multi-brand companies land on a hub model: one identity backbone, brand-scoped experiences on top. Execution quality then depends on unglamorous capabilities: custom domains per brand (for trust and for cookie and session scoping), per-brand theming of every flow including password-reset and MFA-enrollment emails, per-brand authentication policy, and session topology control over which brands share SSO. Rollout is its own discipline: one low-risk brand first, old and new in parallel with lazy migration, instrument drop-off, then template it. That means coexisting with legacy auth for 12 to 18 months, so platforms that assume greenfield make this miserable.