The behavior is caused by the same email address existing as both a personal Microsoft account (MSA) and a work/school identity in a Microsoft Entra tenant. When the same sign-in address is shared, Azure can route sign-in to the wrong identity and enforce that tenant’s MFA.
From the provided information, only the following supported actions and facts apply:
- Forcing the “personal account” path
When an email address is used that exists as both a personal and a work/school identity, the sign-in experience can ask to choose between Work or school account and Personal account. These are separate identities with different profiles, security settings, and permissions:
- Select Personal account if Azure DevOps or other services were created with the Microsoft account identity. In that case, “The global directory for Microsoft accounts authenticates your identity.”
- Select Work or school account only if the Entra directory identity was used to create or access the organization.
If the wrong identity was selected previously and is now cached, sign-out must be forced and the sign-in flow restarted so the correct identity can be chosen:
- Close all browsers.
- Open a private/incognito session.
- Go to
https://aka.ms/vssignout to sign out of Azure DevOps and related sessions.
- After sign-out completes and the browser redirects, sign in again and explicitly choose Personal account when prompted to pick between “work or school” and “personal” for the same email address.
This guidance is explicitly documented for Azure DevOps, but the same identity distinction applies across Microsoft services.
- Why the wrong account type causes sign-in failures
When the same sign-in address is used for both account types:
- “You can only sign in to the Microsoft service that your account is set up for.”
- “If you try to use your Microsoft account to sign in to a business service, you'll receive an error.”
- There is “no synchronization of user account information between personal and work or school accounts.”
If the Entra (work/school) identity does not have access or is blocked by MFA, sign-in fails even though the personal account exists.
- Self-service leaving a tenant / detaching from a tenant
The context provided does not contain a supported, documented self-service method to:
- Leave a guest tenant when blocked by that tenant’s MFA, or
- “Detach” a personal Microsoft account from a third-party corporate tenant.
The only related guidance in the context is:
- For a personal account that cannot be closed because it appears linked to an organization/tenant, escalation was required outside Entra support; the Azure/Entra team explicitly stated: “we can help only for queries related to Microsoft Entra ID” and directed the user to open a different support path (for Outlook / Microsoft account) for email/account issues.
- For NuGet.org and similar services, if the Microsoft login cannot be used, the guidance is to contact Microsoft account support for MSA issues or the tenant admin for work/school account issues.
From this, the only supported pattern in the context is:
- Microsoft Entra ID support handles Entra directory issues.
- Personal Microsoft account issues (including sign-in problems and account recovery) are handled by Microsoft account support or the appropriate consumer support channel, not by Entra support.
- Which Microsoft department can detach an MSA from a corporate tenant
The context does not name a specific internal department that can “detach” a personal MSA from a third-party tenant.
However, it does show the separation of responsibilities:
- For personal Microsoft account problems (including when the account is effectively blocked or entangled with directory behavior), the documented contact is Microsoft account support (“Get help with your Microsoft account”) or the consumer support path (for example, Outlook support in one of the Q&A cases).
- For work or school account issues, the documented contact is Work or school account help or the tenant administrator.
No additional, more specific internal team name or process is provided in the context.
In summary, based on the available documentation:
- Use a clean/private session, force sign-out, and when prompted, explicitly select Personal account for the shared email address.
- If sign-in continues to be forced through a corporate tenant and cannot be corrected by choosing the personal account, the only documented escalation path for a personal Microsoft account is through Microsoft account support (consumer account support), not Entra ID support.
- The context does not document any self-service method to leave a tenant when blocked by MFA, nor does it document a named internal Microsoft department that can detach an MSA from a third-party tenant.
References: