Fixing MFA Blocking an Email Migration

You kick off a 200-mailbox migration at 9pm on a Friday, walk away, and come back Saturday morning to find every single mailbox stuck on the first connection with AUTHENTICATIONFAILED. The tenant has MFA enforced for all users, basic auth was retired in 2022, and your migration tool is still trying to do username-and-password IMAP. This is one of the most predictable auth failures in any 2026 migration, and the fix depends on which provider you're connecting to and which auth model you've already deployed. Here's how to unblock it without disabling MFA for your users.

What you'll actually see in the logs#

The error signatures depend on the source, but the cause is usually one of three:

• Basic auth is disabled at the tenant. Microsoft 365 tenants created after 2020 have basic auth off by default and cannot turn it back on. IMAP, POP, SMTP AUTH, EWS, and ActiveSync all fail with AUTHENTICATIONFAILED or Authentication unsuccessful.
• Conditional access blocks the migration IP or service principal. Even if basic auth works in principle, a CA policy that requires compliant device, named location, or MFA every sign-in will block an automated tool.
• MFA prompt is required but cannot be satisfied. The user has MFA enabled, no app password exists, and the tool has no OAuth2 grant. The IMAP server returns auth failure because the second factor was never delivered.

Each of these has a different fix. Don't start changing tenant settings until you know which one you're hitting.

Fix path 1: app passwords (when basic auth still works)#

If the source is Gmail with 2-Step Verification on, or a Microsoft 365 tenant that still has basic auth allowed, app passwords are the fastest unblock. An app password is a 16-character credential generated per user that bypasses MFA for a single client.

1. Confirm app passwords are available

   On Google Workspace, the admin must allow "Less secure app access" or, preferably, leave 2SV on and let users generate app passwords from myaccount.google.com → Security → App passwords. On Microsoft 365, app passwords work only if you're using per-user MFA (the older model), not security defaults or conditional access.

2. Generate one per user

   Have users sign in to their account security page and create an app password labeled "Migration." Capture the 16-character output and store it securely until migration completes.

3. Feed it to the migration tool

   Mailbox Taxi and most IMAP tools accept the app password in the same field as the regular password. Test the connection before running the full migration — a typo in the app password will fail identically to a wrong real password.

4. Revoke after cutover

   Once the migration completes, have each user revoke the migration app password. Leaving them active is a long-term risk because they bypass MFA.

For Gmail specifically, the Gmail app password fix walks through the exact menu paths and common pitfalls.

Fix path 2: OAuth2 (when basic auth is disabled)#

If your tenant has basic auth fully disabled — which is the default for any Microsoft 365 tenant since the 2022 deprecation — app passwords won't help. You need OAuth2 with a registered app and admin consent.

1. Register an app in Entra ID (Azure AD)

   In the Microsoft 365 admin center, navigate to Entra ID → App registrations → New registration. Give it a name like "Mailbox Taxi Migration" and accept the default single-tenant scope. Record the Application (client) ID and Directory (tenant) ID.

2. Grant the right API permissions

   Add Mail.ReadWrite, Mail.Send, and Mailbox.Migration if your tool supports them. For IMAP-focused tools, you may also need IMAP.AccessAsApp or full_access_as_app. Grant admin consent so the permissions apply to all mailboxes without per-user approval.

3. Configure a client secret or certificate

   Generate a client secret (short-lived) or upload a certificate (long-lived). Certificates are preferable for any migration that might span more than a few days.

4. Configure the migration tool with the OAuth2 credentials

   Provide the client ID, tenant ID, and secret/certificate to the migration tool. It will request access tokens automatically and present them to IMAP via the XOAUTH2 SASL mechanism.

5. Confirm token issuance

   Watch the first connection in the migration log. You should see a token-acquisition log line followed by a successful IMAP login. If you see OAuth2 token expired or invalid_grant, the secret is wrong or admin consent wasn't applied.

The full OAuth2 setup is also covered in fix modern auth required for cases where the error message specifically mentions modern authentication.

Fix path 3: conditional access exclusions#

Sometimes auth works in isolation but conditional access blocks the migration tool because it doesn't match the policy's compliance, location, or MFA-frequency rules. The fix is a narrowly scoped exclusion:

1. Identify the service principal of the migration app you registered (or the named IP range the migration tool runs from).
2. In the conditional access policy that's blocking, add an exclusion for that service principal or IP range.
3. Document the exclusion in your change log with a stop date — typically the day after cutover.
4. After cutover, remove the exclusion and confirm the policy reapplies.

When the source is Gmail with security keys#

If the source Gmail account uses physical security keys (FIDO2 / Titan), app passwords are blocked entirely. You have two options:

• Have the user temporarily switch to TOTP-based 2SV for the migration window, generate an app password, then switch back.
• Use OAuth2 via the Gmail API with a service account and domain-wide delegation. This is the cleaner long-term solution for Google Workspace migrations.

For more context on the wider auth failure space, see the email migration troubleshooting hub. The hub covers throttling, TLS, and DNS issues that often surface alongside auth problems during a real cutover.