EWS shuts down in October, but your deadline is 31 August

There is one detail in the Exchange blog that turns every headline about the end of EWS on its head: from October onwards, leaving EwsEnabled set to True with an empty allow list stops meaning "allow everything" and starts meaning "block everything". Today is 1 August. If a single application in your Microsoft 365 tenant speaks EWS — a mail archiver, a CRM, the signature tool, a script somebody wrote in 2019 that still runs — your date is not 1 October. It is 31 August, and there are thirty days left.

Exchange Web Services is the SOAP API half the industry has used to talk to Exchange mailboxes for nearly twenty years. Microsoft announced its deprecation in July 2018, set the shutdown date in 2023 — October 2026 — and has been preparing for it ever since with tools, reports and notices. What almost nobody has read is the how: the shutdown does not arrive all at once, it arrives in the shape of an allowed-application list that somebody has to write. If you do not write it before the end of August, Microsoft writes it for you in September, based on whatever it has seen running in your tenant. And that is the difference between a decision and a photograph.

The calendar, no decoration

Two clarifications before anybody panics. First: this is Exchange Online, not Exchange Server. If you run Exchange on-premises, your EWS stays where it was. Second: the allow list is not a solution, it is a six-month extension. It runs from 1 October 2026 to 1 April 2027, and after that no switch will help. Everything you put on that list is still outstanding; the only thing that changes is the date by which you have to deal with it.

The empty-list trap

