Office 365 Migration Endpoint Authentication Errors

There's a particular flavor of frustration that comes with a migration that was working fine an hour ago and is now throwing 'authentication failed with the remote server" for no apparent reason. Nothing in the mailbox changed. Nobody touched a password. And yet the migration endpoint just stops trusting the connection. Most of the time, this isn't really a migration problem — it's an identity problem wearing a migration error message. Microsoft has spent the last several years steadily phasing out Basic Authentication across nearly every Exchange Online protocol, and a lot of migration tooling that worked perfectly well in 2021 quietly stopped working once Basic Auth was switched off for good. EdbMails Office 365 Migration is built on modern, OAuth-based authentication for its Microsoft 365 connections, which sidesteps most of the errors this page covers — but understanding what's actually going on under the hood still helps when a migration endpoint refuses to authenticate. Here's a practical breakdown of why these errors happen and how to get past them.

What Is a Migration Endpoint, and Why Does Authentication Fail There?

A migration endpoint is essentially the connection profile a migration job uses to reach a mailbox source or target — it tells the migration service how to connect, what credentials or tokens to use, and which authentication protocol to speak. When that authentication step fails, the endpoint can't establish a trusted session, and the migration can't move data in either direction.

Authentication errors at this layer almost always trace back to one of a few root causes: the authentication protocol itself being unsupported, expired or incorrectly scoped credentials, missing application permissions, or a mismatch between what the endpoint is configured to use and what Microsoft's servers will actually accept.

Why This Has Gotten More Common Recently

For years, Basic Authentication — a simple username-and-password handshake — was the default way many migration tools and scripts connected to Exchange Online. Microsoft began retiring it protocol by protocol: EWS, EAS, POP, IMAP, and Remote PowerShell were all cut over to Modern Authentication by the end of 2022. SMTP AUTH Client Submission held on longer, but Microsoft's latest timeline has Basic Auth disabled by default on existing tenants by the end of December 2026, with no exceptions or permanent waivers being granted after that.

Separately, Microsoft began deprecating the Application Impersonation role — long used by many migration and backup tools to access mailboxes on a user's behalf — starting in February 2025, in favor of more granular API permission models. Tools and scripts still leaning on Application Impersonation are increasingly likely to hit permission failures with no advance warning of exactly when.

Put together, a lot of the authentication errors administrators are running into during migrations today aren't really new bugs — they're old configurations finally catching up with Microsoft's security roadmap.

Common Endpoint Authentication Errors and What They Actually Mean

"Authentication failed with the remote server" / MigrationPermanentException

AADSTS700016, AADSTS90002, AADSTS50126

These Entra ID (Azure AD) sign-in error codes show up frequently when configuring OAuth-based migration endpoints. Broadly: AADSTS700016 usually means the application ID being used either wasn't found in the tenant or hasn't been properly registered/consented; AADSTS90002 typically points to an incorrect tenant ID; AADSTS50126 generally signals invalid username or password credentials being passed where they shouldn't be. Getting any of the Application ID, Tenant ID, or client secret fields wrong on a migration endpoint produces one of this family of errors.

535 5.7.3 Authentication Unsuccessful

Common on SMTP-based connections. This typically means SMTP AUTH isn't enabled for the account in question, or a tenant-wide Security Defaults policy is blocking legacy authentication outright. Re-enabling SMTP AUTH per mailbox or adjusting Conditional Access policy (rather than disabling Security Defaults wholesale) is the usual fix.

Sign-in Loops or "An Error Occurred" with AD FS Environments

In federated environments using AD FS, modern authentication requires forms-based authentication to be enabled as a fallback. If it isn't, users and service accounts can get stuck in a sign-in loop or hit a generic "contact your administrator" error during migration-related authentication.

Application Permission / Impersonation Errors

As Microsoft phases out Application Impersonation, tools still depending on it for mailbox access may start failing intermittently, with no fixed date for when a given tenant's access will actually break. The recommended path is migrating to application-level API permissions and OAuth app registrations rather than waiting for impersonation to be cut off entirely.

