Office 365 Impersonation Rights: What to Use Now
Office 365 impersonation rights were historically used to let an application or service account access multiple Exchange Online mailboxes. In Exchange Online, the Application Impersonation RBAC role is now retired, so administrators should not use older PowerShell or Exchange admin center instructions as the current Microsoft 365 setup method.
Important Microsoft 365 Update
Microsoft completed the retirement of Exchange Online Application Impersonation in 2025. Current application integrations should use OAuth-based application authorization and, where appropriate, Exchange Online RBAC for Applications to control mailbox access.
If an older migration document tells you to assign Application Impersonation in Exchange Online, treat that instruction as legacy guidance rather than a current Microsoft 365 requirement.
What Was Office 365 Application Impersonation?
Application Impersonation was an Exchange authorization model that allowed an application or service account to access multiple mailboxes as the mailbox users. It was commonly used by Exchange Web Services (EWS) applications that needed one-to-many mailbox access.
The model provided broad access but offered fewer modern controls for application identity, visibility, and resource scoping than the authorization options now available through Microsoft Entra ID and Exchange Online.
What Replaced Application Impersonation?
Modern Microsoft 365 applications use OAuth-based application identities and permissions. The exact model depends on the protocol and application design.
| Authorization model | Current Exchange Online status |
|---|---|
| Exchange Online Application Impersonation | Retired; do not use as a current Exchange Online setup method. |
| EWS OAuth / app-only access | Supported for applications designed to use EWS with modern application authentication. |
| Microsoft Graph application permissions | Current application authorization model for Microsoft Graph workloads. |
| Exchange Online RBAC for Applications | Current Exchange authorization model that can assign application roles and restrict access with supported resource scopes. |
Exchange Online RBAC for Applications
RBAC for Applications lets an administrator assign an Exchange Online application role to a Microsoft Entra service principal and, when required, restrict that permission to a defined set of mailboxes. This provides a more granular alternative to broad, tenant-wide application access.
Microsoft currently provides application roles for Microsoft Graph and EWS scenarios, including roles such as Application Mail.Read, Application Mail.ReadWrite, and Application EWS.AccessAsApp. The role selected should match what the application actually needs.
Important: Do not manually assign a collection of application roles simply because they are available. Use the authorization requirements documented for the application and migration scenario.
Do You Need to Set Impersonation Rights for EdbMails?
For current Microsoft 365 migrations, administrators should not try to assign the retired Exchange Online Application Impersonation role just because older EdbMails or Microsoft documentation refers to impersonation.
The required access depends on the migration source, migration target, current EdbMails connection method, and Microsoft 365 authorization model. Follow the authentication and authorization steps presented by the current EdbMails workflow for your scenario. For the broader product capabilities and supported migration paths, see the Office 365 migration Tool.
Which Permission Model Applies?
| Scenario | What to verify |
|---|---|
| EdbMails with Microsoft 365 | Use the current EdbMails Microsoft 365 authentication/authorization workflow for the selected migration scenario. |
| Custom EWS application | Verify OAuth app-only or delegated EWS access and the application permissions required by that application. |
| Microsoft Graph application | Verify the Microsoft Graph application permissions required for the workload. |
| Scoped Exchange Online application access | Use Exchange Online RBAC for Applications with an appropriate application role and supported resource scope. |
| Legacy Application Impersonation deployment | Plan migration away from the retired Exchange Online role rather than creating a new impersonation assignment. |
Use the Least-Privilege Access Model
- Grant only the application permissions required for the migration or application workload.
- Where supported, scope Exchange Online application access to the mailboxes the application actually needs.
- Review existing Microsoft Entra application permissions before adding Exchange Online RBAC assignments.
- Remove obsolete or unnecessarily broad permissions after the migration or authorization transition is complete.
Microsoft Entra application permissions and Exchange Online RBAC assignments are additive. An unscoped Microsoft Entra permission can therefore provide broader access even when a scoped Exchange Online RBAC assignment also exists.
How to Verify Microsoft 365 Application Access
For Exchange Online RBAC for Applications, Microsoft provides the Test-ServicePrincipalAuthorization cmdlet to show the assigned application role, allowed resource scope, and whether a specified mailbox is in scope.
Example:
Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> -Resource <target mailbox>
Replace the placeholders with the service principal identity and mailbox you are testing. The test reflects Exchange Online RBAC assignments; permissions separately granted in Microsoft Entra ID must also be reviewed when evaluating effective access.
Common Microsoft 365 Authorization Problems
- The application authenticates but cannot access a mailbox: Check the assigned application role, service principal configuration, resource scope, mailbox inclusion, and the application-specific permission requirements.
- Access is broader than expected: Review unscoped Microsoft Entra application permissions as well as Exchange Online RBAC assignments.
- A recent permission change does not appear to work: Exchange Online application-permission changes can be affected by authorization caching. Microsoft documents cache behavior ranging from about 30 minutes to two hours depending on application activity.
- An EWS application cannot connect: Verify OAuth configuration, EWS application access, service principal configuration, and any Exchange EWS access restrictions.
- An older script cannot assign Application Impersonation: Do not troubleshoot it as a current Exchange Online role assignment; the role has been retired.
Legacy: Application Impersonation Instructions
Older EdbMails documentation described two ways to assign Exchange Online Application Impersonation: PowerShell and the Exchange admin interface. These resources are retained only as historical references and should not be used as the current method for configuring Exchange Online in Microsoft 365.
Legacy PowerShell Application Impersonation reference
Legacy Exchange admin interface Application Impersonation reference
Before Starting an Office 365 Migration
- Confirm the source and target connection methods required by the migration scenario.
- Verify the Microsoft 365 application identity, authentication method, and required permissions.
- Confirm that any mailbox scope includes all mailboxes intended for the migration.
- Test application access before starting a large migration batch.
- Review the Office 365 migration guide for the wider migration workflow.
- Use the Office 365 migration checklist to verify the remaining pre- and post-migration requirements.
