Exchange Online EWS Disabled: Fix Outlook Password Prompts Before the April 2027 Deadline

Why EWS-dependent apps are failing now​

The shutdown has been announced for years. Microsoft's Exchange Online deprecation page on Microsoft Learn says EWS "starts to be disabled globally for all organizations in October 2026" and "is fully disabled in April 2027". EWS stopped getting new features in 2018. The October 2026 disable date was set in 2023. According to that same page, the Midnight Blizzard incident in January 2024 involved EWS and pushed Microsoft to widen the retirement to its own apps as well as third-party ones.

Microsoft's Message Center post MC1227454 described the mechanism. Beginning October 1, 2026, EWS will be blocked unless the tenant configures an AppID AllowList and sets EWSEnabled=True. Without admin action, Microsoft will set EWSEnabled=False and EWS apps will stop working. Tenant admins will be able to re-enable EWS if necessary.

So if your tenant missed the August preparation window, the outage you're seeing is the planned change, not a bug.

The scope is narrower than the panic suggests. Microsoft's 2023 developer announcement said the retirement covers only Microsoft 365 and Exchange Online, in all cloud environments. EWS in on-premises Exchange Server is unchanged.

Section summary: The October 2026 phase has started. Tenants that never set EWSEnabled are being switched to False, and apps that rely on EWS stop working.

Symptoms: what users and admins will see​

Neowin lists Apple Mail, classic Outlook, Outlook desktop add-ins and third-party vendor software as examples of applications that can use EWS. When it's switched off, users may see:

• Error messages saying the EWS protocol has been disabled
• The affected app asking for credentials over and over

Don't assume every one of those products fails in every configuration. Whether Apple Mail or a particular add-in breaks depends on whether that specific setup actually uses EWS. Check before you blame the retirement. Microsoft recommends its EWS Usage Reports and the EWS Analyzer tool for finding active usage.

On the Microsoft 365 Apps side, the Baseline Security Mode documentation says EWS is still used by some first-party Outlook and web add-in features. It says to make sure Win32 Microsoft 365 Apps are on build 16.0.19725 or later before EWS is disabled, so Office add-ins aren't disrupted.

Step 1: Check Message Center​

Microsoft's first instruction, as Neowin reports it, is to look in the Microsoft 365 Message Center for an advisory saying EWS has been turned off in your tenant. That tells you the problem is the planned disablement and not an authentication fault, a broken app update or a Conditional Access change. If you find it, you have two ways to recover.

Option A: The Microsoft 365 admin center​

Microsoft's Baseline Security Mode documentation gives this route to the settings page:

1. Sign in to the Microsoft 365 admin center.
2. In the left navigation, select ... Show all, then expand Settings.
3. Select Org Settings.
4. Open the Security and Privacy tab.
5. Select Baseline Security Mode.

Next comes the advisory's procedure as Neowin describes it. I couldn't find the advisory itself to confirm it:

1. Find Block access to Exchange Web Services.
2. Clear Block your entire organization from using EWS and apply the change.
3. Select the same radio button again and apply the change once more.

The deselect, apply, reselect, apply sequence looks odd. Follow it as written. According to Neowin, Microsoft says the change can take one to four hours to apply, so don't panic if nothing happens immediately.

To change Baseline Security Mode settings you need the right workload admin role. For Exchange settings that's Exchange Administrator.

Option B: Exchange Online PowerShell​

This is the more precise route. Connect with the Exchange Online PowerShell module and check the current state:

Get-OrganizationConfig | Fl EWSEnabled

If it shows EWS as disabled, the reported guidance is to run:

Set-OrganizationConfig -EWSEnabled $true

A catch with $true​

This is the part a quick fix can miss. EWSEnabled has three possible values. Microsoft documents three possible values for this setting: $true = EWS enabled, $false = EWS disabled, $null = default value; currently treated as enabled

Under the retirement plan, $true is tied to the application allow list. O365HQ's status tracker reports that tenants that set it to true need the application ID allow list. Its timeline also says that from October 10, 2026, the application ID allow list is enforced in the worldwide cloud for tenants that kept EwsEnabled set to true.

In practice:

• If you know which apps need EWS, set $true and list those app IDs. ShareGate's documentation shows the pattern with its own app ID: Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "<AppID>". Put in the IDs for your own applications. This is the tightest option.
• If you need everything back while you investigate, ShareGate says that after Microsoft flips the value, to re-enable EWS after that, run Set-OrganizationConfig -EWSEnabled $null. Setting the value back to $null restores the same unrestricted access you had before October 1, 2026. SyncPenguin describes the same $null approach and adds that there will be a brief service interruption while the change takes effect, but re-enablement remains available until April 1st, 2027.

If you set $true and some apps still fail, check the allow list before you open a support ticket.

Check the mailbox level too​

Fixing the organization setting isn't always enough. SyncPenguin notes that Exchange Online will only allow a mailbox to use EWS if both the organization and mailbox settings are true. If one user is still broken after the tenant fix, look at whether their mailbox has its own EWS block.

Licensing can also get in the way. ShareGate says Kiosk, F1 and F3 mailboxes never included EWS access rights, and starting October 1, 2026, Microsoft will begin enforcing that restriction regardless of your tenant's allow list status. Frontline workers on those licenses won't get EWS back from either toggle.

Section summary: PowerShell is the more precise fix. Use $true with an allow list if you can, use $null for broad temporary access, and check mailbox settings and licensing when a single user is still affected.

The deadline: April 2027​

Microsoft stresses that every one of these workarounds expires. Mimecast's support documentation puts it plainly: re-enablement remains available up until April 1st, 2027. After that date, EWS is permanently shut down for Exchange Online with no exceptions and no further re-enablement.

That leaves a little over five months. Use them for a migration plan:

1. Inventory. Run the EWS Usage Reports so you know which apps and accounts are still making EWS calls.
2. Sort by owner. For internal code, Microsoft recommends its EWS Analyzer and an AI-assisted refactoring tutorial for moving to Microsoft Graph. For vendor software, ask the vendor for a Graph-based release date in writing.
3. Check parity gaps. Microsoft's roadmap lists Graph features still to come, including archive import/export and In-Place Archive access (Q4 2026) and contact lists and notes (Q3 2026). Microsoft says those dates are targets and may change. It also says generic public folder CRUD, generic Microsoft 365 Group mailbox CRUD and legacy Discovery Mailbox access will never be added to Graph. If you depend on any of those, you need a different design, not a wait.
4. Don't forget hidden dependencies. Microsoft's Baseline Security Mode documentation lists features affected when its EWS-related controls are on. They include the Exchange connector in Excel, Power BI, Microsoft Fabric and Power Platform Dataflows, cross-tenant free/busy and MailTips, and server-side sync between on-premises Dynamics and Exchange Online.

What this means for admins​

Is it fair for Microsoft to break apps first and publish recovery steps afterwards? Microsoft would say the warnings were clear: a 2023 announcement, Message Center posts, usage reports and an August opt-in window. Admins whose vendors haven't shipped Graph versions, or whose workloads sit in the parity gaps, have a reasonable complaint that the replacement wasn't finished before the old API was switched off.

Both points hold. The security argument for retiring EWS is real, since it gives broad API access to mail, calendars and contacts and was involved in a nation-state intrusion. The re-enable switch is a short reprieve, not a fix. If you're toggling EWS back on this week, also put the Graph migration in your project plan this week. In April 2027 the switch goes away.