How Different Migration Approaches Handle Authentication

The pattern across all of these: tools still depending on Basic Authentication or Application Impersonation are working against a closing window, while tools built around explicit OAuth app registrations and modern permission scopes are aligned with where Microsoft's platform is heading.

How EdbMails Handles Authentication for Office 365 Migrations

EdbMails Office 365 Migration Software connects to Microsoft 365 using modern, OAuth-based authentication rather than legacy Basic Authentication or Application Impersonation, which keeps it aligned with Microsoft's current and announced security direction rather than relying on protocols already being phased out. In practical terms, this means:

• OAuth-based connections to Exchange Online, avoiding dependency on Basic Authentication that Microsoft is actively disabling across tenants.
• Support for Microsoft 365 app registration and permission-based access, rather than the Application Impersonation role currently being deprecated.
• Clear, mailbox-level error reporting when an authentication issue does occur, allowing administrators to determine whether the problem is caused by missing permissions, token issues, or tenant-side restrictions instead of a generic failure.
• Compatibility with Modern Authentication requirements already enforced across Exchange Online, Microsoft Teams, and SharePoint, preventing migration projects from being disrupted by authentication policy changes during execution.

This doesn't mean every authentication error disappears — issues like incorrect app permissions, expired admin consent, or tenant-side Conditional Access policies still need to be resolved at the Microsoft 365 admin level. But the underlying connection method itself isn't the thing standing in the way.

Step-by-Step: Troubleshooting a Migration Authentication Error

1. Read the exact error code or message. Errors such as "Authentication failed with the remote server", an AADSTS code, or an 535 5.7.3 SMTP error indicate different layers of the authentication process and should be investigated accordingly.
2. Confirm which authentication method the migration endpoint is actually using. For PowerShell-managed endpoints, verify that the Authentication property is set to OAuth and that the Credentials field is empty. A populated username typically indicates that legacy authentication is still being used.
3. Verify the Application (Client) ID and Directory (Tenant) ID configured for OAuth authentication. Authentication failures frequently occur because one of these values is incorrect or belongs to a different Microsoft 365 tenant.
4. Confirm that administrator consent has been granted for all required Microsoft Graph or Exchange Online application permissions. Without tenant-wide admin consent, OAuth authentication cannot succeed even if the application registration is otherwise configured correctly.
5. If using SMTP AUTH, verify that SMTP authentication is enabled for the affected mailbox and confirm that Security Defaults or Conditional Access policies are not blocking legacy authentication protocols across the tenant.
6. For AD FS environments, verify that forms-based authentication is enabled as a supported fallback authentication method.
7. If your migration still depends on the Application Impersonation role, plan to migrate to modern app-based permissions rather than waiting for the feature to stop working. Microsoft has announced its deprecation but has not published a fixed retirement date for every tenant.
8. After making configuration changes, re-test connectivity to the affected mailbox using the migration tool's mailbox connection or connectivity test before restarting the full migration batch.

Best Practices to Prevent Authentication Errors During Migration

• Inventory all accounts, scripts, and migration tools in your environment that still rely on Basic Authentication before starting the migration project.
• Register the required Microsoft 365 application and grant administrator consent for all necessary permissions well before migration day, rather than during a live cutover.
• Avoid designing new migration workflows around the Application Impersonation role, as Microsoft is actively deprecating this authentication model.
• Keep migration endpoint configurations clean by removing legacy username and password credentials from endpoints that are intended to use OAuth authentication.
• Validate authentication by testing connectivity to a single pilot mailbox before launching a full migration batch.
• Monitor Microsoft's published timelines for Basic Authentication and other legacy protocol deprecations, as implementation schedules may change over time.

---

Additional resources:

• EdbMails Office 365 Migration Tool
• Resolve Office 365 Mailbox Mapping Errors
• Exchange Online Service Limits for Migration
• Coexistence During Office 365 Migration