In this blog post Move Exchange Mailboxes Securely with OAuth in Microsoft 365 we will explain how to replace password-based authentication in MRS mailbox migrations with OAuth, without turning the project into an unnecessary business disruption.
For many IT leaders, the uncomfortable issue is not whether Exchange mailboxes can be moved. It is whether the migration quietly depends on a privileged username and password that could be stolen, reused or forgotten after the project finishes.
What has changed for Exchange mailbox migrations
Microsoft 365 uses the Mailbox Replication Service, commonly called MRS, to copy mailboxes between an on-premises Exchange environment and Exchange Online. Think of it as the engine responsible for moving email, calendars, contacts, mailbox rules and other mailbox data.
On the on-premises side, MRS connects through MRS Proxy, which is a controlled doorway within Exchange Web Services. A migration endpoint tells Microsoft 365 where that doorway is and how it should authenticate.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingHistorically, these remote moves relied on Basic authentication using the username and password of a privileged on-premises account. Microsoft now supports OAuth for MRS migrations, allowing the service to use a dedicated application identity and access tokens instead of a reusable administrator password.
Why Basic authentication creates unnecessary business risk
Basic authentication is simple, but that simplicity is the problem. The migration endpoint depends on a password that may belong to an account with significant access to your Exchange environment.
If the password expires halfway through the project, migration batches can fail. If it is exposed, an attacker may gain access far beyond the mailboxes being moved.
This also creates operational questions that are often overlooked:
- Who knows the migration account password?
- Where has it been entered, stored or documented?
- Does the account still exist months after the migration?
- Does it have more access than the migration actually requires?
- Would suspicious use of the account be detected quickly?
OAuth improves this by replacing the human account with a defined application identity. Microsoft Entra ID, which manages identities and access for Microsoft 365, issues a token confirming which application is connecting and what it is allowed to do.
This does not make the entire migration automatically secure. It removes one important weakness: a long-lived, reusable password connected to a privileged account.
How OAuth for MRS works in plain English
The OAuth design involves three main parties. Microsoft 365 MRS requests access, Microsoft Entra ID verifies the application identity, and your on-premises Exchange server accepts the token only when the expected tenant and permissions match.
The application is given a specific role for mailbox migration. Exchange can then distinguish a legitimate Microsoft 365 migration request from another application attempting to reach MRS Proxy.
This is separate from Hybrid Modern Authentication, which controls how users sign in to services such as Outlook. OAuth for MRS is designed specifically for the application-to-application connection used during mailbox moves.
That separation matters. A migration service should not inherit broad access simply because other hybrid Exchange features are enabled.
Check whether your environment is supported
Do not begin by changing a working migration endpoint. Start by confirming that your Exchange version, security updates and Microsoft 365 environment support the new method.
At its November 2026 launch, OAuth for MRS required Microsoft 365 commercial multi-tenant environments and either the October 2026 or newer release of Exchange Server Subscription Edition, or Exchange Server 2019 CU15 with the latest Extended Security Update. Existing Basic authentication endpoints remained supported and were not automatically changed.
Use the Exchange Management Shell to review your servers and MRS Proxy configuration:
Get-ExchangeServer |
Format-Table Name, Edition, AdminDisplayVersion
Get-WebServicesVirtualDirectory |
Format-List Identity, MRSProxyEnabled, ExternalUrlMRS Proxy needs to be enabled on the relevant Exchange mailbox servers. If several servers sit behind a load balancer, check every server rather than assuming they share the same configuration.
A practical rollout plan
1. Document the current migration path
Record the Exchange servers involved, external MRS Proxy address, firewall path, certificates, existing migration endpoints and any active batches. This gives you a rollback position if testing uncovers a problem.
You can review the current Microsoft 365 migration endpoints with:
Connect-ExchangeOnline
Get-MigrationEndpoint |
Format-List Identity, EndpointType, RemoteServer,
MaxConcurrentMigrationsAvoid deleting or modifying an endpoint being used by an active migration batch. Build and test the OAuth endpoint in parallel.
2. Create a dedicated application identity
Register the on-premises MRS Proxy service as a single-tenant application in Microsoft Entra ID. The Application ID URI must be specific to the MRS Proxy endpoint, use a verified tenant domain and be entered in lowercase.
The current Microsoft process also requires an application role for the migration purpose and specific token claims. These claims help Exchange confirm that the token represents an application and that it was issued for the intended resource.
Record the application ID, service principal Object ID, tenant ID and Application ID URI carefully. Confusing an application ID with an Object ID is a common cause of failed OAuth deployments.
3. Authorise Microsoft 365 MRS
The Microsoft 365 MRS service principal must be registered in your tenant and assigned the migration application role. Your on-premises Exchange environment must then be configured to trust the correct tenant-specific identity.
This stage should be treated as a controlled security change. Use separate implementation and review steps so one administrator is not creating, granting and approving every permission without oversight.
4. Create and test a new OAuth migration endpoint
Create a separate OAuth endpoint in Exchange Online rather than converting the production endpoint immediately. Test connectivity and confirm that Exchange accepts the token before adding real users.
Review load balancers, web application firewalls and reverse proxies as part of testing. Security devices that modify authentication headers or send requests to an Exchange server without MRS Proxy enabled can produce confusing authentication failures.
5. Run a small pilot batch
Start with several representative mailboxes: a standard user, an executive assistant with delegated access, a large mailbox, an archive-enabled mailbox and a user with a mobile device.
$batch = New-MigrationBatch `
-Name "OAuth-Pilot-01" `
-SourceEndpoint "OAuth MRS Endpoint" `
-TargetDeliveryDomain "contoso.mail.onmicrosoft.com" `
-CSVData ([System.IO.File]::ReadAllBytes(
"C:\Migration\Pilot.csv"))
Start-MigrationBatch -Identity $batch.IdentityMonitor both migration progress and the employee experience. A technically completed mailbox is not a successful migration if delegates lose access, Outlook repeatedly asks for credentials or business-critical applications stop sending email.
What a lower-risk migration looks like
Consider a 180-person professional services company moving from Exchange Server to Microsoft 365. Its original plan used a migration account placed in a powerful Exchange role group, with the password shared between the internal IT manager and an external provider.
Moving to OAuth removes the need to keep that privileged password attached to the migration endpoint. The company can test ten mailboxes, monitor the result, increase batch sizes gradually and retain the original endpoint temporarily as a documented fallback.
The immediate business outcome is reduced credential risk. The longer-term outcome is cleaner access control, easier auditing and less chance of an old migration account becoming an unnoticed route into Exchange.
OAuth is one control, not the whole security plan
A secure migration still requires supported Exchange servers, current security updates, protected administrator accounts, tested backups, controlled firewall access and monitoring. OAuth should not become another box that is ticked while those basics remain unresolved.
This is similar to the problem discussed in why MFA alone leaves dangerous gaps. One strong control cannot compensate for weak administration elsewhere.
For Australian organisations, reducing privileged password use also supports the intent of the Essential Eight, the Australian Government’s cybersecurity framework, particularly around restricting administrative privileges, applying security updates and strengthening authentication.
After the move, review the wider tenant using a structured Conditional Access checklist. Conditional Access sets rules about who can enter Microsoft 365, from which devices and under what conditions.
Make the security improvement without delaying the migration
Replacing Basic authentication with OAuth in MRS removes a reusable privileged password from a sensitive connection. Done properly, it reduces risk without forcing you to redesign the entire mailbox migration.
The safest approach is to confirm support, document the current environment, build a parallel OAuth endpoint, test representative users and expand only after the evidence says it is safe.
CloudProInc brings more than 20 years of enterprise IT experience across Exchange, Microsoft 365, Azure and cybersecurity. As a Melbourne-based Microsoft Partner, we help organisations plan and test mailbox migrations without the overhead of a large, faceless provider.
If you are unsure whether your current migration endpoint is still relying on a privileged password, we are happy to review the setup and explain the practical options — no strings attached.