The practical point is more precise than a blanket statement that Microsoft 365 is blocking every old Exchange server. The reported scope is Exchange 2016 and 2019 servers that connect to Exchange Online through an inbound connector of the OnPremises type. For hybrid Exchange deployments, that can be a business-critical mail route. A server falling below the required level may be subject to reporting, throttling, and ultimately blocking under Exchange Online’s transport enforcement process.
For Windows and Exchange administrators, this is both an immediate patch-compliance task and a reminder that Exchange 2016 and 2019 are now beyond their normal support lifetime. Updating to the stated baseline may preserve mail flow in the near term, but it does not turn either product into a supported long-term platform.
What is changing — and what is not established
A contemporaneous report says the Exchange Online minimum for Exchange 2016/2019 servers using an OnPremises inbound connector will rise to the October 2025 Security Update level in the second week of September 2026. No exact service-side cutoff date or time should be assumed from that window. Organizations should treat it as an imminent operational deadline, not schedule their work around a guessed day.
The October 2025 baseline matters because it is described as the final publicly released Security Update level for the two older Exchange versions. Exchange Server 2016 CU23 and Exchange Server 2019 CU14 or CU15 were the relevant servicing branches. Later security servicing for those editions moved into the Extended Security Update, or ESU, program for eligible customers.
That distinction can easily cause confusion:
- Publicly available patch level: the October 2025 Security Update baseline reportedly becomes the floor for this September 2026 transport change.
- Later ESU releases: these can be relevant to security posture for enrolled customers, but they are not the same thing as the public baseline being raised now.
- Exchange Online enforcement: this concerns a specific incoming-connector-based route from on-premises Exchange to Exchange Online, rather than necessarily every method an application or server might use to deliver mail.
It would be a mistake to translate the announcement into “all Exchange 2016 and 2019 mail stops in September.” Connector design, routing, and the particular servers Exchange Online detects as connecting systems all matter. It would be equally risky to dismiss the change because another SMTP route appears to work in testing. If a hybrid transport path uses the affected connector model, mail continuity may depend on bringing the real connecting servers into compliance.
Why a mail-flow rule has become a lifecycle issue
Exchange Server 2016 and Exchange Server 2019 reached end of support on October 14, 2025. Microsoft’s support guidance says the products no longer receive ordinary technical support, bug fixes, security fixes, or time-zone updates. Its stated strategic options are migration to Microsoft 365 or Exchange Server Subscription Edition, commonly called Exchange SE.
That support status changes how the September threshold should be interpreted. An organization can reasonably see the October 2025 public baseline as a near-term interoperability requirement: update the server so Exchange Online continues accepting the applicable connector traffic. But that is not a complete security strategy.
The gap becomes especially important when a newly discovered Exchange vulnerability requires a code fix after the public servicing era. Microsoft has documented ESU-only security releases for Exchange 2016 and 2019 during 2026. It has also been clear that emergency mitigations are temporary measures, not replacements for Security Updates. A mitigation may reduce exposure while a patch is being planned, but it is not a durable substitute for supported servicing.
There is also a fixed horizon for ESU planning. The second ESU period runs from the start of May 2026 through the end of October 2026, with no further extensions stated. Therefore, ESU should be viewed as a limited bridge for organizations that qualify and need time to complete a transition—not as a permanent way to keep Exchange 2016 or 2019 viable.
The affected route: focus on the connector, not just the server inventory
Hybrid environments can be more complicated than their Exchange version inventory suggests. An organization may have multiple Exchange servers, a mix of active and standby hosts, old relay infrastructure, and connectors inherited from previous migrations. The servers that administrators consider primary may not be the systems actually establishing the connection Exchange Online sees.
The useful first question is not simply, “Do we have Exchange 2016 or 2019?” It is:
Which on-premises Exchange servers are currently sending to Exchange Online through an inbound connector of the OnPremises type?
That question should drive the investigation. Pay particular attention to:
- production hybrid transport servers and any load-balanced peers;
- disaster-recovery servers that could become active during maintenance or an outage;
- decommission candidates that remain in send connectors, DNS records, or load-balancer pools;
- servers with delayed cumulative-update or security-update maintenance;
- environments where applications relay through Exchange before messages enter Microsoft 365.
The enforcement framework is intended to identify connecting on-premises servers and provide tenant-level reporting. Administrators should use the available Exchange Online reporting facilities to confirm the servers detected, their status, and any scheduled enforcement information. The Get-OnPremServerReportInfo cmdlet is associated with reviewing detected connecting-server information.
That review should be done before changing routing or assuming that every server needs the same remediation. It can reveal a stale node that only appears during failover, or a relay path that was never included in the patching plan. Conversely, it can help prevent unnecessary disruption to infrastructure that is not in the affected path.
A short-term response plan for Exchange administrators
For organizations that still depend on hybrid mail flow, the appropriate response is methodical rather than reactive.
1. Confirm the real Exchange builds
Inventory each Exchange 2016 CU23 and Exchange 2019 CU14/CU15 server that could send toward Exchange Online. Verify the installed cumulative update and Security Update level using the server’s installed build information, rather than relying on a change ticket or an asset-management label.
The goal for the immediate enforcement threshold is the October 2025 Security Update baseline. Administrators should consult their approved Exchange update procedures and ensure the intended update applies to the installed CU branch. A server that is merely “Exchange 2019” is not necessarily at an acceptable build.
2. Map connector traffic and resilience paths
Review the outbound path to Exchange Online, inbound connector configuration, load balancing, and failover behavior. Test both normal routing and the route that would be used if the primary server is offline. A standby host left at an older patch level can become the cause of a mail outage precisely when an organization is already responding to another incident.
Applications deserve separate attention. A line-of-business application may submit mail to an on-premises Exchange relay, which then uses the hybrid path to reach Exchange Online. The application itself may not be in scope for the connector rule, but its business mail can still be interrupted if the relay Exchange server is throttled or blocked.
3. Patch with Exchange-specific operational care
Exchange patching is not equivalent to a simple Windows cumulative update cycle. Teams should use a maintenance window, verify prerequisites, take account of server roles and high availability, and validate transport after deployment. The most useful success checks are practical ones: confirm Exchange services are healthy, queues are behaving normally, mail is reaching Exchange Online, and messages are not accumulating on a previously overlooked server.
Where high availability exists, patching and validation should be staged rather than applied blindly to every node at once. The details depend on the deployment, but preserving a tested recovery path is more valuable than a superficially fast update rollout.
4. Treat an exemption as contingency time, not a solution
The enforcement process is described as allowing a tenant to pause enforcement through the Exchange admin center or by using New-TenantExemptionInfo. The allowance is described as up to 90 days per tenant in a calendar year, and days requested are not returned if remediation finishes earlier than expected.
That makes an exemption a valuable emergency control when patching cannot safely be completed before enforcement begins. It is not a reason to defer planning. Before depending on one, administrators should verify current eligibility, tenant status, the exact pause duration, and the relevant user interface or PowerShell requirements in their own environment.
A good operational rule is to request only the time genuinely needed and use it to complete a dated remediation plan. Consuming the annual allowance early can leave an organization with fewer options if another unexpected problem appears later.
The strategic choice: Microsoft 365, Exchange SE, or a bridge
The path forward is different for Exchange 2016 and Exchange 2019.
Exchange Server 2019 CU14 or CU15 supports an in-place upgrade to Exchange Server Subscription Edition. That offers a clearer route for organizations that require an on-premises Exchange footprint because of application dependencies, regulatory requirements, or local operational design. It does not remove the need for testing, backup, rollback planning, and review of third-party integrations, but it avoids treating another temporary patch cycle as the entire strategy.
Exchange Server 2016 has a more difficult transition. In-place upgrading from Exchange 2016 to Exchange SE is not supported. The documented route requires a legacy migration approach, moving through Exchange 2019 CU14/CU15 or using an appropriate migration path to Exchange SE. That takes more planning: server capacity, namespaces, certificates, transport configuration, client access, coexistence, and eventual retirement of the old platform all need attention.
For some organizations, the better answer will be to remove the remaining on-premises Exchange dependency and migrate the relevant workload to Microsoft 365. That decision is not solely about mailboxes. It can involve SMTP relay, scanners and multifunction devices, service accounts, compliance integrations, and applications coded around legacy relay behavior. Those dependencies should be cataloged early, because they are often what turns a seemingly simple mail migration into a prolonged infrastructure project.
Avoid two damaging assumptions
The first damaging assumption is that reaching the October 2025 Security Update level resolves the entire risk. It may address the reported September 2026 Exchange Online floor for the relevant connector traffic, but Exchange 2016 and 2019 remain out of normal support, and ESU servicing itself has a stated endpoint after October 2026.
The second is that a future enforcement increase has a known date or fixed required build. A later increase has been discussed, but the supplied information does not establish a precise rollout date, a definitive next threshold, or a guarantee about the future enforcement schedule. Organizations should not make outage-sensitive decisions based on speculation. They should monitor their tenant’s reported status and plan against the published end-of-support and ESU timelines that are already known.
The practical bottom line
The September 2026 threshold is best understood as a transport reliability deadline inside a larger Exchange modernization deadline. Organizations using Exchange 2016 or 2019 to send through an OnPremises inbound connector should identify the actual connecting servers, verify the October 2025 Security Update level, and patch or obtain narrowly scoped contingency time before enforcement affects mail flow.
But the more consequential work is choosing the post-ESU destination. Exchange 2019 organizations have a supported in-place route to Exchange SE from CU14 or CU15. Exchange 2016 organizations need a migration-oriented plan. And organizations able to retire on-premises Exchange should treat the connector enforcement signal as an opportunity to eliminate an aging dependency rather than repeatedly extend it.
For Windows administrators, the immediate patch check is concrete and urgent. The longer-term lesson is equally clear: mail transport policy is now exposing the operational cost of running Exchange versions whose normal support era has already ended.