deadlinescan

Backups and integrations failing with EWS access denied

A backup job, a signature deployment tool, or a CRM mail connector starts failing against Microsoft 365. Nothing on your side changed. The errors are HTTP 403s, or EWS access-denied faults, and they arrived on their own. The likely cause is not the tool: it is that EWS is being switched off tenant by tenant, and this tenant's turn came.

Typical shapes of the same failure:

HTTP 403 Forbidden
ErrorAccessDenied
The requested web method is unavailable to this caller or application

Why this happens without anyone changing anything

EWS: tenants that never opted in start getting disabled Oct 1, 2026 (includes Microsoft's own apps); allow-listed apps run until Mar 31, 2027; Apr 1, 2027 is final — no exceptions.

The retirement is enforced per tenant, not as one global switch, and it operates on two organisation-level settings rather than on anything inside your application. A tenant that never explicitly set EwsEnabled to $true has it changed to $false on October 1, 2026. A tenant set to True with no allow list no longer gets unrestricted access from October 2026 — only allow-listed application IDs can call EWS. Both changes land underneath a working integration and look exactly like a permissions bug in it.

Backup and integration vendors have published advisories describing the same thing: for some tenants EWS ended up blocked by default, and backup jobs that depended on it started failing. The symptom is generic because the cause is generic — the caller is being refused at the tenant boundary.

A second, separate cause produces the same 403 and is worth ruling out: EWS requests from F1, F3 and Kiosk-licensed mailboxes have been returning HTTP 403 since March 1, 2026 (reported by The Register, December 2025). If only some mailboxes fail, check their licences before you touch the tenant configuration.

What to do right now

First, read the posture rather than guessing at it. In an Exchange Online PowerShell session:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
  Format-List EwsEnabled, EwsAllowedAppIDs

If EWS still has to work while the affected tools are migrated or replaced, opt in and allow-list the application IDs that call it:

Set-OrganizationConfig -EwsEnabled:$true
Set-OrganizationConfig -EwsAllowedAppIDs "<comma-separated Entra app client IDs>"

Three things worth doing in the same maintenance window:

Then, separately, ask each vendor for their EWS position. Allow-listing keeps a tool alive until March 31, 2027 at the latest; April 1, 2027 is the hard shutdown with no exceptions and no re-enablement, and a tool that has no non-EWS path by then is a replacement decision, not a configuration one. The allow list in detail.

Then scan your own code

Third-party tools are the visible half. The other half is the code your organisation wrote itself: the PowerShell script on a scheduled task, the Python job, the internal service nobody has opened in four years. DeadlineScan is a free, MIT-licensed command-line scanner that finds those call sites and tells you what each one maps to. It makes no network calls and sends no telemetry, so your code never leaves the machine.

deadlinescan scan ./my-repo

Get the scanner: email hello@deadlinescan.com and you'll get the source and a Windows binary by reply — the public repository is being prepared.

A finding count of zero means no affected call sites were FOUND — not that you're unaffected.

Sources

Related