The End of RBAC Application Impersonation - Your 10-Step Survival Guide

Third-party applications and services have commonly used Exchange Web Services (EWS) for integration with Microsoft Exchange environments. Ensuring limited scope and secure integration with EWS often involves RBAC (Role-Based Access Control) Application Impersonation. While these solutions had their time in the sun, they are both being phased out. Microsoft originally announced their plans in a February 20th, 2024, post at Retirement of RBAC Application Impersonation in Exchange Online | Microsoft Community Hub then followed up with another post on November 13th, 2024: Critical Update: Application Impersonation RBAC Role Deprecation in Exchange Online. 

While EWS has a bit longer to live (October 1, 2026), Microsoft ardently encourages developers to migrate to Microsoft Graph sooner rather than later. When it comes to RBAC Application Impersonation, its deprecation is imminent (February 2025). In fact, as I write this post, it’s only days away. If you haven’t taken steps already, it’s time! This post gives a bit of background on RBAC Application Impersonation, and then gives a step-by-step plan for transition to modern methods. 

RBAC Application Impersonation in Exchange Online is a powerful feature that allows administrators to delegate specific permissions to an application or service, enabling it to impersonate (act on behalf of) users within the organization. This is commonly necessary for scenarios where an application, such as a backup solution, migration tool, or email monitoring service, needs to access users' mailboxes or perform tasks on behalf of users without the application needing direct access to user credentials. 

How RBAC Application Impersonation Works in Exchange Online 

1. Role-Based Access Control (RBAC): RBAC is a system in Exchange Online that manages permissions based on roles. Each role defines a set of permissions that allow users or applications to perform specific actions. Roles are assigned to users or service accounts, granting them the ability to perform tasks according to the permissions of that role.
   
   
2. Application Impersonation Role: Application impersonation is a specific role that allows an application to impersonate any user in the organization to access their mailbox, calendar, tasks, etc. This means the application can act as if it were the user and perform operations (such as reading and sending emails) on their behalf.
   
   
3. Example Use Cases for Application Impersonation: 

• Backup and restore applications: The service can impersonate users to back up their emails and restore them later. 
• Email migration tools: During migrations, applications can access mailboxes to transfer emails from one system to another. 
• Monitoring and compliance solutions: These services can monitor user mailboxes for compliance purposes (e.g., archiving, auditing).

Seems like a great way to give our apps the rights they need to function, right? Well, it was until it wasn’t. RBAC Application Impersonation no longer meets the needs of security-conscious organizations. Frankly, it’s unsafe. Organizations must transition to more secure, modern authentication methods like OAuth 2.0 and Microsoft Graph.

8 Reasons Driving Microsoft to Eliminate RBAC Application Impersonation from All Environments 

1. Security Vulnerabilities with Application Impersonation

   1. Over-Privileged Access: Application impersonation grants a service account or application the ability to fully impersonate users and access their mailboxes, which poses a significant security risk. If the impersonating account is compromised, it could lead to a Business Email Compromise situation with unauthorized access to all mailboxes. This access increases your attack surface.
   2. Broad Permissions: In many cases, applications using impersonation were granted wide-ranging permissions, often far beyond what was necessary for their function. This violates the principle of least privilege, which is a core security best practice.
   3. Lack of Granular Control: The RBAC Application Impersonation model lacks fine-grained control over the specific actions that can be performed on behalf of a user. It also makes it difficult to limit permissions based on specific operations (e.g., only reading emails, not sending).

2. Modern Authentication and OAuth 2.0 Adoption

   1. Move to OAuth 2.0: Microsoft is pushing organizations toward adopting OAuth 2.0, a more secure and modern authentication protocol. OAuth allows applications to request access tokens with specific scopes (permissions), minimizing exposure and reducing the risk of over-privileged access. 
   2. Token-Based Access: OAuth relies on token-based access, which improves security by allowing more granular permission assignment and better integration with security policies like Conditional Access and Multi-Factor Authentication (MFA).
   3. Scalability and Future-Proofing: OAuth 2.0 provides a more scalable and future-proof method for application authentication, making it easier to extend and manage as new security features are introduced (e.g., support for device-based policies or location-based access).

