EWS allow-lists start October 10: six Azure, Entra and Microsoft 365 changes to act on (Sept 9 to Oct 9, 2026)

Between September 9 and October 9, 2026, Microsoft passed two Azure Functions retirement dates, started rolling out an application allow-list for Exchange Web Services, shipped an Entra Connect release and a hotfix for it, set March 31, 2027 as the start of stricter Exchange Online PowerShell sign-in, reissued the September Exchange Server security updates and made send-from-alias generally available. Two of those carry hard dates you may already be on the wrong side of. Per Microsoft's notice, a Functions v3 app on Linux Consumption that wasn't migrated should have stopped running after September 30, and from October 10 an EWS integration missing from a worldwide tenant's allow-list stands to lose access. The cost of ignoring either is a sync or connector that quietly stops doing its job. Anyone still running Exchange on-premises, hybrid servers included, also has a new CVE to patch.

Where each change stands as of October 9, 2026:

• Already past: Azure Functions v1 support ended September 14, and Microsoft's notice says v3 apps on Linux Consumption stop running after September 30.
• Rolling out now: EWS AppID allow-lists for worldwide Exchange Online tenants, with enforcement starting October 10.
• Released, plan the upgrade: Entra Connect 2.6.91.0 (September 16) and hotfix 2.6.92.0 (September 23).
• Future enforcement: stricter Exchange Online PowerShell logon checks planned from March 31, 2027.
• Available now: Exchange Server September 2026 V2 security updates, published October 2.
• Optional: send from alias in Exchange Online, generally available since October 7.

Exchange Online EWS: allow-list enforcement starts October 10

Microsoft's October 1 post on EWS deprecation lays out a phased rollout. There's no single shutdown day. For eligible tenants in the worldwide (WW) cloud, Microsoft scheduled automatic population of the AppID allow-list for October 8 and 9, end of day Pacific Time. Starting October 10, a WW tenant with EWSEnabled set to True requires EWSAllowedAppIDs. The app to worry about is the one that isn't on that list, like an old CRM connector or a reporting tool someone set up years ago and nobody has touched since.

1. Find what still uses EWS in your tenant. Then read the tenant's actual EWSEnabled and EWSAllowedAppIDs values instead of assuming the automatic population ran.
2. Go through every allowed application ID. Each one should map to an app you know and an owner who can vouch for it, and every EWS app you rely on should be there.
3. Make changes early. Microsoft says allow-list edits take 24 hours to apply, so an app you add after enforcement starts won't be covered until the next day.
4. Put each EWS-dependent app on a migration plan. The allow-list is one step in a phased deprecation, and moving off EWS is the lasting fix.

Tenants in other Microsoft clouds get their own timing through Message Center. Check yours there rather than borrowing the WW dates.

Azure Functions: v1 support ended September 14, and Microsoft's stop date for v3 on Linux Consumption was September 30

Both Functions dates in this window are already behind us. Support for the v1 runtime ended September 14, 2026. Microsoft's Azure Functions runtime versions page says function apps still running the end-of-life v3 runtime on Linux in a Consumption plan stop running after September 30, 2026. A timer-triggered function that stops doesn't put an error in front of anyone on the business side. The nightly export simply never arrives.

Inventory every function app for runtime major version, operating system and hosting plan. The runtime version is the FUNCTIONS_EXTENSION_VERSION app setting, and a kind value containing linux marks a Linux app.

az functionapp list --query "[].{app:name, group:resourceGroup, kind:kind}" -o table
az functionapp config appsettings list --name APP_NAME --resource-group RESOURCE_GROUP --query "[?name=='FUNCTIONS_EXTENSION_VERSION'].value" -o tsv

Anything returning ~1 or ~3 belongs on the v4 migration list, with Linux Consumption v3 apps at the top because, per Microsoft's notice, those should have stopped running after September 30. Confirm the hosting plan on each app's overview page in the portal.

Don't mix this up with retirement of the Linux Consumption plan itself, which Microsoft dates to September 30, 2028. That's a separate event two years out. This year's date applied to v3 apps running on that plan.

Entra Connect: take 2.6.92.0, the September 23 hotfix

Version 2.6.91.0 shipped September 16. It brings guided migration to Cloud Sync in the Azure public cloud, makes phishing-resistant authentication the default in the setup wizard and changes some configuration and automation behavior. A week later, on September 23, hotfix 2.6.92.0 followed with security fixes and a fix for a Pass-through Authentication agent-registration problem in 2.6.91.0. Plan this into a normal maintenance window.

1. Check the installed version on every Connect server, staging servers included.
2. Target 2.6.92.0 for the upgrade. A server already on 2.6.91.0 that uses PTA has the most reason to move.
3. Confirm whoever runs the wizard can sign in with a phishing-resistant method, since that's now the default.
4. Before upgrading, review any app-scoped Conditional Access policy that targets Microsoft.Azure.SyncFabric or Microsoft 365 Reporting Service.
5. After upgrading, confirm a clean synchronization cycle and check that PTA agents are registered and healthy.

The guided Cloud Sync migration is worth evaluating. It isn't something every tenant has to do now.

Exchange Online PowerShell: move to ExchangeOnlineManagement 3.10.1 before March 31, 2027

Microsoft's October 1 notice recommends ExchangeOnlineManagement 3.10.1 or newer for all customers. Stricter logon enforcement is planned to begin March 31, 2027, and older modules may fail in certain interactive scenarios after that, particularly PowerShell 7 with WAM disabled. Almost six months sounds like plenty. It goes faster once you count how many machines have a copy.

Inventory the module on admin workstations and automation hosts, upgrade it, then test sign-in the way each machine actually connects.

Get-Module ExchangeOnlineManagement -ListAvailable | Select-Object Name, Version, ModuleBase
Update-Module -Name ExchangeOnlineManagement

Update-Module handles copies installed from the PowerShell Gallery with Install-Module. Two pieces of good news from the notice: certificate-based automation isn't expected to be affected by this enforcement, and enabling WAM isn't required.

Exchange Server: September 2026 V2 security updates, published October 2

On October 2 Microsoft published V2 of the September 2026 Exchange Server security updates, adding CVE-2026-96940 to what the original September release covered. Exchange Online is already protected. On-premises servers still need the update, and that includes hybrid servers.

1. Apply the applicable update to Exchange SE servers and to machines running only the Exchange management tools, following Microsoft's supported update guidance.
2. Exchange 2016 and 2019 updates require Period 2 ESU eligibility. No ESU, no update, which makes a strong case for getting to Exchange SE.
3. Read the documented known issues first. This release has calendar and Korean-content issues worth checking against how your users work.

Microsoft reports no known active exploitation. That's what they've observed so far, and it promises nothing about next week, so schedule this with your normal security patching rather than parking it.

Exchange Online: send from alias is generally available as of October 7

Sending from a mailbox alias moved from public preview to general availability on October 7. It's opt-in. An admin enables the tenant setting with Set-OrganizationConfig -SendFromAliasEnabled $true, and the change can take up to 60 minutes to apply. An alias still isn't a separate mailbox, so mail to it keeps landing where it always has.

Before turning it on, check which clients your staff actually use and how routing, journaling and mail-flow rules treat the alias address. Run a message trace on an alias address too, so the help desk knows to search by alias and not only by primary address.

Shared mailboxes are the catch. Alias sending from a shared mailbox only works in OWA through Open another mailbox. Outlook clients don't support it, which is worth telling people before they go looking for the option.