Multi Brand and White Label CIAM Guide: Tenancy Models, Shared Identities and Brand Isolation

When one customer identity platform serves several consumer brands, a design choice made for convenience, such as one shared user store or one login domain, quietly decides whether a breach, a consent mistake or a session bug stays inside one brand or reaches all of them. Retail groups, media houses, travel and hospitality groups, banks with challenger brands, and white label providers who run sign-in for clients all face the same questions: one identity or one per brand, one sign-in page or many, one consent record or several, and how customers move between brands without being linked by accident. This guide covers consumer multi-brand tenancy models, shared versus separate identity stores, per-brand login experience and consent, account linking across brands, passkeys across brand domains, and how four common platforms express these choices. It is written for CIAM architects, product security engineers and privacy leads. Business customer organisations are a different problem, covered in the B2B CIAM and Organisation Management Guide; the wider customer identity picture is in the Customer IAM (CIAM) Guide.

Key takeaways

• Decide the identity boundary first. Whether a person has one account across brands or one per brand is a legal, product and security decision; branding, domains and flows follow from it.
• Sessions and cookies define the real boundary. A shared user store with a shared sign-in domain can sign a customer into a second brand without their knowledge; check how your platform scopes sessions before promising isolation.
• Keep identifiers brand-scoped unless sharing is intended. OpenID Connect pairwise subject identifiers and sector identifiers stop brand applications correlating a customer they should not.
• Consent and privacy notices follow the controller, not the login page. If brands are separate legal entities, a shared identity may make them joint controllers with duties under GDPR Article 26.
• Cross-brand linking needs the same rigour as social linking. Require an authenticated session on both sides, never link on a matching email, and log, notify and allow reversal of every link.

Multi-brand and white label: what changes

Three patterns get grouped under "multi-brand CIAM". They look similar on the sign-in page and differ underneath.

The white label case is closest to multi-tenant SaaS: each client is a tenant and isolation is the product. The tenant isolation patterns are in the Multi-Tenant SaaS Authorisation and Tenant Isolation Guide. What makes consumer multi-brand different from B2B is that the customer is an individual with no organisation administrator, privacy law applies directly to them, and the brand experience is the commercial asset being protected. See the B2B vs B2C CIAM comparison.

Tenancy models: shared versus separate identity stores

Most designs are one of four models. The choice sets your blast radius, your consent model and how hard it will be to sell or spin off a brand later.

• Divestment test: ask how you would hand one brand's customers, credentials and consent history to a buyer. If the answer is "export and filter one huge directory", model 3 or 4 is safer.
• Password hashes and passkeys do not move freely: migrating customers between stores later means password hash import and passkey re-enrolment. See the CIAM User Migration Guide.
• Quotas and rate limits are shared: where brands share one platform account, one brand's traffic spike or credential stuffing attack consumes limits for all of them.

Identifiers and tokens across brands

The subject identifier in tokens decides whether brand applications can correlate a customer. OpenID Connect Core Section 8 defines two subject types. A public identifier gives every client the same sub. A pairwise identifier gives each client a different sub so that clients cannot correlate the user's activity without permission. Section 8.1 adds the sector identifier: a sector_identifier_uri lets a group of sites under common administrative control receive consistent pairwise values, and a client whose redirect URIs span several hostnames must register one.

• Key on issuer plus subject: ASVS 5.0 V10.5.2 asks clients to identify users from claims that cannot be reassigned, usually sub, within the scope of the identity provider. Never key a brand account on email across brands.
• Brand in the token, checked by the API: include a brand or tenant claim and audience per brand, and make every API reject tokens issued for another brand. This is NIST SP 800-53 AC-3 access enforcement applied to brand boundaries.
• Separate signing keys for separate owners: white label clients and separate legal entities should not share token signing keys, so that one key compromise or rotation does not affect every brand.

Per-brand sign-in experience and sessions

Customers judge trust by the domain and page they sign in on. Each brand should sign in on its own domain, with its own look, emails and sender addresses, or customers learn to accept any page that looks roughly right, which helps phishing. Lookalike domains are covered in the Disinformation and Brand Impersonation Guide.

• Custom domain per brand: use login.brand-a.example and login.brand-b.example, not one group domain, unless the group identity is intentionally visible.
• Brand context from a trusted source: choose the brand from the registered client or custom domain, not from a query parameter the browser supplies, so that a crafted link cannot show Brand B's page for Brand A's client.
• Emails per brand: verification, password reset and security notification emails must carry the right brand, sender domain and links. A reset link that lands on the wrong brand's domain trains customers to ignore domains.
• Session scope: a single sign-on session cookie on a shared domain signs customers into every application that trusts it. That is the goal in model 1 and a defect in models 2 and 3. Test it explicitly: sign in to Brand A, open Brand B, and confirm what happens.
• Logout and session termination: decide whether signing out of one brand ends the others, and make security events (password change, account recovery) revoke sessions everywhere the identity is shared. NIST SP 800-53 SC-23 covers session authenticity.

Consent and privacy across brands

Consent belongs to a purpose and a controller. In a shared identity, the record must say which brand collected which consent, for what purpose, under which notice version. A single "marketing consent" flag across brands is rarely lawful when the brands are different controllers, and confuses customers even when they are not.

• Model consent per brand and purpose: store brand, purpose, notice version, timestamp and capture method. See the Consent Records Guide.
• Joint controllers: where separate group companies jointly decide how a shared identity is used, GDPR Article 26 requires an arrangement setting out their responsibilities, its essence made available to customers, and lets customers exercise their rights against each controller. See the Controller vs Processor Guide.
• White label providers are usually processors: the client is the controller for its customers, which shapes the contract, sub-processor list and support access. See the GDPR Article 28 Processor Guide.
• Rights requests across brands: an erasure request to one brand may or may not mean erasure from the shared profile; decide the rule, publish it, and implement it consistently. NIST SP 800-53 PT-4 covers consent as a privacy control.
• Collect only what each brand needs: progressive profiling per brand avoids a group-wide profile that no single brand can justify. See the Progressive Profiling vs Upfront Registration comparison.

Account linking across brands

Cross-brand linking is account linking with a commercial motive, and it fails in the same ways as social login linking. The core rules are in the Social Login and Account Linking Security Guide; these apply them to brands.

1. Offer, do not assume: show the customer that a link is available and what will be shared; never merge silently because the email matches.
2. Prove control of both accounts: require an authenticated session on the existing brand account and a fresh authentication on the account being linked. NIST SP 800-63C-4 requires an authenticated session for all linking functions in federation.
3. Record the link as data: store both brand identities (issuer and subject), link date, method and the consent shown.
4. Notify both sides: send a notification through each brand's channel when a link is created or removed.
5. Make unlinking real: unlinking stops sharing going forward, removes cross-brand session trust and is honoured by every brand application.
6. Check broker defaults: where a platform can link brokered users automatically to existing accounts, confirm it is restricted to trusted, authoritative identity sources before using it across brands.

Passkeys across brand domains

A WebAuthn passkey is bound to a relying party ID, normally a domain. A customer who creates a passkey on brand-a.example cannot use it on brand-b.example. Three options exist:

passkeys.dev recommends considering OpenID Connect federation before Related Origin Requests. See the Passwordless and Passkeys Guide.

How common platforms express multi-brand designs

Platforms are listed alphabetically; the order is not a ranking. Each entry describes the vendor's documented features as of November 2026. Settings are the customer's to configure under shared responsibility. For platform hardening beyond multi-brand design, see the Amazon Cognito Security Guide, the Auth0 Hardening Guide, the Keycloak Hardening Guide and the Azure AD B2C to Entra External ID guide.

Amazon Cognito

• Tenancy: AWS documents tenant separation by user pool per tenant, app client per tenant, user groups, custom attributes or custom scopes, and splitting tenants across AWS accounts or Regions for stronger isolation.
• Branding: managed login styles, built in the console branding editor, can be applied to a user pool or to a specific app client.
• Sessions: the managed login session cookie lasts one hour and signs local users in to all app clients in the same user pool. For brand isolation, AWS describes per-tenant user pools or user pools API sign-in.
• Availability: Cognito quotas apply per AWS account and Region and are shared by all tenants in the application.

Auth0

• Tenancy: one tenant per brand gives full separation; Organizations are designed mainly for business customers and share the tenant's login domains.
• Branding and domains: Multiple Custom Domains attaches several verified custom domains to one tenant for brands, products or regions. Post-login Actions receive event.custom_domain, and email templates can use the custom_domain.domain variable.
• Emails and passkeys: emails use the default domain unless the request names another domain and "Use Custom Domains in Emails" is turned on; each domain has its own passkey enrolment tied to its own relying party ID.
• Availability: Multiple Custom Domains requires an Enterprise plan, with a base entitlement of 20 custom domains per tenant.