3. Enhanced Control and Security Features with Microsoft Graph API 

   1. Microsoft Graph API Integration: The deprecation of RBAC Application Impersonation is part of a broader effort to standardize and streamline API access via the Microsoft Graph API. Graph API provides more secure, fine-grained, modern methods to interact with Exchange Online and other Microsoft 365 services.
   2. Least Privilege Model: The Microsoft Graph API, combined with OAuth, follows the principle of least privilege, enabling IT admins to assign only the necessary permissions to an application, unlike RBAC Application Impersonation, which typically granted broader access than needed.
   3. Unified Access to Services: Microsoft Graph offers a unified endpoint to access multiple Microsoft 365 services beyond Exchange Online (e.g., OneDrive, Teams, SharePoint), simplifying development and improving integration across the suite.

4. Deprecation of Basic Authentication 

   1. Basic Authentication Retirement: Basic Authentication, which was commonly used alongside EWS and RBAC Application Impersonation, is being deprecated due to its inherent security weaknesses. Basic Auth requires passing credentials (username and password) with every request, which is less secure than token-based OAuth flows. With Basic Auth being deprecated, it no longer makes sense to support an impersonation model that relies heavily on it.
   2. Modern Authentication Push: Microsoft’s push for Modern Authentication (OAuth 2.0) across all services makes RBAC Application Impersonation less relevant, as more secure and manageable alternatives, such as delegated access and application-specific permissions, are available.

5. Compliance with Modern Security Standards 

   1. Zero Trust Security Model: Microsoft is promoting the adoption of the Zero Trust security model, which assumes that no user or service should automatically be trusted. Application impersonation, by design, allows broad access to user data without much visibility or control, which contradicts this model. OAuth 2.0, Conditional Access Policies, and other modern security practices provide more effective enforcement of the Zero Trust model. 
   2. Visibility and Auditing Improvements: Using OAuth tokens in modern applications provides better tracking and auditing capabilities, which are essential for compliance and security. OAuth offers more transparency into what operations are performed, by whom, and under what conditions.

6. Reducing Misuse and Misconfiguration 

   1. Risk of Misuse: Application impersonation can be misused or misconfigured to grant excessive access, often unintentionally leading to Business Email Compromise. For example, an administrator might accidentally allow an application to impersonate all users in an organization, creating a significant security vulnerability.
   2. Improving Manageability: By deprecating impersonation and shifting to Microsoft Graph and OAuth, organizations can enforce stricter access controls, ensuring that applications are granted only the minimal permissions required to perform specific tasks. 

7. Encouraging Best Practices for Application Development 

   1. Modern APIs and Development Standards: The deprecation of RBAC Application Impersonation is also a push toward modern development practices. Microsoft encourages developers to use Microsoft Graph, which aligns with best practices for secure cloud application development (and supports the 'Secure by Design' tenet of their Secure Future Initiative). The use of REST APIs and OAuth 2.0 improves both security and performance compared to legacy protocols like EWS that are often associated with RBAC Application Impersonation. 
   2. Support for Conditional Access and Policies: Modern APIs (such as Microsoft Graph) allow for integration with advanced security features like Conditional Access Policies, which RBAC Application Impersonation does not easily support.

8. Security Compliance Requirements 

   1. Compliance with Industry Standards: As Microsoft aligns with evolving industry standards for cloud security and compliance (such as GDPR, HIPAA, and others), deprecating legacy models like RBAC Application Impersonation ensures that Exchange Online and other services adhere to these stringent security and privacy requirements. 
   2. Better Reporting and Compliance Audits: Modern APIs provide better audit logs and tracking mechanisms, allowing organizations to meet regulatory compliance requirements and produce more detailed reports of data access and usage. 

So, what exactly are we supposed to do now?

Here’s my 10-step guide for moving away from RBAC Application Impersonation while enabling your Exchange Online applications to function as expected. 

1. Identify current apps using RBAC Application Impersonation 
2. Migrate to Microsoft Graph 
3. Use RBAC for Applications in Exchange Online 
4. Implement OAuth 2.0 
5. Review application permissions 
6. Engage with third-party vendors 
7. Train the IT team 
8. Monitor changes 
9. Prepare for Legacy Decommissioning 
10. Stay Informed 

