Patch latency is the gap between the moment a software vendor ships a security fix and the moment that fix is actually running on your systems. In legacy MFT — managed file transfer, the software an enterprise uses to move files securely between itself and its partners — that gap is the flaw breaking the whole category. The vendor patches fast. You don't, because you can't, because the patch lands on your loading dock and you still have to install it yourself across every server you run.

A vulnerability gets a name and a number when it's disclosed: a CVE, short for Common Vulnerabilities and Exposures, the public ID every security team tracks a flaw by. Once a CVE is public, the clock starts. Attackers read the same disclosure you do, and they start scanning the internet for systems that haven't been fixed yet. The question that decides whether you get breached is simple: who closes the hole first, you or them?

In the legacy model, they usually win. And the reason isn't that your team is slow. It's the architecture.

How Patch Latency Actually Plays Out

Picture the sequence the way it really happens. A critical flaw is found in a managed file transfer product. The vendor does its part well — a fix is written and released, sometimes within a week.

That sounds reasonable until you remember what "released" means for self-hosted software: the vendor has made a patch available. It is not installed anywhere yet. That part is on you.

So now the work starts on your side. You find a maintenance window when taking the server down won't break a partner's nightly transfer. You test the update against your configuration so it doesn't take down something else. You push it through internal change management, which exists for good reasons and is not fast. Then you deploy it by hand across every box running the software — and a large enterprise runs more of them than it can easily count.

Every step is reasonable. Stacked together, they add up to days or weeks. That is the window.

Attackers do not have a change-management process. The moment a CVE is public, ransomware groups begin scanning the internet for the exact systems that haven't been fixed yet. They are racing a window you can't close quickly, and they know it. This is not a story about one bad week. It is the structural shape of how legacy MFT gets breached: a real fix exists, and it just isn't installed in time.

Why This Keeps Happening to the Same Category

The mass-exploitation breaches of the last few years all rhyme. A single criminal group, Cl0p, ran the same play against several legacy MFT products in succession — MOVEit, GoAnywhere, Cleo, and earlier the file-transfer appliance from Accellion. Find a flaw in a widely deployed file-transfer product, weaponize it before defenders can patch, and harvest data from hundreds of organizations that all share the same unpatched window at the same time.

It keeps working for the same reason every time. These are self-hosted products. The vendor can ship a fix, but it cannot install the fix for you.

Every customer is responsible for their own patching, every customer is on their own timeline, and the slowest customer is the one that gets hit. When thousands of organizations run the same software and each one patches on its own schedule, the attacker only has to find the ones who are still mid-process. There are always some.

MFT is an especially rich target because the product sits exactly where the sensitive data moves — it's the pipe between an enterprise and its partners, full of exactly the files a ransomware crew wants. A flaw there isn't a nuisance; it's a data breach.

The point worth sitting with: the delay isn't a failure of your team's responsiveness. It's a property of the architecture. Self-hosted software puts the install step on the customer, and the install step is where the time goes.

How the SaaS Model Closes the Window

Software-as-a-service — SaaS, software the vendor runs centrally and you reach over the network instead of installing yourself — changes who does the patching. When the software runs on the vendor's infrastructure, the vendor patches it once, centrally, and every customer is protected at the same instant. There is no patch sitting on your loading dock, because there is no server of yours for it to land on.

That single change collapses the timeline. Instead of thousands of customers each starting their own multi-day process, the exposure window shrinks from weeks to hours, sometimes to minutes. The maintenance window, the test cycle, the change-management queue, the manual deploy across every box — all of it disappears, because none of it was ever about the fix itself. It was about the install. Take away the install and the latency goes with it.

This is the architectural answer to the architectural problem. You cannot train your way out of patch latency or staff your way out of it, because the bottleneck isn't effort. The only way to remove the gap is to remove the step that creates it.

File Transfer on a Platform With Nothing to Patch

Most teams that get tired of racing a CVE clock have moved to a single cloud-native platform that takes the patching off their plate entirely. Files.com is the cloud-native File Orchestration Platform: one platform that replaces the stack of legacy tools IT teams run to move files — SFTP and FTP servers, MFT suites, file-sharing apps, and the custom scripts holding them together. It speaks every protocol, connects to 50+ cloud and on-prem systems, automates every transfer, and keeps a complete audit trail of who touched what.

The patch-latency part is the part that matters here: there is nothing for you to patch. Files.com runs the platform, so security updates roll out across the whole platform the moment they're ready — no maintenance windows, no manual upgrades, no waiting on a change-management queue while attackers scan for you. Your partners still connect over the same FTP, SFTP, and FTPS they always have, with the same clients and the same logins, and the exposure window that breaks legacy MFT is simply not yours to manage anymore. Files.com has run this way for 15+ years with zero breaches.

If you want to see how the model holds up under your own requirements, explore Files.com's managed file transfer platform, or read the deeper explainer on what FTP is and why it still matters in the cloud era. When you're ready, start a free trial — no credit card, live in minutes.