Your archive is where a credit union, bank, or mortgage company keeps the correspondence it is required to keep, and where someone goes when an examiner or a borrower asks for a loan file from four years ago. Microsoft began the deprecation of Exchange Web Services in Exchange Online on October 1, 2026. From October 10, in Microsoft's worldwide cloud, a tenant that keeps EWS switched on has to name every application allowed to use it, and for tenants that never built that list Microsoft writes one from the last 60 days of activity. A retention export that runs quarterly, or a legal hold sweep that runs once a year, can fall outside that window. This page shows how to find the archive jobs at risk, how to keep them running while they move off EWS, and what the April 2027 shutdown still requires.
Microsoft started the deprecation of Exchange Web Services in Exchange Online, and it published the order the next steps run in.
Exchange Web Services is the older programming interface that applications use to read and write mailbox data in Exchange Online. Backup products use it. Archiving and journaling products use it. Records management and legal hold tools use it. So do a great many small internal scripts that somebody wrote once and nobody has opened since.
On this page, archive mailbox means Microsoft's Exchange Online archive: the In-Place Archive attached to a mailbox, including any auxiliary archives that auto-expanding archiving creates. An institution's records estate can be wider than that, so treat an affected application as a reason to check the records it handles.
On October 1, Microsoft's Exchange Team put the start in one line:
“The deprecation of EWS in Exchange Online starts today.”
The same post sets out what happens next in Microsoft's worldwide (multi-tenant) cloud. Read it as a sequence, because each step depends on how your tenant was configured before it.
| When | What Microsoft does | What it means for you |
|---|---|---|
| October 2, end of day Pacific | Records every tenant that has EWSEnabled set to True and no EWSAllowedAppIDs list. | From then on, an administrator who sets EWSEnabled to True populates the allow list as well. |
| October 8 to 9, end of day Pacific | Creates an EWSAllowedAppIDs list for each tenant recorded on October 2, populated with the EWS application IDs used in the previous 60 days. | Read the list Microsoft wrote. Jobs that run less often than every 60 days may be missing from it. |
| Starting October 10 | Turns on the cloud setting that requires an allow list whenever EWSEnabled is True, in the worldwide cloud first. | Only applications on the list keep EWS access. |
| After that change, tenant by tenant | Switches EWS off in tenants whose EWSEnabled is still not set, with a 7-day warning in Message Center when a tenant is selected. Shortly before, Microsoft populates a list from 60 days of use if none exists. | Watch Message Center. If a workflow still needs EWS after the switch, set EWSEnabled back to True. |
| April 1, 2027 | Disables EWS fully and permanently, and removes the ability to control EWSEnabled from tenant admins. | From this date, every EWS call to Exchange Online is refused. |
Government cloud tenants follow their own schedule. Microsoft says the behavior change starts in the worldwide cloud and that tenants in other clouds get timelines specific to them through Message Center.
How to read October 1. The first enforced change lands on October 10, and it applies to tenants that switched EWS on. A tenant that never touched the setting gets a 7-day Message Center warning before Microsoft switches EWS off there. Microsoft's own sequence is the one to plan against, which is why the useful question this week is which state your tenant is in. The next section shows how to read it in two commands.
The same retirement page on Microsoft Learn still frames the whole program in two dates: “October 2026: EWS starts to be disabled globally for all organizations” and “April 2027: EWS is fully disabled.” It also explains why Microsoft is doing this: “The Midnight Blizzard security incident in January 2024 involved EWS and elevated the urgency of the EWS deprecation effort.”
Microsoft Learn, Deprecation of Exchange Web Services in Exchange Online. Retrieved October 3, 2026.Two settings decide what happens to every EWS call in your tenant: EWSEnabled and the EWSAllowedAppIDs allow list.
An Exchange Online administrator can read both in Exchange Online PowerShell. These are the commands Microsoft uses in its own field guide to the allow list:
Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDsThe commands show your current values, and the table below reads them. The history behind them, such as who wrote a list and whether your tenant was in Microsoft's October 2 record, comes from your own change records.
| EWSEnabled | Allow list | What happens | What to do |
|---|---|---|---|
| True | A list is present | From October 10, only the applications on the list reach EWS. A list your administrator wrote stays exactly as written. A list Microsoft wrote on October 8 to 9 comes from 60 days of use. | Read the list. Confirm that each archive, retention, backup and eDiscovery application that still needs EWS is on it, with its end date recorded in your exception log, including jobs that run less often than every 60 days. |
| True | No list | From October 10, an allow list is required wherever EWSEnabled is True. Microsoft writes one on October 8 to 9 for tenants it recorded on October 2; a tenant that set True after that date writes its own. | Write the complete list now, or confirm that Microsoft's list appears and then read it. |
| Not set (Null) | Any | Microsoft selects tenants in phases, posts a 7-day Message Center warning, writes a list from 60 days of use if none exists, then sets EWSEnabled to False. | Decide now, application by application: a supported replacement, a rebuild, retirement, or an approved temporary entry with EWSEnabled set to True and a complete list you wrote. |
| False | Any | Every EWS call is refused. | Confirm the setting is unintended and the workflow still needs EWS, then set EWSEnabled to True with a complete allow list as an approved temporary exception, and plan its replacement. |
These settings decide which applications may call EWS. Whether an application then works still depends on its own sign-in, permissions and code.
Two timing details matter when you act on this. Microsoft says a change to the allow list takes about 24 hours to take effect, and a change to EWSEnabled typically takes under an hour and can take up to four. And the allow list is, in Microsoft's words, “a replacement list.” The command writes the complete list each time, so an update that names one new application has to carry every existing entry with it.
Microsoft Exchange Team Blog, October 1, 2026; Microsoft 365 Message Center notice MC1485116, October 1, 2026.EWSAllowList is a different setting. The older EWSAllowList and EWSBlockList settings belong to EwsApplicationAccessPolicy, filter requests by user agent, and can affect REST traffic as well. Microsoft's notice is explicit that “EWSAllowList is unrelated to EWS retirement and does not replace EWSAllowedAppIDs.” The setting that governs the retirement is EWSAllowedAppIDs, which lists application IDs.
Because the jobs that touch an archive tend to run on a calendar, and the list Microsoft writes comes from a 60-day window.
Microsoft is direct about the limits of the lists it writes. Its October notice says “Infrequently used applications may not be identified.” An earlier notice adds that its lists “may omit applications that run infrequently and may include applications that no longer require EWS access.”
Microsoft 365 Message Center notices MC1485116, October 1, 2026, and MC1469960, updated September 18, 2026. Message Center notices are delivered to each tenant; check them against your own Message Center.Now picture the archive side of a credit union, bank, or mortgage company. A quarterly retention export. A month-end journaling reconciliation. A year-end sweep that confirms legal holds. An eDiscovery search that runs only when counsel asks for one. A job on a cycle longer than 60 days can run entirely outside the window Microsoft reads. If its application ID made no other EWS call inside that window, nothing puts it on the list.
Microsoft's notice on archive mailboxes names the kinds of software it expects to be affected: eDiscovery solutions, compliance and records management workflows, data lifecycle management solutions, backup and export tools, and custom applications that access archive mailboxes. Its consequence is one sentence:
“Applications and scripts that continue to use EWS for archive mailbox operations will stop functioning after EWS is disabled.”
The EWS usage report in the Microsoft 365 admin center shows, in Microsoft's description, “the successful-call volume for each SOAP action.” For each application it lists the application ID, the SOAP action, the call volume and the last activity date, and it filters to the last 7, 30 or 90 days. Microsoft also notes that “Usage data is collected and aggregated weekly, not daily. It can take up to 10 days for usage to show in the report.”
Microsoft Learn, Exchange Web Services (EWS) usage report. Retrieved October 3, 2026.That shapes how a blocked application looks. Because the report counts successful calls, an application whose calls are being refused shows up as a call volume that falls and a last activity date that stops advancing. So read the report twice: once for the applications that are still calling, and once for the ones that went quiet.
One archive arrangement has its own instruction from Microsoft. If your institution keeps mailboxes on an on-premises Exchange server and their archives in Exchange Online, the Exchange Team wrote on September 30 that “the scenario where on-premises mailboxes have archive mailboxes in Exchange Online is not fully supported yet,” and added: “We expect this to be enabled in following months.”
Until then, Microsoft's instruction for that scenario is to keep EWS working: keep EWS permissions on the Exchange SE servers for now, set the tenant's EWSEnabled to True, and add the dedicated Exchange hybrid application to the allow list. Hybrid organizations that host no mailboxes on-premises, and on-premises mailboxes that do not use online archiving, are outside this case.
Microsoft Exchange Team Blog, Impact of Exchange Online EWS Deprecation on Hybrid Rich Coexistence and Cross-org Sharing, September 30, 2026.
Five checks, in order. Before October 10 they help identify dependencies and reduce the risk of a break, and after it they help find one. The first two take minutes in PowerShell and the admin center.
Run the two commands above and save the output with the date. That gives you your current row of the table and a dated record of what the tenant allowed and when. Your change records add the history: who wrote the list, and when.
Export the EWS usage report for the last 90 days. An application that appears in the report and on the allow list keeps EWS access while EWSEnabled is True. An application that appears in the report and is missing from the list loses access once the October 10 requirement reaches your tenant, or once Microsoft switches EWS off in a tenant that never set it. Then look for applications whose last activity date stopped moving. Investigate each one against its expected run schedule and the report's reporting delay, then check the job's own logs.
A 90-day report is a list of what called recently, so build the job calendar beside it: the scheduled jobs inside each archiving, backup, retention and eDiscovery product, your application inventory, and a confirmation from each workflow owner. Keep three lists apart: dependencies the report shows, dependencies you found another way, and open items still waiting on an owner or a vendor.
For each archive, retention, backup and eDiscovery job, compare what the last run collected with what a normal run collects: item counts, export sizes, mailboxes processed. A job that authenticates, runs and records success while reaching less of the archive looks healthy on a status dashboard. Whether a given product fails loudly or quietly depends on that product, which makes this a test to run on each one.
Microsoft's field guide names the mistake it sees most often in this step: “Treating an OAuth, permission, consent, or credential failure as proof that EWSAllowedAppIDs blocked the request.” Rule those causes out first. The same guide gives a controlled before-and-after test for proving the allow list behaves as expected for one application, run in a test tenant where you can, with at least 24 hours after each change.
For anything you did not write, the answer has to come from the vendor. Four questions cover it. Does your product use Exchange Web Services today? Does it reach archive mailboxes or Discovery Mailboxes? What is your supported replacement for EWS, and on what date is it available to us? And if that replacement uses Microsoft Graph, does it handle the archive redirects Microsoft documents?
The last question earns its place. Microsoft documents that an auto-expanding archive can spread across a main archive and auxiliary archive mailboxes, that Graph can answer a request with an HTTP 308 redirect or an ErrorArchiveFolderMovedPermanently error pointing to where the content lives, and that “Well-known folder names aren't supported for archive mailboxes,” so archive folders are referenced by folder ID.
Microsoft Learn, Handle archive mailbox redirects. Retrieved October 3, 2026.Microsoft's own applications count too. Microsoft lists Outlook for Windows, classic Outlook for Mac, Excel Power Query, Power BI and Exchange Server hybrid scenarios among the sources of EWS traffic, and says these applications still need to be added to the allow list to keep working if they show up in the usage report. For Outlook for Windows it asks customers to be on the August 2026 build 16.0.20430.20092 or later, and it says new Outlook for Mac is unaffected.
Add the application to the allow list, give the change a day, and treat the result as a bridge to April 2027.
Null is a testing rollback. Microsoft's field guide uses EWSEnabled set to Null to make EWS unrestricted within about an hour during a test. Its October notice also says tenants with EWSEnabled not configured remain subject to the phased retirement and will have EWS disabled as part of that rollout. For a production tenant that needs EWS through the migration, Microsoft's stated path is True with a complete allow list.
One security detail for every entry you keep. Microsoft Learn states: “On October 15, 2026, Microsoft Defender for Cloud Apps will retire the Exchange Web Services (EWS)-based detections marked Retiring soon in this article.” The two are Suspicious OAuth app email activity through EWS API, and App with EWS application permissions accessing numerous emails. From that date they stop generating alerts, so an application kept on EWS through the allow list runs without those two checks. Keep the list short, and keep each entry's end date in your exception log.
Every one of these entries ends by the same date at the latest. Microsoft's February plan says that starting April 1, 2027, EWS will be fully and permanently disabled, that “The ability to control EWSEnabled will be removed from tenant admins,” and that “There will be no exceptions past April 2027.”
Microsoft Exchange Team Blog, Exchange Online EWS, Your Time is Almost Up, February 5, 2026, updated September 9, 2026.The mechanics of building and inventorying the allow list are the subject of our companion page on the EWS application allow list, and the deadline history is covered in our earlier article on the retirement. This page stays with the archive: which dependencies exist, how to keep them running, and where each one goes next.
A supported replacement path for every archive dependency you keep: a Microsoft Graph route where one exists, the Microsoft service Microsoft names where it points the work elsewhere, and a rebuild for the three capabilities it has ruled out.
The Graph replacement for archive mailbox access is the next date on the calendar. Message Center notice MC1469565 gives its rollout:
“General Availability (Worldwide): Beginning in late October 2026 and expected to complete by early November 2026”
The public Microsoft Learn roadmap targets the archive gaps for the same quarter, and sets expectations in one sentence: “Estimated availability dates are targets and might change.”
| Capability | What Microsoft says it covers | Target |
|---|---|---|
| In-Place Archive (Generic CRUD) | Access and manage mailbox items in an existing In-Place Archive. This capability doesn't create archive mailboxes. | Q4 CY2026 |
| Import-Export (Archive) | Export and import mailbox items in archive mailboxes in a full-fidelity format. | Q4 CY2026 |
| Import-Export (Public Folder) | Export and import public folder items in a full-fidelity format. This capability doesn't include public folder CRUD APIs. | Q4 CY2026 |
| Import-Export (Group) | Export and import items in Microsoft 365 Group mailboxes in a full-fidelity format. | Q4 CY2026 |
| Exchange Admin API | Manage selected Exchange recipient and mailbox settings, including folder permissions, through Exchange Admin APIs. | Q4 CY2026 |
| Sovereign Cloud availability | Make Exchange workload APIs required for EWS migration available in supported sovereign clouds. | Q4 CY2026 |
Read the first row carefully, because it carries a limit that matters for a migration plan. In-Place Archive generic access covers items in an existing archive, and Microsoft states that the capability doesn't create archive mailboxes. A process that provisions archives programmatically through EWS is a separate question from one that reads and writes the contents of an archive.
The Microsoft Graph documentation already reads as finished: its overview states that “These APIs support access to data in users' primary, shared, and archive mailboxes on Exchange Online.” General availability reaching your tenant is tracked separately, in the Message Center window above, so confirm it in your own tenant before a migration depends on it.
If the dependency is a backup product. The same Microsoft page carries an explicit limitation: “The mailbox import and export APIs in Microsoft Graph aren't designed for mailbox backup and restore.” Microsoft points backup and restore scenarios to Microsoft 365 Backup. So the right question for a backup vendor is where its product lands after EWS, which may be a different service from the import and export APIs.
Auto-expanding archives also get a higher ceiling this month. Microsoft is raising the limit for eligible licenses from 1.5 TB to 3 TB per mailbox, with rollout beginning in mid-October 2026 and expected to complete by late October 2026. Any Graph-based tool that reads an expanded archive has to follow the redirects described above.
Microsoft 365 Message Center notice MC1472592, updated September 28, 2026.Alongside the roadmap, Microsoft publishes a shorter table headed “Confirmed capabilities that won't be added”, with the instruction to “Plan migrations without a Graph equivalent for these capabilities.” For two of the three, Microsoft names where the work goes instead. What closes is the EWS route and the Graph route, so tooling that took those routes is rebuilt against a different surface.
The Discovery Mailbox row is the one to pause on in a regulated environment. Legacy Discovery Mailboxes are where older search and hold workflows put their results. A process that still reaches into one through EWS has no Graph equivalent coming, and rebuilding it on Purview eDiscovery is a different piece of work from swapping an interface.
And one sentence governs everything absent from the table. Microsoft puts it just above the roadmap:
“If an EWS capability isn't listed in this roadmap table, don't plan on a corresponding Microsoft Graph or Exchange Admin API capability being available before EWS is fully disabled.”
A format detail that surprises people. Microsoft describes the export format of the import and export APIs as “intentionally opaque” and “designed to preserve item fidelity rather than to serve as a general-purpose interchangeable format.” If a plan assumes a Graph export produces a portable archive that another system can read, test that assumption before it becomes a retention control.
That is the whole problem, and the first step is smaller than it sounds. We will read your tenant's EWS settings and allow list, compare them with the EWS usage your tenant is already reporting, flag the applications in that reporting that are missing from the list, list the scheduled jobs and products that still need an owner's or vendor's confirmation, and sort each dependency we find by whether it has a Graph route available now, targeted later, or ruled out. Usage reporting shows which applications call EWS, so a vendor product still needs that vendor's written confirmation, and we give you the questions to send.
Request your free security assessmentBecause in a regulated institution the archive holds records a retention schedule says you must produce.
At a credit union, bank, or mortgage company, the archive holds the correspondence a retention schedule says has to be kept, produced, and searchable. The tooling that reaches it is doing compliance work, whether or not anyone has ever described it that way. Three consequences follow.
A records retention schedule is a commitment to produce, on request, for a defined period. If a retention job loses EWS access in October and its Graph version arrives in November, the obligation still covers October. Microsoft's rollout leaves what you owe a regulator, an auditor, or opposing counsel exactly where it was. An affected application is a reason to test what it collected and to check the records it covers.
Consider an archiving job that can still authenticate and still run, but has lost its path into the archive. Depending on how it handles the error, it may write a smaller report, finish faster, and record a successful run. If your monitoring records only whether the job completed, a run like that looks healthy. The question to put to your own tooling is specific: if the archive call fails, does this product raise an alert, and who receives it?
Much of the archive tooling in a regulated institution belongs to a vendor: your core provider, your archiving vendor, your backup product, your eDiscovery platform. Each of them has its own migration timeline. The useful question is which of your vendors has moved, and what each of them says in writing.
An illustrative examiner question. Show us how you know your retention controls are working. An examiner can ask it without ever reading a Microsoft deprecation notice, and answering it means producing evidence that the tooling still collects what it should.
Productivity is the first thing people feel when this breaks, because somebody cannot find a file. Security follows, because a scramble to keep a legacy interface alive is how exceptions get written and never removed. Governance arrives last and stays longest, because that is the one that turns up in a report.
Five steps, each tied to a date Microsoft published.
If your institution also still runs an on-premises Exchange server for hybrid management, that server has its own separate set of dates worth checking in the same pass.
And if the inventory step is where this stalls, which is where it usually stalls, that is the part we will do for you.
ABT is a Tier 1 Microsoft Cloud Solution Provider, and we manage Microsoft 365 tenants for more than 750 financial institutions. The assessment starts with the question this page is about and includes a review of the wider tenant configuration.
You get it as a short written summary.
Request your free security assessmentABT also operates M365 Guardian, its managed security service for credit unions, banks, and mortgage companies.
Dates and capability descriptions on this page are quoted from Microsoft's own wording. Microsoft describes the roadmap dates as targets that might change, and this page repeats that qualification. Tenant-specific timing appears in each tenant's Message Center.
Where Microsoft points backup and restore once the import and export APIs are ruled out for it, and what the shared responsibility model leaves with you.
Read the article
Where Microsoft points legacy Discovery Mailbox workflows. The licensing rule reverses by tier, which catches institutions out when they plan the move.
Read the article
The companion habit. An allow list entry written to keep a legacy integration working is an exception too, and exceptions last until somebody removes them.
Read the articleTell us roughly how many mailboxes you run and which archiving, backup or eDiscovery products touch them. Our engineers will read your EWS settings and allow list, compare them with the Exchange Web Services usage your tenant already reports, and give you the applications the reporting shows missing from the list, the jobs still to confirm, and the vendor questions to send.