1. Identify current apps using RBAC Application Impersonation & Risky EWS permissions

• Immediate Action: Perform a full audit of all applications using RBAC Application Impersonation.
• Plan:
  • Use ENow’s FREE AppGov Score to identify how many apps are considered 'BEC Risky Enterprise Applications' using EWS/RBAC Application Impersonation 
    • AppGov is a quick and easy way to quantify your exposure. If it identifies affected apps, use the free Graph-FindImpersonation script on GitHub to get detailed information for each app. The script is located at GitHub - jmartinmsft/Exchange-App-Usage-Reporting: PowerShell script to retrieve app registrations using selected API and find recent sign-in events. (BIG thanks to Jim Martin at Microsoft for this script!) 
    • If you're already an App Governance Accelerator client, you can use the BEC Risky Enterprise Applications report to investigate if these apps are being used and then utilize our automated workflows to contact the owner and/or disable the risky apps. 
  • Prioritize applications based on critical business functions.
  • Check the applications to ensure they can perform properly (reading mail, scheduling meetings, etc.) using the new methods.

2. Migrate to Microsoft Graph 

• Immediate Action: Start migrating to Microsoft Graph, which is Microsoft's recommended replacement for EWS and RBAC impersonation for accessing and managing mailboxes. 
• Benefits of Microsoft Graph API: 
  • Offers a more modern, secure, and unified approach to interacting with Microsoft 365 services. 
  • Provides fine-grained permissions using OAuth 2.0 and supports Delegated Permissions and Application Permissions for accessing user data. 
  • It enables access to Exchange and other Microsoft 365 services (OneDrive, Teams, SharePoint, etc.).
• Steps for Transition: 
  • Review your current applications and services that rely on RBAC impersonation and EWS. 
  • Update or rewrite scripts and applications to use Microsoft Graph for email, calendar, contact, and task management. 
  • Ensure that the necessary OAuth 2.0 authentication flows (Delegated or Application) are set up for service-to-service or user-level access.
• Example Graph API endpoints to use: 
  • Mail: GET https://graph.microsoft.com/v1.0/users/{userId}/messages 
  • Calendar: GET https://graph.microsoft.com/v1.0/users/{userId}/calendar/events 
  • Contacts: GET https://graph.microsoft.com/v1.0/users/{userId}/contacts 

3. Use RBAC for Applications in Exchange Online 

• Immediate Action: Identify legacy needs or specific use cases where Microsoft Graph isn’t an option. 
  
• Why RBAC for Applications? 

• • RBAC is designed to give fine-grained control over administrative permissions specific to Exchange Online. It allows administrators to assign very specific roles, such as the ability to manage user mailboxes, transport rules, or retention policies, which may not be fully covered or as easily configured in Microsoft Graph.
  • RBAC enables administrators to assign predefined Exchange roles to applications. These roles are well-established in the Exchange environment, allowing for predictable and familiar permission assignments for Exchange administrators. 
  • Many legacy apps and scripts are built around Exchange Online’s PowerShell-based RBAC model and Exchange Web Services (EWS). In these scenarios, switching to Microsoft Graph requires significant rewrites, so admins may find it more beneficial in the short term to use RBAC for Applications. However, keep in mind the EWS retirement date (October 1, 2026). 

4. Implement OAuth 2.0 Authentication 

• Immediate Action: For authentication, migrate to OAuth 2.0. Basic Authentication, which was often used alongside EWS, is also being deprecated. 
• Why OAuth 2.0 Matters: 
  • It enhances security by removing the need to pass credentials directly. 
  • It supports Conditional Access Policies, Multi-Factor Authentication (MFA), and other modern security features. 
  • OAuth allows you to grant applications specific permissions, reducing the risk of over-permissioned accounts.
• Setup: 
  • Register your applications in Entra ID. 
  • Use Application Permissions (for non-user interactive scenarios, such as backups or migrations) or Delegated Permissions (for user-interactive applications). 
  • Configure token-based authentication to replace older credential-based methods

5. Review Application Permissions 

