When AI Discovery Outpaces Release Cycles

Microsoft Can't Ship Exchange — And Your Change Process Is Next

Microsoft announced on August 13 that it still can't ship the first cumulative update for Exchange Server SE. Not because the code is broken. Because their AI security tools won't stop finding vulnerabilities long enough to cut a release.

The Exchange team's blog post reads like an apology note: "Where is Exchange SE CU1 anyway?" They promised the bundled update for the first half of 2026. Then the second half. Now there's no date at all. The reason? Every time they get close to shipping, their automated security scanners find three more critical issues that have to go out first. They're waiting for "a reasonable stable point... a month without pressing security payload." That month keeps not arriving.

AI didn't break Exchange. It broke the release calendar.

And if you own a change-approval process — the kind where IT, audit, and business units meet every Tuesday to decide what gets deployed when — this is the movie trailer for your next twelve months.

The Pattern: When Discovery Outruns Governance

I've watched this before. Not this exact scenario, but the shape of it.

In 2008, Chrome launched and started shipping updates every six weeks. Then every month. Then they dropped version numbers entirely and went evergreen — continuous auto-updates with no user opt-in. Firefox followed. The reason wasn't feature velocity. It was that security vulnerabilities were being discovered faster than the old "wait for the next major version" cycle could patch them. The eighteen-month release calendar that worked fine in 2003 became a liability when automated fuzzing tools started finding exploitable bugs weekly.

The change didn't come from some grand digital transformation strategy. It came because the old process mathematically couldn't keep up.

Microsoft is now hitting that same wall from the enterprise side. Chrome and Firefox could force continuous updates because they owned the entire delivery chain. But Exchange Server is installed behind corporate firewalls, tested against custom configurations, and deployed on schedules governed by change-advisory boards that meet twice a month if you're lucky.

The AI security tools don't care about your CAB meeting cadence. They find what they find, when they find it. And the business expectation — reinforced by every breach headline — is that critical vulnerabilities get patched immediately, not shelved until the next quarterly release window.

So Microsoft is stuck. They can't ship CU1 because there's always one more urgent patch. And they can't skip the patches because leaving known vulnerabilities unfixed is negligent. Discovery now outruns the release cycle, and nobody has figured out how to resolve that tension without breaking the deployment model enterprises still rely on.

Your Change Process Was Built for a Different Velocity

Here's the uncomfortable part: your organization probably runs the same playbook Microsoft can't make work anymore.

I've sat through enough change-advisory boards to know how the meeting goes. Half the agenda is finding a week when nobody's mid-crisis, nobody's on PTO, and the trading desk isn't in quarter-close. You evaluate risk, you batch changes to minimize disruption, you schedule deployment windows three weeks out.

That process was designed for a world where changes arrived at a predictable pace. Security patches once a month. Application updates once a quarter. Major infrastructure refreshes once a year.

But when automated testing tools — the same AI-powered scanners every vendor is now deploying — find problems faster than governance can approve fixes, the backlog never clears. You're not evaluating ten changes per meeting anymore. You're triaging forty, then sixty, then deciding which critical vulnerabilities you're going to accept as residual risk because you literally don't have meeting slots to approve them all.

The same AI tools your audit team is deploying to speed up control testing and your finance team is using to automate reconciliations will also hand your IT organization a discovery rate that drowns the approval pipeline. Microsoft has thousands of engineers working on Exchange and still can't find the quiet week to ship. What's your plan when your team of twelve is handed the same problem?

The Question Nobody's Asking

The conventional response to "we can't keep up with the pace of change" is to streamline the process. Automate approvals for low-risk changes. Delegate authority. Move some decisions out of the CAB entirely.

All good ideas. All insufficient.

Because the real question isn't how do we approve faster? The question is: what happens when the rate of discovered risk permanently exceeds the capacity of human governance?

Chrome's answer was to remove humans from the loop — force updates, no approval, trust the automated testing. That works for a browser. It doesn't work for the ERP system running your financial close, or the patient records database your compliance team has to audit, or the trading platform your regulators require you to test in a staging environment before production deployment.

You can't "move fast and break things" when the thing you break is a SOX control or a customer's encrypted financial records. But you also can't pretend the old cycle time still works when the threat landscape has accelerated past it.

I don't have a clean answer here. I don't think anyone does yet. But pretending this is just a Microsoft problem — or an Exchange problem — misses the pattern. The tooling that's about to make your teams more efficient is the same tooling that's about to make your governance process obsolete.

The Failure Mode Nobody's Discussing

Here's what keeps me up: we're about to automate discovery without automating response.

Every vendor pitch I see right now is about AI-powered threat detection, AI-enhanced code review, AI-driven control testing. All great. All finding problems we wouldn't have caught manually. But nobody's figured out the back half — what you do with a vulnerability backlog that grows faster than your team can remediate.

The optimistic take is that AI will also accelerate remediation. Auto-patching. Self-healing systems. Code that fixes itself. Maybe. Eventually. But the discovery tools ship first, and they're already outrunning human judgment.

The gap between "we found a problem" and "we fixed the problem" used to be measured in days or weeks. Now it's minutes for discovery and still weeks for deployment, because deployment requires testing, approval, and coordination across teams that don't move at AI speed.

That gap is where the next generation of breaches will live. Not because we didn't know about the vulnerability. Because we knew about it and couldn't deploy the fix fast enough to beat an attacker who's also using automated tools.

What to Do Monday Morning

If you own any part of your organization's change process, here's what I'd ask this week:

What's our current change approval throughput, measured in requests per week? Not how many we receive. How many we can actually evaluate, test, and deploy. That's your ceiling.

What happens when we hit that ceiling? Do we batch and delay? Do we let the backlog grow? Do we start making approve/defer decisions based on meeting time available rather than actual risk?

Who's tracking the rate of new vulnerabilities discovered across our stack? Not the rate we're patching. The rate they're being found — by our tools, by vendors, by researchers. Is that number going up? (It is.)

And the hard one: at what point does our process become the risk? When does the fact that we can't deploy fixes fast enough become more dangerous than deploying with less testing?

I'm not suggesting you abandon governance. I'm suggesting you measure the gap between discovery velocity and approval velocity before it becomes a crisis. Microsoft just told you they can't close that gap on one of the most scrutinized enterprise products in the world.

You've got less margin than they do.

What's the current backlog in your change process — and how fast is it growing? If you're seeing the same pattern, I'd like to hear how your team is thinking about it. Reply here or find me on LinkedIn.