On 25 September, Kiteworks told customers to take its secure file-transfer platform offline for nine hours. Federal intelligence authorities had warned the company that an attacker might target some Kiteworks systems. There was no confirmed compromise, and the current software release addressed every vulnerability the company knew about. The concern was what it did not know.
Kiteworks shut down the systems it hosted and asked customers running the platform themselves, whether on-premises or in AWS and Azure, to do the same. Two days later it lifted the recommendation. No breach was reported.
That looks like a non-event. It was not.
Availability was the risk treatment
Most continuity plans treat an unavailable system as the incident to prevent. Kiteworks inverted that assumption: keeping the service available carried the greater risk, so a controlled interruption became the protective measure.
That distinction matters for any organisation whose critical processes depend on an external platform. Security and continuity teams often work to competing objectives during a live threat. One wants to isolate first and investigate second. The other wants to preserve service until there is proof of harm. If nobody has decided which objective takes precedence, the argument starts when the evidence is weakest and time is shortest.
The useful question is not whether Kiteworks was right to shut down. Outsiders do not have the intelligence needed to judge that call. The useful question is whether its customers could act on the warning without first improvising their authority, workarounds, and recovery criteria.
A supplier cannot make the whole decision for you
The advisory covered hosted and self-managed deployments, but the operational consequence belonged to each customer. A secure transfer platform may sit inside legal exchanges, regulated reporting, payroll, product delivery, or incident response itself. Nine hours can be trivial for one process and a missed statutory deadline for another.
Following the supplier's instruction therefore required more than finding someone with administrator access. Customers needed to know which business services depended on the platform, what could continue manually, who could accept the interruption, and which transfers had to be reconciled after restart. The vendor supplied threat intelligence and technical guidance. It could not supply that business context.
Restart is part of the shutdown
Taking a system offline is immediate and visible. Bringing it back safely is less so. A credible plan needs a restart condition, a trusted source for the all-clear, checks for configuration and data integrity, and a way to identify transactions that failed or were duplicated during the gap. Without those controls, a precautionary shutdown merely moves uncertainty from the threat window into recovery.
The Kiteworks case is a clean test for continuity plans because the feared attack never became a confirmed incident. Ask who in your organisation could disconnect a critical supplier on warning alone. Then ask what evidence they would require, which services would degrade, and who would authorise reconnection.
If those answers require a committee to assemble, the decision has not been prepared. It has only been deferred.
