Issue: Azure DevOps access failing after company domain change.

Hey! Sorry you’re running into this—what you’re describing (Azure DevOps redirects you to an old UPN/identity and then returns 403 Forbidden) is a pretty common symptom of the user identity mapping/session state not being refreshed after an identity change.

Based on the provided Azure DevOps “Sign-in Issues” guidance, here are the most relevant things to try and check:

1) Sign out completely + clear cookies (force a fresh auth)

Azure DevOps recommends doing a full sign-out and deleting browser cookies so it doesn’t reuse cached authentication tied to the old identity.

Try:

1. Sign out of Azure DevOps completely (this signs out all active browser sessions).
2. Delete cookies in your browser (and specifically for Azure DevOps).
   • You can use Ctrl+Shift+Delete to clear browsing data.
   • If using Visual Studio, it also uses Microsoft Edge cookies, so clear those too.
3. Open an InPrivate/Incognito window.
4. Navigate directly to https://dev.azure.com/<YourOrganizationName> and sign in with the new @abc.com work account.

This step matters because Azure DevOps (and the browser) can keep using an existing session/token that was issued for the prior identity.

2) Confirm you’re signed in to the right account and right Entra tenant

Even if you “start the login” with the new address, you may still end up authenticated to the old one if multiple identities/tenants are in play.

Azure DevOps guidance suggests:

• If you have work and personal accounts, make sure you’re on the work account.
• If your work account belongs to multiple Microsoft Entra tenants, switch to the correct tenant from the account/tenant selector and then sign in again.

3) If the organization is backed by Microsoft Entra ID: 403 can be permission/policy related

For a 403 Forbidden, the doc calls out two main possibilities when the organization is backed by Entra ID:

• Guest user access: contact the organization owner / project collection admin to verify the organization security policy (External guest access).
• Member user access: access may be blocked by Conditional Access policies. In that case, the organization owner / project collection admin should check the policy.

4) If identities changed due to domain/UPN change: re-map access on the Azure DevOps side

Your scenario sounds like your org granted access to the new domain accounts, but Azure DevOps is still resolving you to the old identity. The doc includes guidance that if access mapping is wrong, admins may need to remove and re-add the user(s) so Azure DevOps links the correct Entra identities.

At a minimum, have the customer/organization owner check whether:

• the new accounts are properly added,
• the old identity isn’t still considered the mapped identity for the user,
• the user needs to be removed/re-added to resolve the mapping.

5) (If relevant) Check for CAE/conditional access timing effects

Azure DevOps also notes support for Continuous Access Evaluation (CAE) (rolling out from Nov 2025), which enforces Conditional Access more quickly when critical events occur (like disablement/password reset/location changes, etc.). If the environment uses Conditional Access, the organization owner should validate that no access-revocation logic is now impacting sign-in.

References (provided documentation)

• Sign-in issues in Azure DevOps (includes full sign-out + delete cookies, 403 causes, account/tenant switching): https://learn.microsoft.com/azure/devops/user-guide/troubleshoot-connection?view=azure-devops
• Capture a browser trace for troubleshooting (from the same Sign-in Issues doc): https://learn.microsoft.com/azure/devops/user-guide/capture-browser-trace?view=azure-devops
• Change Azure AD connection (includes the “immediate steps” for Entra connection completion: sign out, clear cache, sign back in): https://learn.microsoft.com/azure/devops/organizations/accounts/change-azure-ad-connection?view=azure-devops
• Configuring with Microsoft Entra ID / Entra connection and troubleshooting (includes CAE/conditional access notes): https://supportabilityhub.microsoft.com/solutions/apollosolutions/e94aeedc-3345-e791-61c2-e134f416b103/apollo-aae30144-3bca-412c-b366-cb6179c4b34b
• Connect your organization to Microsoft Entra ID (includes cache clearing guidance): https://supportabilityhub.microsoft.com/solutions/apollosolutions/eabd5636-7357-729f-6ca3-4b0a5a78a69c/apollo-f6b88fe7-454b-4e8a-903f-c7026b8faaaa