Keycloak

• Tenancy: a realm manages a set of users, credentials, roles and groups, and realms are isolated from one another, authenticating only the users they control. A realm per brand is the natural separate-store model.
• Branding: themes are set per realm for the login, account, admin console and email pages.
• Administration: the documentation advises using the master realm only to create and manage other realms, with no end users in it.
• Linking: the first login flow for brokered identities includes the Detect Existing Broker User authenticator, and a configuration in which existing users are linked automatically without a prompt; restrict automatic linking to trusted identity providers.

Microsoft Entra External ID

• Tenancy: an external tenant holds customer identities; a tenant per brand gives separate stores.
• Branding: company branding in the external tenant sets background, favicon, banner logo, layout, header, footer and custom CSS, with language customisation, for browser-delegated sign-in. It is managed through Microsoft Graph organizationalBranding.
• Domains: custom URL domains serve sign-in from your own domain through a reverse proxy such as Azure Front Door. Because sessions are stored per domain, Microsoft advises moving all apps to the custom domain together, and recommends asking support to block the default domain once the custom domain works.
• Availability: Azure Front Door is a separate, billable service.

How to implement

1. Decide ownership and boundary: with legal and privacy, document which entity controls each brand's customers and whether a shared identity is intended (model 1 to 4).
2. Design the identifier and claims: choose public or pairwise subjects and sector identifiers, define brand and audience claims, and decide signing key separation.
3. Build one pilot brand: configure domain, branding, emails, consent capture and session scope for one brand in a non-production tenant.
4. Run isolation tests: cross-brand session test, token replay against another brand's API, password reset email branding, consent record contents, and a support agent's access scope. Use test accounts only.
5. Add the second brand and repeat the tests: most isolation defects appear only when two brands exist side by side.
6. Enable cross-brand linking last: behind a feature flag, with notifications and unlinking in place first.
7. Roll back safely: keep the previous domains and clients live until the new brand configuration has run cleanly for a release cycle, and keep linking reversible.

Detection and measurement

• Log brand on every event: sign-in, sign-up, link, unlink, consent change and recovery events should carry brand, client and domain.
• Alert on cross-brand anomalies: tokens presented to the wrong brand's API, a sudden rise in links, and credential stuffing that moves from one brand's login to another.

Framework mapping

Common failure patterns

• Silent single sign-on between brands: a shared sign-in domain or user pool session signs customers into a brand they never joined.
• Linking on email: an attacker registers on a second brand with the victim's address and gets merged into the victim's group account.
• One password, every brand: credential stuffing against one brand's login unlocks the shared account everywhere, and one account can reach far more data than its owner expects. The 23andMe credential stuffing breach shows how a few thousand reused passwords exposed data on millions of other people through a shared feature.
• Wrong-brand emails: a reset email for Brand B arrives with Brand A's sender and links, and customers learn to ignore domains.
• Brand chosen from a URL parameter: a crafted link shows one brand's page for another brand's client, which phishing pages copy.
• One consent flag for the group: marketing consent given to one brand is used by another controller.

Practitioner checklist

• Document the controller and identity boundary for every brand.
• Choose public or pairwise subjects and sector identifiers deliberately.
• Put a brand claim and audience in tokens and reject cross-brand tokens in every API.
• Give each brand its own custom domain, branding, emails and sender domain.
• Test session scope between every pair of brands before launch.
• Store consent per brand, purpose and notice version.
• Require authenticated sessions on both sides, notification and unlinking for cross-brand links.
• Decide the passkey model: per brand, federated hub or Related Origin Requests.
• Log brand context on every identity event and alert on cross-brand anomalies.

Standards and references

• OpenID Foundation: OpenID Connect Core 1.0
• GDPR: Article 26 Joint controllers
• passkeys.dev: Related Origin Requests
• AWS: Amazon Cognito multi-tenant application best practices
• Auth0: Multiple Custom Domains
• Keycloak: Server Administration Guide
• Microsoft Learn: Custom URL domains in External ID

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · B2B CIAM and Organisation Management Guide · B2B vs B2C CIAM · Multi-Tenant SaaS Authorisation and Tenant Isolation Guide