If you run Exchange Online tenants for other people, open a PowerShell session this week and check EwsEnabled on every one of them. Microsoft is disabling Exchange Web Services tenant-by-tenant, and the property that controls it has a default value that turns into a block on October 1.

The Exchange team's retirement post explains the mechanism plainly: "We'll disable EWS tenant-by-tenant using the EWSEnabled property, which supports three values: True, False, and Null (the default today)." Then the part that matters: "Any tenant with EWSEnabled still set to Null on October 1, 2026, will see the value changed to False as the deployment rolls out. That will block EWS for all applications in the tenant at that time."

Null is the default, so unless somebody deliberately set the value, every tenant you manage is sitting on the value that gets flipped. This is not an opt-in migration that skips tenants nobody touched. It is the opposite — the untouched tenants are exactly the ones that change.

You have two ways to keep EWS working. Microsoft lists them as: "Set EWSEnabled to True and maintain an AppID Allow List (via Baseline Security Mode or Exchange Online PowerShell)," or "Set EWSEnabled back to Null, which re-enables EWS without restrictions until the final deprecation occurs. This will have to be done using Exchange Online PowerShell."

There is also a way to opt out of the October 1 change entirely, and it has a deadline of its own: "if you proactively configure an AppID Allow List and set EWSEnabled to True by the end of September 2026, your tenant will be excluded from the October 1 automatic change to EWSEnabled=False." That is two weeks away. Microsoft says it will "pre-populate the AppID Allow List for customers who have not created one, based on each tenants own usage," so the list you inherit may already be close to right — but only if the tenant is set to True, because a Null tenant ignores the allow list altogether.

Fixing it after the fact works, and Microsoft says so, but it is not free: an admin can re-enable EWS after the block, "But note that there will be a service interruption in this case."

How long that interruption runs is where operators and the vendor post diverge. Microsoft does not publish propagation timing. An r/msp thread this week reports that EWS "stops working within about an hour of that flip," and that recovery takes another hour after an admin sets the value back, which the poster totals as "a minimum two-hour outage per client." The same thread reports that Apple Mail and several Microsoft 365 backup tools still depend on EWS. Treat those numbers as one operator's field measurement rather than a Microsoft commitment, but they scope the risk correctly: the change lands per tenant, and the affected applications are server-to-server integrations rather than anything that shows up in a user's Outlook.

One more thing worth setting now even if you conclude you do not need EWS. Microsoft says it "may perform temporary 'scream tests' (shorter periods of time when we turn EWS off and then back on)," and that "If your organization sets EWSEnabled = True now, you will not be impacted by any 'scream tests' that we might conduct." Setting the value explicitly is what takes a tenant out of that sample.

Action this week: pull the EWS usage report for each tenant — Microsoft points admins at the "EWS usage reports in the Microsoft 365 admin center" — and sort tenants into two piles. Tenants with no EWS traffic need no action; the October 1 flip is the outcome you want. Tenants with traffic need an explicit decision before September 30, and the app IDs in that report are the list you will be allow-listing. Either way, write the value down rather than leaving it at Null, because Null is the one state that changes underneath you. The final shutdown is "April 1, 2027," and at that point "The ability to control EWSEnabled will be removed from tenant admins."

Advisories

Cisco's email gateway gets rooted by an email, and the KEV deadline is tomorrow

CISA added CVE-2026-76461 in Cisco Secure Email Gateway on September 14 with a due date of September 17 — tomorrow. NVD carries Cisco's description: an unauthenticated remote attacker can "execute arbitrary commands with root privileges on the underlying operating system" by "sending a crafted email message that contains malicious SQL statements through an affected device." Cisco scores it 9.8. The delivery mechanism is inbound mail, so the appliance's job is the attack surface. Cisco's advisory says the bug affects the gateway "both physical and virtual, regardless of device configuration," that "In September 2026, the Cisco PSIRT became aware of active exploitation," and that there are "No workarounds available."

Action: upgrade. Cisco's fixed releases are 15.5.5-014 for 15.5 and earlier, 16.0.4-302 for 16.0, and 16.5.0-780 for 16.5, and it "strongly recommends that customers migrate to Release 16.5.0-780." Then check whether you were already hit: Cisco says to review mail_logs for suspicious SQL, with grep -i "COPY.*TO PROGRAM" as its example, and to check every device in a cluster. Secure Email and Web Manager and Secure Web Appliance are confirmed not vulnerable.

Chrome ships 42 security fixes, three of them Critical