Today, a tenant with EwsEnabled set to True and no list lets everyone through. From October, that same pair of values blocks everyone. It is the kind of semantic flip that breaks nothing while nobody touches it and breaks everything the day it is applied, and it explains why the admin who "leaves it configured" in August without populating the list is locking themselves out with the best of intentions. You read it and write it like this, in Exchange Online PowerShell:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Set-OrganizationConfig -EwsEnabled $true `
  -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

Look closely at the second command, because there is a buried mine here: the parameter does not support incremental add or remove. Every write replaces the whole list. The day somebody has to add one more application — in October, in a hurry, probably over the phone — without having read the full value first, everything else goes with it. So this piece of work ends with the complete value stored somewhere your team can retrieve it, dated, with the name of whoever approved it, like any other setting that gets touched once a year.

Other controls have existed for years — EwsApplicationAccessPolicy with EwsAllowList and EwsBlockList — filtering by user agent string. They are still there, but it is worth knowing what they are: the user agent is a text field chosen by the client. As a descriptive label, useful. As an identity, worth exactly what it is worth. The Entra application ID is a different thing, and it is what will be enforced from October. And for mailboxes you know no integration should touch, there is the surgical cut: Set-CASMailbox -Identity mailbox@domain -EwsEnabled $false.

The real problem: you do not know who uses EWS

Writing the list takes one command. The hard part is knowing what to put in it. Microsoft shipped the EWS usage report in 2025, and it lives in the Microsoft 365 admin center under Reports → Usage → Exchange → EWS usage tab. It gives four columns: application ID, SOAP action executed, call volume and last activity date in UTC. You can filter by the last 7, 30 or 90 days. And it comes with two pieces of small print that change how you should read it: the data is aggregated weekly, not daily — so do not validate a change on Tuesday morning — and the filter does not reach past 90 days.

The report gives you GUIDs, not names. Resolving them is the tedious part: Microsoft's own are in the public first-party application list, and the rest come out of Entra ID enterprise applications. A Microsoft identifier is not automatically off the hook: Microsoft maintains a page — Baseline Security Mode Settings — listing which of its own products still require EWS, and that is where to look before writing off a first-party GUID. And one judgement of ours, stated as judgement: identifiers with low, regular volume deserve more attention than they get, because that pattern fits a scheduled automated process, and an automated process has nobody to complain the day it stops working.

Why the list Microsoft writes is not your list

Here we move into opinion, and we will say so plainly: what follows is our judgement, not Microsoft policy. September's automatic list is built from observed usage. Microsoft does not publish exactly which window it looks at, so we cannot give you that number; what we do know is what it means to build a list out of what ran. It is a photograph of what executed, not a decision about what should execute, and that fails in both directions.

By omission: the process that only runs at quarter close, the annual export of a mailbox to a file, the migration tool that wakes up when there is a migration and sleeps the rest of the year. If they did not run inside the observed window they are not in the photograph; and if they are not in the photograph, they will hardly be on the list. You will notice on the day they are due to run, which also tends to be a day with a financial close or an audit attached. Nobody connects an October failure to a list they did not write in August.

By over-inclusion, which is worse: the automatic list will allow whatever was running. Including that integration nobody remembers authorising, with application permissions over every mailbox, bought for a pilot that was abandoned. That access goes from being a loose end to sitting explicitly on an allow list approved by nobody. It is worth remembering where all this urgency comes from: the incident that accelerated the plan was exactly that, EWS access with broad permissions. The allow list is, in practice, a security exercise with the paperwork of a compatibility task, and it is the best excuse you will get this year to review which applications can read your company's mailboxes. That review is the one we argued for when writing about Entra retiring SMS as a second factor: vendor deadlines are annoying, but they are usually the only date that gets anyone to genuinely look at what is plugged in.

What Graph still does not cover (Microsoft says so)

"Migrate to Graph" is good advice until you open Microsoft's own roadmap and see the list of parity gaps still open. It is published, in their documentation, ordered by work priority:

• Mailbox import and export, in preview — with Microsoft 365 Group and public folder mailboxes excluded.
• Import and export of public folders.
• Import and export of Microsoft 365 Groups.
• In-place Archive.
• Event delta for recurring events.
• Sticky Notes CRUD.
• User configuration and administration APIs — accepted domains, distribution group membership, mailbox folder permissions, organisation config, among others — all in preview.

If your company still runs on public folders — and plenty of SMBs run on public folders even if their IT department would rather not bring it up — the calendar squeezes you harder than the allow list does. And there is one word in there that deserves its own paragraph: preview. In preview means it exists and it can change; building on it with the confidence of a production service is another matter. Planning a critical migration against a preview API is a legitimate decision, taken in writing and with a plan B. It is the same conversation we had about the end of support for SharePoint 2016 and 2019: the vendor's date is not negotiable, and your room for manoeuvre comes from having counted properly what you have before it arrives.

One note that helps set the right tone: on that same page, Microsoft says it is working to remove EWS dependencies from its own products, naming Outlook, Office, Teams and Dynamics 365. Eight years after the announcement. We bring it up to calibrate expectations, not to score a point: the vendor is being transparent and that deserves credit. If the people who wrote the API are taking eight years to get it out of their own stack, the question "do we use EWS?" is not answered from memory in a meeting but by opening the report.

The thirty days, divided up

August in Spain is an awkward month for asking anybody for anything, and that works against you in the one week where you need an outside party to reply. This is how we would divide the month:

• Week one — inventory. Open the usage report at 90 days and export it. One row per application ID, with its volume and last activity date. Do not decide anything yet: count. Microsoft packaged more tooling for this than most people use: there is an EWS code analyzer for your own in-house code, a usage reporting tool and a guide to identifying third-party applications.
• Week two — names and owners. Resolve every GUID to a name and to a responsible person. And send each vendor two specific questions: which application ID do you need to allow, and on what date does their product stop needing EWS. By email, so there is a record. This is the week that jams if it starts late.
• Week three — what the report does not show. Sit down with finance, with HR and with whoever owns legal archiving, and ask which processes touch mail every quarter, every six months or once a year. This is where the export nobody had mentioned turns up. Add backup and archiving tools, and admin scripts running under service accounts.
• Week four — write it and store it. Configure the full list, set EwsEnabled to True, and save the complete value in your documentation with a date and an approval. Add two calendar reminders: one in October to check nothing has fallen over, and another no later than January 2027 to review what is left to migrate before 1 April.

What we would not do

• Putting everything on the list "just in case". It is the obvious temptation and it turns a six-month extension into an excuse to do nothing until March. Every identifier that goes in should have a name, a reason and an exit date behind it.
• Accepting "we are working on it" as a vendor answer. That is not a date. If your supplier has no Graph support date in August 2026, that information is worth as much as the product itself and belongs in the next renewal conversation.
• Mistaking the list for the project. The list buys time until April 2027. The work is getting EWS out of your integrations, and that work has code, tests and a deployment window. If by October the only thing you have done is the list, the whole project is still ahead of you.
• Leaving it to September because "Microsoft does it for you". It does, and that is precisely what we want to avoid. Letting an automated process decide the security of your mailboxes based on what happened to run over the summer is exactly the kind of decision nobody later remembers making.

The link nobody owns

The interesting thing about this shutdown is where the blow lands: on the layer that almost never has a clear owner, integrations. Users will keep opening Outlook without noticing a thing. The connector between the ERP and email, the archiving tool, the room booking system, the process that pulls a PDF out of a shared mailbox and drops it in a folder. Things that have worked for years, appear on no org chart, and that you only remember when they stop working. At everyWAN we deploy and manage Microsoft 365 environments, and what we see over and over is an impeccable server inventory next to an integration inventory that does not exist. That is where we work on data and applications: putting a name and an owner on what connects to what, so a vendor calendar change arrives as a planned task. We are not tied to one vendor's platform, and there is no scare to cash in on here: what we can give you is the list, with its date.

One line to close on: 1 October is Microsoft's date; 31 August is yours. One is decided by the vendor and the other by you, and the difference between them is who writes the list of what can read your company's email.

Sources (verified): the full timeline (deprecation announced July 2018, disablement date set in 2023, the January 2024 Midnight Blizzard incident that raised urgency and widened scope to Microsoft's own applications, the 2025 tooling, global disablement from October 2026 and full shutdown in April 2027), the list of Graph parity gaps and the mention of Outlook, Office, Teams and Dynamics 365 all come from the Microsoft Learn page on EWS deprecation in Exchange Online. How the allow list works — EwsAllowedAppIDs, the flipped meaning of an empty list from October, the absence of incremental operations, the automatic population in September and the recommendation to have it configured before the end of August — comes from the Exchange blog announcement "Introducing EWSAllowedAppIDs" and from message MC1227454 in the Microsoft 365 message center (5 February 2026), which also confirms only Exchange Online is affected. The report columns, the 7/30/90-day filters and its weekly aggregation are in the EWS usage report documentation. The EwsEnabled, EwsAllowedAppIDs, EwsApplicationAccessPolicy, EwsAllowList and EwsBlockList parameters are in the Set-OrganizationConfig reference; Set-CASMailbox -EwsEnabled is in the Set-CASMailbox reference. One honest caveat: the -RetrieveEwsOperationAccessPolicy switch on Get-OrganizationConfig comes from the Exchange blog announcement and does not yet appear in the published cmdlet reference. Ours, not Microsoft's: the reading that the automatic list fails both by omission and by over-inclusion, the reading that identifiers with low, regular volume deserve priority attention, the four-week split, the warning about storing the complete list value, and everything under what we would not do.