That makes CU1 more than a package of already completed changes. Shipping on the original timetable could have forced Microsoft to choose between leaving newly validated vulnerabilities out of the cumulative build, rushing fixes that had not received adequate regression testing, or delaying the release. Microsoft has chosen the delay and says it will release CU1 when the build reaches a reasonable stable point and there is a month without a pressing security payload.
The schedule has shifted in stages:
The Exchange team is continuing to roll monthly security payloads into its internal CU1 build. That means the eventual cumulative update is intended to include the security work completed while the release was delayed, rather than representing a separate pause in Exchange security maintenance.
The indefinite CU1 delay does not mean that Exchange SE customers have been left without security fixes. Microsoft released Exchange SE Security Updates in June, July, and August 2026.
May was different: Microsoft announced that there would be no regular Exchange Security Update that month. It subsequently issued guidance and mitigation information for CVE-2026-42897, and later directed customers to the July update as the point at which the mitigation recommendation could be removed.
The August release also addressed CVE-2026-65813, an elevation-of-privilege vulnerability affecting Exchange Server Subscription Edition among other supported Exchange versions.
CU1 should not be treated as a security deadline that customers can wait for. Microsoft’s own guidance is for organizations already running Exchange SE to stay up to date while CU1 remains in development.
Use the organization’s normal change-control process: test updates in representative non-production environments where feasible, assess urgency against exposure and risk, deploy the matching Exchange security package, and verify that the security update installed successfully. August guidance also emphasizes that administrators should verify the security-update build rather than rely only on the underlying cumulative-update version shown by Exchange tooling.
A monthly SU is primarily an operational security action. CU1 should be planned as a broader platform event that may require compatibility testing, application validation, backup and rollback preparation, and wider regression checks.
This distinction prevents a common planning mistake: treating CU1 as a replacement for routine patching. Monthly updates reduce current security exposure; CU1 will consolidate accumulated work and introduce the next major set of Exchange SE changes when its quality bar is met. Microsoft’s roadmap describes CU1 as the first introduction of new features in Exchange Server SE.
The Exchange delay illustrates a structural tension in modern software development. AI-assisted discovery can increase the flow of potential vulnerabilities, but discovery is only the beginning of the security process. Human engineers still need to determine what is real, reproduce the behavior, build a safe remediation, and prove that the fix does not break surrounding functionality.
That is a positive security problem: finding more potential flaws can improve protection before attackers exploit them. But it also puts pressure on remediation, quality assurance, release engineering, and customer communication. Subscription software creates an expectation of predictable delivery, while security work is inherently driven by findings that may not fit a calendar.
For Exchange customers, the durable operating model is therefore two-track: patch monthly for protection, and schedule CU1 for lifecycle and platform consolidation once Microsoft provides a stable release. The absence of a CU1 date changes deployment planning, but it does not change the need to keep Exchange SE current.