Table of Contents
Frontline Workers and Kiosk Accounts Cannot Use Outlook After June 2026
Following Microsoft’s December 2 announcement that they will terminate access to Exchange Web Services (EWS) for kiosk workers after the end of June 2026 (originally March 2026), I read a fair amount of totally bland commentary that lacks any insight because it simply repeats what Microsoft announced. Far too many people rush to comment without thinking about the context and technical underpinnings of what’s happening. Let’s try and put some flesh on the bones of this announcement.
As Microsoft notes, they’re in the middle of a plan to remove EWS completely from Microsoft 365. This will happen sometime in October 2026, and in the interim a Microsoft project team is tracking down all the places where EWS is used in products so that the usage can be terminated as quickly as possible. Recently, we’ve seen the roll-out of a new hybrid connectivity app to replace the use of EWS with Graph APIs for rich coexistence between Exchange Server on-premises mailboxes and cloud mailboxes.
We’ve also seen the launch of the Exchange Admin API, a short-term plaster to allow app developers to complete the migration of EWS-based apps like email clients to Graph APIs. I call the API a plaster because it’s simply a REST-based wrapper to allow the apps to run Exchange PowerShell cmdlets to access features where Graph APIs are unavailable. Other people have used less complimentary terms to describe the Exchange Admin API, but let’s be charitable. The API is there to do a short-term job.
Reviewing the Exchange Online Service Description
No job is done until the paperwork is complete. In this case, service descriptions and licenses must be adjusted because these form the legal basis of the delivery of services by Microsoft to its customers. In the course of a review to prepare for the termination of EWS, Microsoft discovered a lacuna (a lovely word) when they realized that the service description for Exchange Online excluded EWS application support for “kiosk” Microsoft 365 licenses, aka frontline F1 and F3 user licenses and the Exchange Online Kiosk license (Figure 1).
EWS application support includes using EWS to access Exchange content via third-party or home-grown apps. By now, those apps should be known and well on the way to being upgraded to use the Graph APIs. Users with frontline licenses don’t need anything else to access Exchange content via Graph APIs.
A Deliberate Exclusion for Frontline Workers
While it might seem odd to exclude frontline workers from using EWS, I think the exclusion in the service description is quite deliberate because frontline licenses were always intended to use browsers or mobile devices to access applications. In this light, no need exists to make EWS available to frontline users because they won’t use Outlook classic on either Windows or Mac (at one stage, Outlook for Mac was built using EWS).
But hold on, frontline Microsoft 365 licenses don’t come with Microsoft Apps for Enterprise (the subscription version of the Office desktop apps), but that doesn’t mean that someone with an F1 or F3 license couldn’t use a licensed copy of Outlook classic (perpetual) to access their mailbox and benefit from EWS.
Footnote 8 in the service description doesn’t mention frontline license holders when it lays out the requirement to connect to Exchange Online with Outlook (the text is a little mangled, but you can understand what it means):
“Connecting an Office 365 E1, Microsoft 365 Business Basic, Microsoft Exchange Online P1 or P2 to Outlook for Windows, classic Outlook for Windows, and Outlook for Mac requires that those applications first be licensed with an account that includes the rights to Microsoft 365 desktop apps.”
No Licensing Block to Stop F1 and F3 Accounts Using EWS
To control access to Exchange Online, Microsoft 365 products include an Exchange service plan. For example, Microsoft 365 F1 includes the Exchange Foundation (113feb6c-3fe4-4440-bddc-54d774bf0318) service plan while Microsoft 365 F3 includes the Exchange Online Kiosk (4a82b400-a79f-41a4-b4e2-e94f5787b113) service plan. See this page for details of service plans and products, or see this PDF for a functionality comparison. The Microsoft 365 F1 license doesn’t include full mailbox access. This product is intended to support Teams calendar access for apps like Shifts.
If an account has the Exchange kiosk service plan or above, it can connect to Exchange Online and use everything made available by the service plan. There’s never been a way to block a mail access protocol like EWS through licensing. Any blocks are implemented further up the stack. For example, by configuring the protocols that a mailbox can use with the Set-CASMailbox cmdlet.
In fact, Exchange Online updates the value of the EWSEnabled setting to $false if an F3 or Exchange Kiosk license is assigned to an account. However, an exception always existed to allow users with kiosk licenses to use EWS because of a dependency on some background apps. Those dependencies have now gone away, and that’s why Microsoft can now impose the block that licensing always said existed. Some ISVs took advantage of the loophole to backup these accounts using EWS, a practice long frowned upon by Microsoft. Those type of backups won’t be possible once the block comes in.
Clearing the Decks
The reason why Microsoft will block EWS access for frontline users starting March 1, 2026, is that Microsoft is clearing the decks to prepare for the final termination of EWS in October 2026. If your organization has frontline worker licenses, it’s a good idea to check if they access any EWS app: first or third-party or home-grown. Otherwise, those folks might get a shock in early March.
Learn about managing Exchange Online and the rest of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.
What i am curious about is I believe most backup SAAS products use EWS to backup Exchange. If that it is the case, I wonder how SAAS products (Datto / Kaseya, Cove, etc) will get around that to backup mailboxes.
I think it’s true to say that many backup products used EWS to access Exchange (and Teams compliance record) data. However, that was a legacy of the on-premises space where EWS was the only game in town. Modern backup products for Exchange Online should be off EWS by now and use the mailbox import/export Graph API, or have a solid plan to get off EWS before Microsoft retires EWS in October 2026. I can’t answer for all backup products, but I know that some are struggling to move from EWS.
The writing for EWS deprecation has been announced quite a while ago. Any self-respecting backup vendor should have started incorporating other APIs (eg Graph) in their Exchange Online backup products to extract or ingest data in mailboxes by now, in anticipation of the EWS termination in Exchange Online.
@Tony: I know how to find the Enterprise / registered apps that use EWS in our tenant. Is there a way to identity the mailboxes that these apps access via EWS?
I want to make sure that business processes incorporating F1/F3 user accounts are not interrupted by the EWS block coming (now) on June 30th, 2026.
Indeed you can. As explained in the Automating Microsoft 365 with PowerShell eBook, you can search the Entra ID sign-in audit log by app identifier.
$AppID = 'd3590ed6-52b3-4102-aeff-aad2292ab01c'[array]$SignIns = Get-mgauditlogsignin -Filter "AppId eq '$AppId'" -All
$SignIns | Select-Object CreatedDateTime, UserPrincipalname, ClientAppUsed
@Tony: Thanks. Unfortunately I cannot find any sign-ins for our tenant appids.
MS writes: “Sign-ins that are interactive in nature (where a username/password is passed as part of auth token) and successful federated sign-ins are currently included in the sign-in logs.”
My apps use client certificates for authentication. Maybe they are not “interactive”? What do you think?
If the connections are coming from apps, they won’t show up as interactive connections. Try this:
[array]$AuditRecords = Get-MgBetaAuditLogSignIn -Filter “(signInEventTypes/any(t:t eq ‘servicePrincipal’) and status/ErrorCode eq 0) and AppId eq ‘$AppId'” -All -Sort “createdDateTime DESC”