Fixing "Modern Authentication Required" Errors in Migrations

Your migration job dies at the very first IMAP LOGIN command and the log line reads AUTHENTICATIONFAILED basic authentication is disabled. The credentials are correct, MFA is satisfied, the mailbox exists. None of that matters, because Microsoft 365 no longer accepts a password on IMAP. The fix is not a new password — it is a different authentication method entirely. This post walks through why the error appears, how to switch to OAuth 2.0 with the device code flow, and what to do when tenant policy still blocks you.

Why "modern authentication required" appears#

Microsoft retired basic authentication for IMAP, POP, EWS, MAPI, Remote PowerShell, ActiveSync, and Offline Address Book against Exchange Online. The retirement applied tenant-wide, and the per-tenant override that some admins relied on has also been removed. Any IMAP client that still presents a username and password over AUTH LOGIN or AUTH PLAIN is rejected at the protocol layer, regardless of whether the password is right.

The server response varies a little by provider, but the patterns you will see in a migration log include:

• * BAD User is authenticated but not connected.
• NO AUTHENTICATE failed.
• NO LOGIN failed: basic authentication is disabled
• A001 NO [AUTHENTICATIONFAILED] Authentication failed

The OAuth path uses AUTHENTICATE XOAUTH2 instead of LOGIN, and the credential is a bearer token issued by Entra ID — not a password. That token is bound to a specific app registration, a specific scope (https://outlook.office.com/IMAP.AccessAsUser.All), and a specific user, and it expires hourly.

The supported fix: OAuth 2.0 device code flow#

For a desktop migration tool, the cleanest auth path is the OAuth 2.0 device code flow. You sign in to a normal browser window, paste a one-time code, and Entra ID hands a token back to the migration app. No client secret is stored on disk, the token lives in your OS keychain, and refresh happens silently.

1. Find the failing log line

   Open the run's debug log and search for AUTHENTICATIONFAILED, LOGIN failed, or basic authentication. If you see any of those against outlook.office365.com:993, you are hitting the modern auth requirement, not a typo in the password. Note the exact account name — you will reuse it in the OAuth prompt.

2. Switch the connection type to OAuth

   In Mailbox Taxi, remove the failing connection and add it back with the provider preset Microsoft 365 (OAuth) rather than a generic IMAP entry. The preset hardcodes the correct authority (login.microsoftonline.com/common), scope, and IMAP endpoint, which avoids a common copy-paste mistake.

3. Complete the device code prompt

   The app shows a short alphanumeric code and a verification URL. Open the URL in any browser, paste the code, and sign in with the account whose mailbox you are migrating. If MFA is required, finish the second factor in the same browser session. The migration window will pick up the token automatically once consent is granted.

4. Handle 'AADSTS65001: consent required'

   If you see AADSTS65001 or a tenant-level consent screen instead of a normal sign-in, your tenant restricts user consent for third-party apps. Send the tenant admin the consent URL from the error page and have them approve IMAP.AccessAsUser.All for the app once. After that, every user in the tenant can complete the device flow without admin involvement.

5. Re-run the migration

   Restart the job. The first IMAP connection will use AUTHENTICATE XOAUTH2; subsequent connections inside the same run share the cached token, and Mailbox Taxi refreshes silently before expiry. There is nothing else to configure.

If you need a deeper primer on how OAuth 2.0 access and refresh tokens actually flow, the OAuth 2.0 entry in the glossary covers the role of the authorization endpoint, the token endpoint, and the refresh token lifetime in plain language.

When OAuth still fails#

A successful device code flow is not always the end of it. Three follow-on errors are common during migrations.

Conditional Access blocks the sign-in#

Conditional Access policies can require a compliant device, a trusted network, or a specific MFA strength. The error you see is usually AADSTS53003 or AADSTS50158. The fix is policy-side: either exclude the migration account from the policy for the duration of the cutover, or run the migration from a compliant device on the trusted IP range. The migration tool cannot work around the policy and should not try.

App is not approved for the tenant#

If your tenant has Microsoft's app governance feature on and the migration app is unverified there, you will see a consent screen even after admin approval. Add the app's object ID to the allow-list under Enterprise Applications and re-run.

Token expires mid-run#

Long migrations sometimes outlast the initial access token. The refresh token should handle this transparently, but if the refresh fails — typically because the user's password was rotated during the migration — you will see the OAuth token expired error and the job will pause. Sign in again from the same panel and the run resumes from the last committed UID.

Verifying it actually worked#

After the first OAuth-backed run, check three things to confirm the fix held:

• The migration log shows AUTHENTICATE XOAUTH2 followed by OK AUTHENTICATE completed, not LOGIN.
• The Entra ID sign-in logs for the user show an interactive sign-in to the migration app within the last few minutes.
• A test transfer of a small folder (Sent Items is a good choice) lands with the original INTERNALDATE preserved.

If any of those three are off, treat it as a separate problem rather than a modern auth issue. The authentication failed troubleshooter covers token scope mismatches and the Office 365 migration guide walks through the full end-to-end run.

For the broader picture of migration error categories, the troubleshooting hub groups every common failure mode by symptom.