Google released Chrome 153.0.8010.47/.48 for Windows and Mac and 153.0.8010.47 for Linux on September 15. "This update includes 42 security fixes." Three are rated Critical: CVE-2026-91726 (out of bounds read in WebGL), CVE-2026-91721 (use after free in Internals), and CVE-2026-91749 (use after free in Workers). Twenty-eight more are High. Google does not report any of them as exploited.

Action: Chrome applies updates on relaunch, so a machine that has not been restarted is still on the old build no matter what your patch dashboard says. Edge inherits the same Chromium base on its own cadence — check both.

Oracle ships 673 patches and is now on a monthly clock

Oracle published its September Critical Security Patch Update on September 15: "This Critical Security Patch Update contains 673 new security patches across the product families listed below." For database estates, 11 of those are Oracle Database Products patches, and "5 of these vulnerabilities may be remotely exploitable without authentication."

Action: the scheduling change matters more than the count for most shops. Oracle now states that "Security patches are released on the third Tuesday of each month," and lists the next four as 20 October 2026, 17 November 2026, 15 December 2026 and 19 January 2027. Check that your maintenance calendar carries all four rather than a quarterly cycle.

A normal KEV week, and four deadlines that ran out on Monday

KEV took 7 additions between September 10 and today; across the prior eleven weeks the weekly range was 3 to 12, so this one sits mid-range. The catalog is at 1,710 entries. More useful than the additions is what came due: six deadlines elapsed inside this window. September 14 was the due date for ConnectWise ScreenConnect CVE-2026-84869, which led #020, for GitLab CVE-2026-85706, and for the PaperCut pair CVE-2026-81578 and CVE-2026-82078 that led #019. Two more, in LiteLLM and Starlette, come due today.

Action: if any of those four are still unpatched, you are past the federal deadline, not approaching it. Check ScreenConnect first, because patching the server is not the whole job — ConnectWise's bulletin tells cloud customers they must still reinstall host clients and update access agents.

Product changes

Edge 153 changes which local IP it reports to your PAC scripts

Microsoft shipped a change in Edge 153 to "how it selects the local network address reported to proxy auto-config (PAC) scripts." The new defaults match Chromium's: "The default IPv4 and IPv6 probe destinations now match Chromium's defaults." The item is marked Launched with general availability in September.

Action: if a client's PAC script routes on myIpAddress() — common on multi-homed machines and split-tunnel VPNs — test before this reaches the fleet. Microsoft added two policies for exactly this case: "Administrators can override these defaults using the PacMyIpAddressIPv4ProbeAddress and PacMyIpAddressIPv6ProbeAddress policies when required by their network routing."

Teams gets a report button for guest invitations, Outlook gets Cloud Policy

Two admin-facing roadmap items landed on September 14. Teams will let users report suspicious guest invitations: "When users receive an unexpected or potentially malicious guest invitation, they can report it to their IT admin for review, helping identify and mitigate phishing and other abuse through guest invitations." That is general availability in November. Separately, Cloud Policy service support is coming to Outlook on the web and new Outlook for Windows in October, so admins "can set default values for supported Outlook settings and choose whether users can change them."

Action: decide now who receives the guest-invitation reports in each tenant, and where they land. The feature routes reports to "their IT admin for review," so for a managed tenant that destination needs to be a queue you actually watch.

Licensing

Office, Project and Visio LTSC 2021 lose support on October 13

Microsoft told partners on September 15 that "Support for Office Long Term Servicing Channel (LTSC) 2021, Project LTSC 2021, and Visio LTSC 2021 ends on October 13, 2026. After this date, these products no longer receive updates, security fixes, or technical support." The announcement says "Enterprise customers should turn to Microsoft 365 E3 as the primary recommended path."

Action: LTSC installs are the ones that do not show up in a subscription report, because nobody is billed for them monthly. Find them by querying installed Office build numbers across managed endpoints rather than by pulling a license list, and get the conversation started before October 13 rather than after a client's Visio stops getting fixes.

Compliance

Purview extends browser DLP to more apps in Edge for Business

Two Purview DLP items posted on September 15, both preview in November and general availability in December. One "will support browser inline protection for a significantly broader set of unmanaged generative AI apps in Edge for Business." The other upgrades inline protection for Entra-managed apps, and it "integrates with a Microsoft Entra Conditional Access grant control and simplifies configuration while removing current Purview policy restrictions."

Action: if you evaluated Purview inline protection earlier this year and rejected it on the policy limits, the December build removes several of them — the upgraded version adds simulation mode, so you can measure what a rule would have caught before you turn it on for anybody.