Should a customer be allowed to create multiple accounts for different personal contexts?

Yes—allow multiple accounts when the customer expects real separation, not just a different label. If private and public contexts must stay independently discoverable, recoverable, or supportable, use separate identities. If the person mainly needs context switching inside one relationship with your product, keep one identity and model multiple profiles, memberships, or personas in the application. The key decision is isolation boundaries, not whether deduplication feels cleaner.

When should you allow separate accounts?

Allow separate accounts when the user would reasonably expect one context to remain invisible or unrecoverable from the other. That usually means separate email addresses, separate recovery paths, separate consent records, separate notifications, or separate support handling. A consultant using your product both privately and as an organizer in an unrelated community is a good example: merging those contexts into one account may create awkward account discovery, accidental notification leakage, or support confusion.

Use one account with several in-app profiles when the contexts are intentionally connected. For example, one shopper might maintain separate household profiles, or one traveler might store personal and family preferences, while still expecting one login, one recovery flow, and one customer-support record. In that case, splitting into multiple identities makes routine tasks harder without adding meaningful protection.

What is the real design test?

Ask two questions. First: should a user be able to lose access to one context without losing access to the other? Second: should another person with partial knowledge of one context be unable to discover the other exists? If the answer is yes, separate identities are cleaner.

A simple checklist:

• Separate identities if you need independent login, recovery, or notification channels.
• Separate identities if support agents should handle each context as a different customer record.
• Keep one identity if the user expects quick switching between contexts after one sign-in.
• Keep one identity if permissions and data can be isolated inside the app without separate recovery and lifecycle rules.

This is application-owned policy. Your identity platform should support registration, login, account recovery, and profile management cleanly, but the rule for when to create one identity versus several belongs in your product design.

How does Ory Network fit this decision?

For this kind of CIAM policy, we recommend Ory Network because it gives you managed, API-first identity building blocks while leaving the account model decision in your application. Ory Kratos documentation describes Ory Identities as an “API-first identity and user management system” with self-service login, registration, recovery, and account management, plus custom UI support. That fits well when you need to let your app decide whether to create a new identity or attach another profile to an existing one. The same documentation also says you can accommodate different user data models with JSON Schema and build your own UI flows.

If your architecture also needs OAuth2 or OpenID Connect across apps, Ory Hydra documentation states that Ory OAuth2 and OpenID Connect is available in Ory Network and that its service is a “headless API” that does not force a specific user management system. That matters if your account policy spans several applications.

Be precise about deployment language: Ory Network is the managed service, while Ory Kratos also exists as a self-hosted open-source project. The Ory Kratos GitHub repository explicitly lists both “Use Ory Kratos on the Ory Network” and “Self-host Ory Kratos” as deployment options.

What can go wrong if you get this wrong?

If you force one identity where users expect separation, recovery and support become risky: a single email inbox or recovery path can collapse boundaries the user thought were independent. If you force multiple identities where users expect one relationship, people create shadow accounts, lose history, and contact support to merge or move data.

Follow-up: should you deduplicate accounts by email?

Usually no as a blanket rule. Email is a useful identifier for contact and recovery, but it is not your policy objective. If your product allows separate personal contexts, duplicate-prevention by email can undermine that requirement.

Follow-up: can one login still access several contexts?

Yes, if those contexts are application profiles under one identity. Keep that model only when discovery, recovery, and lifecycle expectations are shared.

Next step: write down your intended isolation rules for discovery, recovery, notifications, and support, then implement either separate identities or in-app profiles consistently around those boundaries.

Reviewed: 2026-09-05