If Your Vendor Says ‘Turn It Off,’ You’ve Already Lost

You trust your file-sharing tool. You’ve built workflows around it. You’ve trained your team. And then one day, the vendor sends an email that says: Please turn off the software to stay secure.

That’s not a security update. That’s a confession.

This is exactly what happened to Progress ShareFile customers this week. The official guidance? Disable the product. The safest action? Complete shutdown. And if you’re a sysadmin reading that, you feel a cold knot in your stomach. Because you know what that means: the thing you relied on just became your biggest liability.

When the safest thing you can do with a product is to turn it off, the product doesn’t have a security problem—it is the security problem.

Let’s be clear about what’s going on here. This isn’t just another CVE. This is a fundamental breakdown in software lifecycle management. The vendor’s only viable response was to disable the product entirely. That means the incident response failed. The product design failed. And the trust you placed in them? That’s gone too.

You’ve probably noticed this pattern before. A vendor patches a vulnerability, everything’s fine. But when the patch is to turn off the product, you’re no longer managing a bug—you’re managing a crisis. The product’s core value proposition—secure file sharing—is now a vector for compromise. The tool that was supposed to enable you now forces you to choose between security and functionality.

And that’s the real poison. Most observers will focus on the bug or the vendor’s communication misstep. But the deeper issue is our industry’s tolerance for monolithic, opaque software that leaves you no options. You can’t fail gracefully. You can’t isolate the broken component. You can’t even trust the vendor to have a fail-safe that doesn’t involve pulling the plug on your entire operation.

We’ve normalized a world where vendors can hold your infrastructure hostage with a single point of failure. And then they call it ‘security.’

I saw this firsthand years ago with a different vendor. They told us to disable an entire application layer because of a zero-day. The fix took three weeks. In those three weeks, we had to rebuild half our workflows. The trust never came back. We eventually moved to a system that was designed with fail-safes, not just patches.

Here’s the twist: the bug itself isn’t the story. The story is that the industry allows products to be built this way—where a single vulnerability can force a total shutdown. That’s not a bug in the code. That’s a bug in the design philosophy. And it’s systemic.

So what do you do?

Stop asking, ‘Is this product secure?’ Start asking, ‘If this product fails, can I still operate?’ The answer should tell you everything. If the vendor’s only answer to a crisis is ‘turn it off,’ then you’re not buying a solution—you’re buying a hostage situation.

Your disaster recovery plan should never be a vendor’s email subject line.

This is a blueprint for evaluating vendor risk. Go check your critical software right now. Ask the vendor: ‘What happens if there’s a critical vulnerability? What’s your backup plan?’ If they hesitate, you have your answer. If they say ‘we’ll issue a patch,’ that’s fine. But if they say ‘we’ll advise you to disable,’ run.

Because the day your vendor tells you to turn it off, you’ve already lost. The only question is whether you’re willing to lose again.