The MOVEit lesson: asset discovery beats patch speed

The MOVEit story gets retold as a patching failure. That framing is comfortable because it implies a clean fix: patch faster, be more disciplined, close the window. What I keep coming back to, though, is the uncomfortable version of the same story. How many of the organizations named in those breach notifications first learned they were running MOVEit from the breach notification itself?

That is the part that does not fit into a cadence metric. And it changes what “how the MOVEit vulnerability worked and what to do about it” actually means for a small IT team, because the answer starts a lot earlier than the patch cycle.

How the MOVEit vulnerability worked and what defenders faced

The technical shape is not exotic. MOVEit Transfer had a SQL injection flaw, CVE-2023-34362, rated CVSS 9.8, that let an unauthenticated attacker reach the underlying database over HTTP or HTTPS. No credentials, no foothold, no social engineering. Just a web request that reached into the database behind the file transfer app and pulled out what was there, including file metadata and stored content.

Cl0p, a group with ties to the FIN11 crew, ran mass exploitation as a zero-day before patches were widely available. CISA added it to the Known Exploited Vulnerabilities catalog as activity spread. Healthcare organizations felt it especially hard, because claims data, benefits administration, and vendor file exchanges were riding on MOVEit instances that nobody thought about on a weekly basis.

That last part is the part I want to sit with. A managed file transfer app is a high-value target on purpose. It sits between organizations. It holds data in motion. It touches partners, payers, vendors, and downstream systems. When it gets popped, you do not just lose one company’s data. You lose the seam where a lot of companies’ data was passing through.

The quiet-infrastructure problem

MOVEit was not a household name in most orgs. It was deployed on thousands of servers doing quiet, essential work. Somebody stood it up once, probably to satisfy a specific integration need, and then it just… ran. The person who set it up moved teams. The team that inherited it touched it only when a job failed. The vendor became a line item on a renewal spreadsheet.

I think of this as the quiet-infrastructure problem, and MOVEit is a clean example but not a rare one. Managed file transfer, integration middleware, print management, backup agents, identity brokers, appliance-shaped things that live in a rack or a VM and hum along. They are load-bearing. They are also under-instrumented compared to the marquee products the security team watches every day.

The pattern I keep seeing since 2023 is that attackers have figured this out. The middle layer is connected to sensitive data, exposed enough to be reachable, and monitored less than the front-of-house tools. That is a good deal from the attacker’s side of the table.

Why patch speed is the wrong scoreboard

Here is where I want to be careful, because I do not want to overclaim. Patch speed matters. Nobody argues otherwise. But patching cadence is a downstream metric of something more fundamental, which is whether you know what you have.

You cannot patch what you have not inventoried. And in the MOVEit case, the window between disclosure and mass exploitation was compressed to near zero anyway. The zero-day was already running when the advisory dropped. For that class of event, patch speed is bounded by the vendor. Asset knowledge is bounded by you.

The questions I find more useful than “how fast did we patch” are the ones you can actually answer in advance:

• Where does this software live?
• What data flows through it?
• Who depends on it?
• What is it exposed to?

Reframing the work this way changes what a Tuesday morning looks like. Less time refreshing a CVE feed. More time understanding the systems you already own.

What asset discovery actually looks like for a small team

You do not need an enterprise platform for this. You need a habit. A few things I usually recommend for the small businesses I work with in Southwest Florida, and that I try to hold myself to as well:

Keep a living inventory of internet-facing services, not just endpoints. For each one, write down the vendor name and one sentence describing what the software does. If nobody on your team can write that sentence, that is the finding.

Map the data flows through file transfer, integration, and identity tools. These are the systems that turn one CVE into a breach, because they are the ones connected to everything else. In my experience with small businesses, the identity layer and any tool that moves files or payment data deserve this map first.

Subscribe to advisories for the boring infrastructure, not just the big names. If you use a specific file transfer product, a specific firewall, a specific backup agent, get the vendor’s security bulletins into an inbox somebody actually reads.

Tabletop the question: if vendor X announced a critical zero-day tomorrow, how long until we could answer where it runs and what it touches? If the honest answer is measured in days, that is the gap. Close the gap before the advisory forces you to.

And a bias I hold, offered as judgment rather than fact: I treat unknown or forgotten software as a higher risk than unpatched-but-known software. The unpatched thing is a task on a list. The unknown thing is not on the list yet.

Closing

The MOVEit victims who fared best were not necessarily the fastest patchers. Speed helped, sure. But the ones who came through cleanest were the ones who could answer, within minutes of the advisory, where the software lived, what it was connected to, and whose data was riding on it. That kind of knowledge is not built during an incident. It is built in the quiet months before, by teams that decided understanding their own systems was the actual job.

So the question I would leave you with is not “how fast can you patch?” It is: if the next MOVEit-shaped advisory drops tomorrow, for a product you have quietly relied on for years, how long until you can answer where it runs?