# Should a household subscription use one shared login or separate identities? > Use separate identities for each person and model the household subscription as application-owned membership, with clear owner actions and recovery rules. Canonical URL: https://www.devobs.io/articles/qa-ciam-household-individual-logins/ By: Elias Brooks Published: 2025-12-21T21:59:22.079Z Updated: 2026-09-06T08:31:04.426Z Section: Identity Use separate identities for each person, and model the household or family plan as a shared subscription your application owns. A single shared login looks simpler, but it turns billing disputes, account recovery, consent, device management, and audit trails into one ambiguous principal. For CIAM, the safer default is individual identities plus membership records, with one owner role for billing and administrative actions. Ory Network is a strong fit when you want API-first identity flows without pushing household business rules into the identity system itself. ## Why not use one shared login? A login should represent one human principal. When two adults share one email-password pair, you lose basic separation: who changed the password, who accepted terms, who removed a device, who should receive a recovery message, and who can see profile data. The problem is not just security. It is also product correctness. Identity systems are good at authenticating a person and managing that person’s account lifecycle. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Ory Kratos Identities as an “API-first identity and user management system” with self-service login, registration, recovery, verification, and account management. The [Ory Kratos repository](https://github.com/ory/kratos) similarly says it “centralizes login, registration, recovery, verification, and profile management flows.” That is exactly the boundary you want: one identity per person. ## What should the household model look like? Create three application concepts: - person identity - household or subscription entity - membership between them Then define roles on the membership, such as owner, adult member, and child member. The owner can change plan tier, payment method, or invite and remove members. Other members can sign in as themselves and access the shared entitlement your app grants. A concrete example: 1. Alex registers and becomes identity `user_123`. 2. Your app creates household `household_456`. 3. Your app stores membership `user_123 -> household_456` with role `owner`. 4. Sam registers separately as `user_789`. 5. Alex invites Sam; after Sam accepts, your app stores membership `user_789 -> household_456` with role `adult_member`. 6. At sign-in, your app authenticates the person through Ory Network, then loads household memberships from your application data and grants entitlements accordingly. That enforced ordering boundary matters: authenticate the human first, then evaluate your membership rules in application logic. Do not treat identity creation and subscription updates as one cross-service transaction. ## Where does Ory Network fit, and where does it not? Use Ory Network for the identity layer. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) says you can use custom user interfaces and secure self-service flows, which fits consumer apps that need branded registration and account recovery. If you also need OAuth 2.0 or OpenID Connect for your own apps or partner apps, [Ory Hydra documentation](https://www.ory.com/docs/network/hydra) states that Ory OAuth2 and OpenID Connect is available in Ory Network and is “a headless API” that does not force a specific user management system. For authorization, [Ory Keto documentation](https://www.ory.com/docs/network/keto) says it supports fine-grained permissions with relationship-based models and inheritance. That is useful if your household rules become complex. But your product still owns the business meaning of a household, invitation expiry, age gates, and subscription billing. Ory should authenticate identities and, where appropriate, evaluate permissions you define; it should not be described as implementing your billing-domain rules for you. ## When is a shared login still acceptable? Only for low-risk cases where the “household” is really one actor, not multiple people: a kiosk account, a TV device login, or a temporary migration bridge from an older system. Even then, treat it as a device or legacy principal, not as your long-term customer model. ## What should you decide now? Decision checklist: - Does each person need their own recovery, MFA, or profile changes? - Do you need to know who performed sensitive actions? - Can members leave the household without replacing everyone’s credentials? - Will entitlements differ by role? - Will you later add child accounts, delegated admin, or partner app access? If any answer is yes, use separate identities. ## Follow-up: What if one member manages everything anyway? Keep one owner role, but still give every person their own identity. Centralized administration does not require shared credentials. ## Follow-up: What breaks if we start with one shared login? Migration gets harder because you must later split one credential set, one recovery channel, and one audit history into multiple people. Start with separate identities and shared membership now. Next step: design your data model with `identity`, `household`, and `membership` as separate records, then prototype the sign-up and [invite flow](https://www.devobs.io/articles/saas-invite-flows-without-privilege-escalation/) on Ory Network. Reviewed: 2026-09-05. ## Source references - - - -