Know which applications still depend on EWS — and what to do about each one, tenant by tenant.
A fixed-scope, independent audit for Microsoft 365 service providers. It turns consented EWS evidence into a reviewable decision pack: what is actually calling EWS, how that compares to the current allow list, who owns each application, and what you would change — with every row traceable back to its source.
The dates that actually apply
Below is Microsoft’s published sequence, with the primary source for each step. It is an operational timeline, not a prediction about your estate: no one can tell you the day a specific tenant is switched.
A tenant that sets EwsEnabled to true and defines its own App ID allow list is excluded from the automatic switch. Microsoft's newest notices phrase this as “before 1 October”; the explicit end-of-August wording is in the Skype for Business hybrid guidance.
For tenants that have not configured a list, Microsoft plans to populate one based on observed usage. An administrator-created list is not planned to be changed. Reviewing whatever list results remains the administrator's responsibility.
Exchange Online begins gradually disabling EWS. Tenants without a timely explicit opt-in are progressively set to EwsEnabled = false. Access after that point depends on the allow list.
EWS in Exchange Online is disabled completely. Microsoft states no exceptions after this date, and EwsEnabled stops being a workaround.
Sources were last re-read on 7 August 2026. Microsoft has revised this guidance more than once, most recently to note that Organization Relationships traffic is not governed by the allow-list state. Every engagement re-reads the primary sources and your tenant’s Message Center before any recommendation is made. The full breakdown — state matrix, the September auto-population, how to read the usage report and the write trap that removes App IDs silently — is in the MSP guide, free and without a form.
The report tells you what happened. It does not tell you what to do.
Microsoft’s usage report and your existing inventory are both real inputs. Neither of them, alone, answers the question your client is going to ask.
Usage is not the same as permission
An application holding EWS permissions may never call EWS. An application calling EWS may not appear in the inventory you already keep. Deciding what to allow requires reconciling observed SOAP-action usage against the current configuration — two different sources, per tenant.
The allow list is written by full replacement
There is no documented incremental add or remove. Setting the list writes it whole, so any existing App ID missing from the new value is removed. A proposal therefore has to state the complete prospective set, the delta and the read-before-write precondition — not just the additions.
The bottleneck is ownership, not discovery
The hard part across dozens of tenants is not producing a list of GUIDs. It is knowing who owns each application, what happens if it stops working, who signs off on the change, and being able to show a client the evidence behind each decision.
Two scopes, and an honest boundary between them
The scope is decided before any file is accepted, because the two differ by one input — and that input is what separates an inventory from a proposal.
Usage inventory
What you supply
- One consented EWS Usage export per tenant, with a stated report window.
What you receive
- Normalised portfolio summary and per-tenant findings.
- Normalised application and SOAP-action usage, each row traceable to its source row.
- Keep / migrate / remove / investigate decision register with owner and target date.
- Unknown-evidence and unknown-owner queues, with the limitations stated explicitly.
- Deterministic run manifest: input hashes, artefact hashes and workbench version.
Full reconciliation
What you supply
- Everything above, plus a separately consented read-only snapshot of EwsEnabled, EwsAllowedAppIDs and the relevant current configuration.
What you receive
- Everything in Usage inventory.
- Current configuration compared against observed usage, per tenant.
- Enforcement-state modelling based on Microsoft's published behaviour, with the publication date recorded.
- Reviewable allow-list proposal: current set, prospective full set, delta, blockers, warnings and mandatory review preconditions.
- Explicit CANNOT_DETERMINE rows wherever the supplied evidence cannot support a safe decision.
Six steps, and you can stop at any of them
You receive artefacts, not a slide deck
Every machine-readable artefact is deterministic: the same inputs, the same recorded decisions and the same ruleset produce byte-identical output, so a re-run produces a diff you can actually review.
| Artefact | Format | What it contains |
|---|---|---|
| portfolio-summary.csv | CSV | One row per tenant: applications observed, decisions taken, unresolved items. |
| reconciliation-findings.csv | CSV | One row per tenant-application finding, with state, severity, explanation and evidence IDs. |
| decision-register.csv | CSV | The human decisions: keep / migrate / remove / investigate, owner, target date, review status. |
| configuration-proposal.csv | CSV | Review-only allow-list proposal: current set, prospective set, delta, preconditions. |
| unknown-owner-queue.csv | CSV | Applications observed with no identified owner — the queue that actually needs your people. |
| validation-report.json | JSON | What was accepted, what was rejected and why. Fails closed on ambiguous input. |
| run-manifest.json | JSON | SHA-256 of every input and every artefact, plus ruleset and workbench versions. |
| tenants/<tenant>/overview.html | HTML | Per-client evidence page, built only from that tenant's partition. |
A fictional sample is available before any of your data moves
A complete three-tenant evidence pack built from entirely fictional data — deliberately mixed states: active and known, active and unknown, allow-listed but not observed. Every identifier in it is synthetic. It is a demonstration of the output format and of the limitations wording; it is not a customer result and implies no customer relationship. Ask for it in your first message; it is sent as a link, not as an attachment.
Where your data goes, and where it does not
You are a service provider. Handing a third party access to dozens of client tenants is not a reasonable ask, so it is not the ask.
- No Microsoft 365 credentials, tokens or certificates are requested, held or accepted.
- Files are processed locally on a controlled workstation under a written consent and retention record.
- Your export is never uploaded to a hosted SaaS, a public repository, a CI system or an AI chat.
- The deliverable minimises identifiers and records unresolved evidence explicitly instead of guessing.
- Deletion is confirmed in writing at the end of the agreed retention window.
- No direct connection is made to your tenant, to Exchange, to Microsoft Graph or to any RMM/PSA system.
What this audit does not claim
Stated plainly, before you buy, because a decision pack whose limits are hidden is worth less than no decision pack at all.
- This is not a Microsoft product, and it is not endorsed by or affiliated with Microsoft.
- It does not guarantee that every EWS dependency in your estate has been found.
- It does not guarantee the prevention of any service interruption.
- It is not a Graph migration project, and it does not rewrite any application.
- It never modifies EwsEnabled, either allow list, a mailbox policy or any other tenant setting.
- A usage inventory alone cannot prove your current allow-list configuration.
- It does not accept “any CSV”. An unexpected or ambiguous input shape is rejected or re-scoped, not silently parsed.
- The absence of an application from a report window does not prove the absence of a dependency.
Fixed after intake, before any data is accepted
The band is agreed during the written scoping, once the portfolio and the available evidence are known. The final scope, delivery date and retention window are written into the order. Unexpected or ambiguous input is re-scoped or declined, not silently absorbed.
A bounded inventory with a limited number of tenants and applications.
A multi-tenant inventory, or a full reconciliation for a moderate portfolio.
A larger portfolio, or one with material evidence exceptions to work through.
Prices are exclusive of any applicable tax, which is stated on the order. Quotes and invoices can be issued in EUR, USD or GBP — the amount is fixed in the written quote, not at payment time. Invoicing is from a Polish sole proprietorship; see legal information.
Check the claims yourself
- Deprecation of Exchange Web Services in Exchange Online — Microsoft Learn
- Introducing EWSAllowedAppIDs — Exchange Team Blog
- Exchange Online EWS, Your Time is Almost Up — Exchange Team Blog
- Exchange Web Services (EWS) usage report — Microsoft Learn
- Prepare for EWS retirement (Skype for Business Server hybrid) — Microsoft Learn
Last re-read 7 August 2026. Microsoft may revise this guidance at any time; where this page and Microsoft’s current documentation disagree, Microsoft is correct and this page is out of date.