• Immediate Action: As part of the transition to OAuth and Microsoft Graph, review the permissions assigned to applications to ensure they follow the Principle of Least Privilege. 
• Why This Is Important: 
  • Only grant the minimum permissions required for an application to perform its tasks. For example, if an application only needs read access to a mailbox, avoid assigning full control or write access. 
  • Use Entra ID Conditional Access Policies to enforce security controls, such as requiring MFA for high-risk operations. 

6. Engage Vendors and Update Third-Party Tools 

• Immediate Action: Contact third-party vendors whose products use RBAC impersonation or EWS to ensure they are transitioning to modern APIs and OAuth. 
• Steps: 
  • Request updates or patches from vendors for tools that rely on RBAC impersonation. 
  • Ensure that these tools will continue to function correctly after the deprecation by testing the updates. 

7. Train the IT Team 

• Immediate Action: Ensure that affected IT team members, including IT admins, developers, and helpdesk staff, are aware of the upcoming changes and are prepared for the transition. 
• Training: 
  • Provide training on Microsoft Graph and OAuth 2.0. 
  • Educate the team on how the new permission models work and how to manage access through Entra ID. 

8. Monitor and Adjust Access Controls 

• Immediate Action: Set up monitoring to track the usage of new OAuth-based and Graph-based solutions. 
• Why Monitoring Matters: 
  • Monitor application activity to ensure compliance and security. 
  • Use audit logs to detect any potential issues or misuse of permissions. 

9. Prepare for Legacy Decommissioning 

• Immediate Action: Identify and decommission any systems or scripts that cannot be easily transitioned or updated. 
• Steps: 
  • Plan a phased decommissioning approach for legacy systems that are still relying on RBAC impersonation and cannot be upgraded or replaced. 
  • Set firm deadlines and transition plans to avoid service disruption after the deprecation. 

10. Stay Informed 

• Immediate Action: Stay informed about Microsoft's announcements about the deprecation, changes to the timeline (unlikely), and new recommendations. 
• Resources: 
  • Regularly check Microsoft’s Message Center for updates. 
  • Follow the Microsoft 365 roadmap to anticipate any future changes related to API access or mailbox management. 
    
    

Save yourself loads of grief by watching out for these seven common pitfalls: 

• Not all third-party applications have Graph-compatible versions yet 
• Some vendors might need extra time to update their applications 
• Always check with vendors about their Graph migration timeline before starting your migration 

• Graph permissions work differently than RBAC Application Impersonation 
• You might need multiple Graph permissions to replicate what one RBAC role previously handled 
• Take time to map out exactly which Graph permissions each application needs 
• Watch for overly broad permission requests from applications 

• Not testing applications with a small user group first 
• Failing to test edge cases (like accessing shared mailboxes or handling delegation) 
• Not verifying that all features still work as expected after migration 

• Not properly implementing token refresh logic 
• Missing token expiration handling 
• Inadequate error-handling for authentication failures 
• Not accounting for token size limits in applications 

• Starting too late and rushing the migration 
• Not accounting for dependencies between applications 
• Failing to build in buffer time for unexpected issues 
• Not coordinating with change management windows 

• Missing legacy scripts that use RBAC Application Impersonation 
• Overlooking departmental or shadow IT applications 
• Not identifying all service accounts with impersonation rights 

• Not informing end users about potential service impacts 
• Missing key stakeholders in the migration planning 
• Poor coordination with security and compliance teams 
• Inadequate documentation of changes for support teams 

The deprecation of RBAC Application Impersonation represents a significant shift in how applications interact with Exchange Online. While this change may seem daunting, it's ultimately about improving security and aligning with modern authentication standards. By following the 10-step plan outlined above and keep an eye on the pitfalls, you can ensure a smooth transition while setting your organization up for a more secure future. Remember, this isn't just about compliance - it's an opportunity to modernize your applications and strengthen your security posture. Start your migration to Microsoft Graph and OAuth 2.0 today. Don't hesitate to use tools like ENow's App Governance Accelerator and the Graph-FindImpersonation script to help you along the way. 

The clock is ticking, but with proper planning and execution, you've got this. Your future self (and your organization's security team) will thank you! 

Have Questions?

Do you have additional questions on the EWS/Application Impersonation retirement and impact to your applications? Head over to our Application Governance Forum to ask experts, like John, for their advice!