"In short: Exchange SE CU1 is coming; we do not have a date to give you. But we did not forget about it," the Exchange team wrote last Thursday in a post titled "Where is Exchange SE CU1 anyway?"
Microsoft's Exchange team explains the delay and shifting timeline
The Exchange team acknowledged customers' questions about the absence of Cumulative Update 1 (CU1) for Exchange Server Subscription Edition (SE), saying earlier public timelines — "by the end of the first half of calendar year 2026," later updated to "second half of 2026" — have slipped. The post framed CU1 as the inclusive release that bundles "all recent bug fixes, plus other changes such as new features or removing deprecated code," and reminded readers that Microsoft typically publishes CUs once or twice a year.
AI bug‑finding created extra validation work, Microsoft says
Microsoft attributed much of the delay to the downstream effects of using AI tools to surface potential vulnerabilities. The post explains the team is "working through reported issues – which includes validation that they are real security issues, reproducing, fixing, testing for regressions / issues after fixes are deployed and releasing updates monthly." In short, automated discovery has increased the volume of reported findings, and each report triggers human-led validation and regression testing before fixes can ship.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadSecurity prioritization after a prior Exchange attack
The Exchange team tied its schedule choices to an explicit pledge to "prioritize security above all else." The post recalled that Microsoft adopted that stance after "flaws in Exchange led to an attack on Exchange by suspected Chinese operatives, earning it a tongue-lashing from the US government." That experience, the team says, altered release calculus: they prefer to fold monthly security payloads into an internal CU1 build rather than ship CU1 only to have to replace it quickly with a separate security update.
Release mechanics: monthly payloads, internal builds, and the problem of double updates
Microsoft described its practical path to CU1 as iterative. "We are regularly rolling our monthly security payload into our internal CU1 build and plan to release Exchange SE CU1 as soon as we get a reasonable stable point and have a month without pressing security payload," the post states. The team warned that releasing CU1 and then issuing a subsequent security update "would create double the update work for many organization administrators." Internally, it noted, ensuring two major releases — a Security Update and a CU — are both appropriately tested "would be very challenging as CU1 must be all inclusive of everything that we released since the RTM."
What this means for Exchange administrators, enterprises, and potential adversaries
- Exchange administrators and affected enterprises: They will be spared the immediate burden of applying two large updates in quick succession if Microsoft meets its stated objective, but they are left without a firm CU1 date and must continue to apply monthly security payloads as they arrive.
- Security teams and technologists: The increase in AI‑generated findings means more validation, reproduction, and regression testing work upstream of releases — a process Microsoft says it is executing before rolling fixes into CU1.
- Adversaries and threat actors: The post signals a defensive posture that prioritizes rapid security patching over fixed feature release dates; Microsoft’s stated aim to avoid shipping a CU that would immediately require replacement for security reasons reduces windows in which unpatched vectors could be exploited once fixes are available.
Microsoft's message is straightforward and unresolved: the company says it has not forgotten CU1, that it is actively integrating monthly security work into a CU1 build, and that it will not commit a date until it finds a "reasonable stable point" and a month without a "pressing security payload." The decision to let security updates take precedence reflects lessons from a prior Exchange compromise, but it also exposes a modern tension: expanding automated vulnerability discovery can slow calendar promises as human teams validate and test findings. The immediate practical question the post leaves is explicit and concrete — when will Microsoft find a month without a pressing security payload?
