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 likely cause is not the tool: EWS is being switched off tenant by tenant, and this tenant's turn came.
- Never opted inA tenant that never explicitly set
EwsEnabledto$truehas it changed to$falseon October 1, 2026. - True, no listA tenant set to
Truewith no allow list no longer gets unrestricted access from October 2026 — only allow-listed application IDs can call EWS. - F1 · F3 · KioskA second, separate cause with the same 403: EWS requests from F1, F3 and Kiosk-licensed mailboxes have been returning HTTP 403 since March 1, 2026. If only some mailboxes fail, check their licences first.
- → Apr 1Allow-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 — a tool with no non-EWS path by then is a replacement decision, not a configuration one.
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs | deadlinescan tenant
Then, separately, ask each vendor for their EWS position. The allow list in detail.
A finding count of zero means no affected call sites were FOUND — not that you're unaffected.
Scan your code
Third-party tools are the visible half. The other half is the PowerShell script on a scheduled task and the service nobody has opened in four years.
Get the scannerGet the scanner: email [email protected] and you'll get the source and a Windows binary by reply — the public repository is being prepared.
backup
archiving
signatures
ticketing
CRM
Microsoft first-party apps
From your tenant's usage reporting, not from memory. A telemetry-built or hand-written list misses the job that runs monthly.
Set the allow list →