Skip to main content

        Microsoft starts blocking EWS in Exchange Online on October 1. In this post, I go over what VB365 still uses EWS for, why it needs to stay enabled, and what the move to Graph will bring later.

Preparing Veeam Backup for Microsoft 365 for the EWS Retirement

Microsoft starts blocking EWS in Exchange Online on October 1. In this post, I go over what VB365 still uses EWS for, why it needs to stay enabled, and what the move to Graph will bring later.

The end of EWS (Exchange Web Services) in Exchange Online is almost here! Microsoft stopped adding features to EWS back in 2018, and starting October 1, 2026, they will begin blocking it tenant by tenant, with a hard stop on April 1, 2027. If you run Veeam Backup for Microsoft 365 (VB365), this is a big deal, since EWS is still how Exchange Online mailboxes get backed up.

Veeam already has the step-by-step in KB4820 , so please go check it out for the official information and the immediate action you need to take.

What Does VB365 Use EWS For?

Today, Exchange Online mailbox data still moves over EWS, and in the VB365 ports documentation , you’ll see that 443 to outlook.office365.com is listed as “required to connect to Microsoft Exchange Online through EWS.” The permissions page shows where it gets used.

For backup, VB365 uses the full_access_as_app Exchange permission to read mailbox content. Restores with an application certificate use full_access_as_app as well, which covers Veeam Explorer with cert auth, the Restore Portal, REST, and PowerShell.

Restores with device code in Veeam Explorer for Exchange use EWS.AccessAsUser.All plus the ApplicationImpersonation role. Microsoft deprecated that role, so certificate-based restore is the way to go - see KB4708 .

Public folder and discovery search mailboxes also need Exchange.ManageAsApp and the Global Reader role so VB365 can use Exchange Online PowerShell, and that same combo also lets VB365 identify shared mailboxes correctly.

Thankfully, directory lookups, SharePoint and OneDrive discovery, and Teams channel posts already run through Graph.

From v7 to 8.6

In v7, the Graph Teams Export APIs were opt-in (KB4340 ), and v8 made them the only option, along with modern app-only auth for new organizations. I covered that upgrade in Upgrade Veeam backup for M365 from v7 to v8 . Then per KB4873 , 8.5 added the new Graph permission requirements “to support Exchange mailbox protection after EWS retirement.” However, mailbox backup still uses EWS, and KB4820 says a later release will complete the move to Graph, so we will need to upgrade again. Either way, I would strongly recommend getting to 8.6.0.1102 now, since it assigns those Graph permissions automatically when you add or edit an organization, per KB4913 .

What Changes on October 1?

Microsoft controls this with two tenant settings. The first is EwsEnabled, which can be True, False, or Null, and Null is the default. The second is EWSAllowedAppIDs, a new allow list of Entra application IDs.

Microsoft’s Exchange team post and the EWSAllowedAppIDs announcement list what happens once the rollout reaches a tenant:

  • Null gets flipped to False, which blocks EWS for every app
  • True with an empty list also blocks everything (before October, this combination meant “allow all”)
  • True with a populated list only lets in the apps on the list

Then on April 1, 2027, EWS is completely gone, and admins can no longer change the setting. Microsoft’s FAQ says: “There will be no exceptions past April 2027.”

Microsoft also documents setting EwsEnabled back to Null to re-enable EWS without an allow list, but I would stick with the KB4820 approach of True plus the allow list.

So, why does EWS need to stay on at all? Well, in KB4820 it says that Graph does not have everything VB365 needs yet, specifically the delta sync support that incremental backups depend on, and until that gap is closed, EWS has to stay reachable.

Microsoft’s own parity gap roadmap lists several more gaps. Import and export for archive, public folder, and Microsoft 365 Group mailboxes is targeted for Q4 CY2026, and so is item access for In-Place Archives. Quite a lot of important things! So it’s surprising that they are proceeding with depreciation before having replacements available.

If a tenant still has EWS blocked when the rollout reaches it, mailbox backups will fail. Once it is fixed, the first run is a full sync, and there will be a gap in coverage, but KB4820 covers how to recover from that.

Why Move to Graph?

The first thing Graph improves is least privilege. Microsoft describes app-level EWS access as “full access to all mailboxes” in their RBAC for Applications documentation . The Graph permissions split backup (MailboxItem.Export.All and MailboxFolder.Read.All) from restore (MailboxItem.ImportExport.All and MailboxFolder.ReadWrite.All), per the VB365 permissions page . Veeam has also said on the R&D forums that the next release will assign separate backup and restore permissions automatically. I think security teams will like that.

Graph’s granular permissions also line up with RBAC for Applications, which can limit app roles to a management scope or an administrative unit once the unscoped Entra consent is removed. This is a Microsoft feature and separate from VB365, but it does show where app permissions are heading.

Graph is not without limits, though. Microsoft’s throttling limits cap each app and mailbox pair at 4 concurrent requests, 10,000 requests per 10 minutes, and 150 MB of uploads per 5 minutes.

What’s Next?

In the meantime, be sure to get to 8.6 and set EwsEnabled to True. Then put your Veeam app IDs on the allow list before October 1. KB4820 has all the details. I will write a follow-up once the Graph-based release is out. If you have questions about your own tenant, feel free to reach out!