In this post, we wanted to share a practical walk-through of discovering which Azure AD app registrations are still using Exchange Web Services (EWS), plus what the Kiosk/Frontline license changes mean as you plan your move to Microsoft Graph.
Microsoft has announced that Exchange Online EWS blocking with start on October 1, 2026. If you have line-of-business apps, third-party tools, or automation that still depends on EWS, you need two things: (1) an inventory of what’s using EWS today, and (2) a migration plan to supported alternatives – typically Microsoft Graph.
What’s changing (and why you should care now)
- EWS retirement in Exchange Online: Microsoft will start blocking EWS requests to Exchange Online on October 1, 2026. The guidance is to migrate integrations to Microsoft Graph.
- EWS access changes for Kiosk / Frontline licenses: Starting at the end of June 2026, Microsoft will start blocking EWS access for users without license rights to EWS (for example, certain Kiosk and Frontline Worker license types). This can cause EWS-based integrations for such licensed users to fail before the broader October retirement date.
Even if you plan to complete your Graph migration well ahead of October 2026, the end-of-June 2026 licensing-related blocks mean you should validate whether any users with those licenses assigned use EWS. That’s where the Exchange-App-Usage-Reporting script is useful: it helps you find app registrations with EWS permissions and correlate them with recent sign-in activity so you can prioritize remediation.
What the Exchange-App-Usage-Reporting script does
The script is designed to answer a practical question: Which Azure AD app registrations in my tenant have EWS permissions, and are they still being used? At a high level, it:
- Discovers application registrations that have permissions associated with Exchange/EWS-related access.
- Queries sign-in activity for those applications to determine active applications.
- Queries audit logs for EWS activity within the tenant.
- Outputs report files that you can sort and share with app owners.
- Outputs a user license report to help identify kiosk or frontline workers.
How the script complements the Microsoft 365 admin center EWS usage report
For customers in our WW service, the Microsoft 365 admin center EWS usage report is a great starting point because it summarizes EWS activity across your tenant and breaks down which EWS SOAP actions are being called and their volumes over time. That helps you quantify overall EWS dependency and spot the heaviest EWS workloads.
Where teams often get stuck is turning that usage signal into an actionable remediation plan (for example, identifying the exact Entra ID app registration/service principal, determining whether it is still actively used, and finding the people and mailboxes affected). Exchange-App-Usage-Reporting script is intended to bridge that gap by adding identity and operational context around EWS usage by:
- App registration and ownership context: identifies Entra ID app registrations/service principals with EWS-related permissions so you can immediately pivot from “an app is calling EWS” to “this is the app object to remediate,” then route it to the right owner/team.
- Recency and “is it still used?” signals: correlates apps to sign-in activity so you can prioritize the apps that are actively authenticating today versus stale registrations that may be safe to validate/decommission.
- Authentication + permission model visibility: helps you distinguish whether usage is tied to application permissions versus delegated patterns, which matters for choosing the right Microsoft Graph migration approach and designing least-privilege access.
- Mailbox population risk (Kiosk/Frontline): adds a user license report so you can quickly identify whether the EWS-dependent workflow touches mailboxes that may lose EWS access earlier (end of June 2026).
- Exportable, app-centric worklists: produces CSVs you can sort/share (for example, by last sign-in) to drive an engineering backlog: confirm owner, confirm scenario, map EWS operations to Graph endpoints, and track progress to zero.
In practice, use the admin center report to understand what EWS operations are happening and at what scale, then use this script to determine which app registrations are responsible, who owns them, whether they’re still active, and which mailbox/license populations are most likely to experience impact first.
Customers with tenants that are not in our WW cloud should rely heavily on the script as admin center reports are not available.
Step-by-step: run the script and generate the report
1) Download the code
The repository for this solution can be found here
Note: The following permissions are required for the application:
- AuditLogsQuery.ReadAll to query the audit logs for EWS activity
- Application.Read.All to locate app registrations
- AuditLogs.Read.All to query sign-in activity
- Directory.Read.All to query user license information
2) Get active applications
Open a PowerShell session and change to the folder where you downloaded the script. You may need to unblock the files (for example, by using Unblock-File) before execution. Run the script with the following example syntax:
.\Find-EwsUsage.ps1 -OutputPath C:\Temp\Output -OAuthCertificate 8865BEC624B02FA0DE9586D13186ABC8BE265917 -CertificateStore CurrentUser -OAuthClientId 7a305061-1343-49c3-a469-378de4dbd90d -OAuthTenantId 9101fc97-5be5-4438-a1d7-83e051e52057 -PermissionType Application -Operation GetEwsActivity
The output provides a list of applications with EWS permissions and the last sign-in for the associated service principal. A CSV file called App-SignInActivity-yyyyMMddhhmm will be created in the specified output path.
3) Get sign-in activity report for an application
Use the output from the previous step to get the sign-in activity for an application (you need to run this step for each application). Depending on the size of your tenant, you may also need to adjust the StartDate, EndDate, and have the Interval be 1 hour.
.\Find-EwsUsage.ps1 -OutputPath C:\Temp\Output -OAuthCertificate 8865BEC624B02FA0DE9586D13186ABC8BE265917 -CertificateStore CurrentUser -OAuthClientId 7a305061-1343-49c3-a469-378de4dbd90d -OAuthTenantId 9101fc97-5be5-4438-a1d7-83e051e52057 -PermissionType Application -Operation GetAppUsage -QueryType SignInLogs -Name TJM-EWS-SoftDelete-Script -AppId 86277a5c-d649-46fc-8bf6-48e2a684624b -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date).AddDays(-14) -Interval 8
The output provides a list of users that have signed into the application in the specified period requested. A CSV file called <AppId>-SignInEvents-yyyyMMddhhmm will be created in the specified output path.
4) Get user license information (Kiosk and Frontline identification)
For those organizations that have users with licenses that may be impacted by the upcoming enforcement in June, a report of user licenses can also be generated to help identify potential impact. The output from the previous step can be used to generate this license report. A single CSV file with the results from each application can also be merged into a single user license report.
.\Find-EwsUsage.ps1 -OutputPath C:\Temp\Output -OAuthCertificate 8865BEC624B02FA0DE9586D13186ABC8BE265917 -CertificateStore CurrentUser -OAuthClientId 7a305061-1343-49c3-a469-378de4dbd90d -OAuthTenantId 9101fc97-5be5-4438-a1d7-83e051e52057 -PermissionType Application -Operation GetUserLicenses -AppUsageSignInCsv C:\Temp\Output\86277a5c-d649-46fc-8bf6-48e2a684624b-SignInEvents-20260203122538.csv
How to interpret the output (and prioritize fixes)
Once you have the output files, sort by “last sign-in”. Apps with recent activity are your highest priority because they’re more likely to break production workloads when EWS is blocked. Apps with no sign-in data may be dormant, misconfigured, or retired—treat these as “needs validation,” not automatically “safe to ignore.”
- Identify the owner of each app registration (or the business system it belongs to).
- Confirm the workload: mailbox access patterns (read, send, calendar, contacts, etc.) and whether it uses application or delegated access.
- Check mailbox populations the app touches—especially if any are assigned Kiosk / Frontline licenses that may lose EWS access at the end of June 2026.
- Choose the migration target: Microsoft Graph API equivalents, supported Exchange Online features, or a vendor upgrade that removes EWS dependency.
Don’t miss the Kiosk / Frontline Worker EWS blocks (end of June 2026)
Recommended validation playbook:
- Use the script output to build a shortlist of actively used EWS-enabled apps.
- For each app, determine which mailboxes it accesses (application access policies, RBAC, service accounts, shared mailboxes, or user populations).
- Cross-check those mailboxes’ license assignments for Kiosk / Frontline SKUs that may not include EWS rights.
- Run a controlled test (non-production where possible) to confirm whether the integration depends on EWS for those mailboxes and whether the vendor has a Graph-based update available.
- Evaluate if adding a different type of license for specific users is needed (for example, adding an Exchange Online Plan 1 or 2, which can still use EWS until October deprecation.)
Remediation options (what to do when you find an EWS dependency)
- Upgrade or reconfigure the product: Many vendors have already moved to Microsoft Graph. Engage the vendor and request their Graph migration guidance and timelines.
- Refactor custom code: Map EWS operations (mail, calendar, contacts) to Microsoft Graph endpoints and re-test auth flows, throttling, and permissions. More information on mappings can be found here.
- Reduce blast radius: If an app truly must remain temporarily, scope it tightly using least-privilege permissions and (where applicable) scope the mailbox it has access to using RBAC—then treat it as a short-term exception with an expiration date.
Quick checklist
- Run Exchange-App-Usage-Reporting and identify apps with recent EWS sign-in activity.
- Track down app owners and document which mailboxes/workloads each app touches.
- Assess exposure to the end-of-June 2026 licensing-related EWS blocks (Kiosk/Frontline).
- Prioritize migrations to Microsoft Graph and validate functionality end-to-end.
- Re-run the report periodically to confirm EWS usage is trending to zero.
Jim Martin (Exchange)
