Customer Identity: EU Residency, Email Changes, and Multi-Brand Login
A media company launches a customer portal with 2.5 million existing subscribers. Requirements include email/password, Sign in with Apple and Google, progressive profiling, self-service password reset, and a branded custom domain. About 18% of users are in the EU and require data residency; 5% are minors requiring parental consent. The company has one Okta org in the US. The first release used the default Okta domain and email as the username. Users who changed email lost their profiles and purchase history. Marketing wants a second brand with a separate login page but a shared user base. Customer support reports 2,000 password reset calls per week, and the org is hitting SMS rate limits.
1. Evaluate the org and data residency strategy. Would you use one org, multiple orgs, or another pattern?
Read the worked answer
Start by confirming the contractual data residency requirement, not just the word 'EU.' If EU personal data must remain in an EU region and the current US org cannot meet that, one global org is not acceptable. The usual pattern is a regional org for EU customers and a US org for the rest, with a routing layer that sends each user to the correct org based on residency or account origin. That creates real tradeoffs: duplicate administration, cross-org identity linking, separate API rate limits, and a harder shared user base.
If the requirement can be met with the existing org's regional controls, keep one org. For the second brand, do not create a separate org just for branding. Use separate OIDC applications or authorization servers and brand-specific login pages inside the same org so the user base remains shared. Split orgs only for a hard isolation requirement such as residency, regulatory separation, or a completely separate business unit.
Document the decision with the legal and security teams. A residency decision made only by engineering is a compliance risk, and a multi-org design chosen only for convenience creates years of operational overhead.
2. The first release used email as the username, and email changes destroyed purchase history. How would you correct the identity model?
Read the worked answer
Stop treating email as the identity key. In Okta, use the immutable Okta user ID as the subject returned to applications, and store the legacy subscriber ID in externalId. If email must remain the login identifier, make it a mutable attribute and handle a change as an update to the existing user, not a new registration. Applications must key their data on the OIDC subject or the legacy subscriber ID, never on email.
For social login, do not automatically link an Apple or Google account to an existing account just because the email matches. Require the user to sign in to the existing account and then link the social identity, or use a verified-email flow with step-up authentication. Automatic linking by email enables account takeover when email ownership changes.
For the existing 2.5 million users, export the mapping between the legacy subscriber ID and the current Okta user ID. Backfill externalId before changing the login flow. Test with a user who changes email, signs out, signs back in with the new email, and confirms that purchase history is still attached to the same subject.
3. Design the multi-brand login and a plan to reduce the 2,000 weekly password reset calls. What Okta capabilities would you use, and what would you avoid?
Read the worked answer
Keep one org and one user base. Create brand-specific OIDC applications or authorization servers, each with its own branding, custom domain or login page, and callback URLs. Use the same user store so a subscriber can move between brands without a second account. Avoid separate orgs for each brand unless there is a legal isolation requirement; separate orgs would fragment the user base and make cross-brand SSO and support difficult.
For password resets, first instrument the recovery flow. Determine whether calls come from failed email delivery, unclear reset instructions, expired links, or users who no longer own the email. Improve the self-service recovery policy with clear email templates, a longer but still safe link lifetime, and a fallback that does not rely on SMS. Add passwordless options such as email magic links or Okta Verify where appropriate. Use progressive profiling to capture a recovery phone or backup email only when needed.
Monitor SMS rate limits and do not make SMS the primary recovery channel. Add rate limiting and alerting on recovery abuse. Target a measurable reduction: baseline the 2,000 calls, pilot the new recovery flow with 5% of users, and compare reset completion and call volume before expanding.