The advisory Kiteworks customers received on Friday 25 September did not ask them to patch. It asked them to switch off. And with that the problem left the systems department: nobody on call has the authority to leave the company without the channel customer documentation arrives through for an entire Saturday morning.
Kiteworks is a secure file transfer platform: the place many companies use to move documentation with customers, insurers, hospitals or public bodies. Its CISO, Frank Balonis, wrote to customers that they had received "credible threat intelligence from law enforcement indicating an attack on Kiteworks systems may be imminent this weekend". In a further statement he added that he was unaware of any compromise and that the move was being taken "out of an abundance of caution". The company's press release, the same day, attributed it to "federal intelligence authorities".
Six hours in the email, nine in the press release
It is worth stopping here, because both figures are in circulation. The customer email, first published by the German outlet Heise, said plainly: "We strongly recommend you shut down your Kiteworks system for six hours", with the window adjusted per time zone: 4:00 to 10:00 on Saturday in central Europe, 22:00 Friday to 4:00 Saturday in New York. The public press release the company posted on its site that same day spoke of "a nine-hour precautionary shutdown window this weekend, in their local time zone".
Adjusting for time zones explains why the absolute hours differ by country; it does not explain a different duration. Sophos researchers, who saw the reports that same day, described the window as "between 02:00 and 08:00 UTC on September 26, if not sooner": six hours again. Three of the four sources say six; the one saying nine is the public one. Nobody made the figure up, but it is the one that reached the headlines, and it is not the one the people on the other side had to carry out.
The rest of the advisory is unambiguous, and that is the part that matters for your plan:
- →It covered self-managed deployments —on-premises, on AWS and on Azure— and also those hosted by the company itself, where the customer had nothing to do. And it asked for systems to be switched off even if they were not reachable from the internet, which is another way of saying there was no way to scope it by exposure.
- →There was no CVE, no patch and no indicators of compromise published. The company pointed to its current release — "all known vulnerabilities are addressed in current release 9.5.1" — which is another way of saying there was nothing known to apply.
- →Kiteworks stated it had no indication that its systems or its customers' were compromised, and that the advisory was "preventative rather than a response to a confirmed breach". On 27 September it lifted the recommendation for all customers.
One more detail, which explains why the market took an email with no CVE seriously: Kiteworks was formerly known as Accellion, and Accellion's file transfer platform was one of those swept up in mass extortion campaigns. The industry knows how that film ends, and that is why thousands of companies powered down over a Friday email.
Somebody has to sign it, and that somebody is not the on-call engineer
A patch advisory gets resolved in the maintenance window and is signed off by whoever runs the platform. With a shutdown advisory the chain gets improvised: the engineer calls the IT manager, the IT manager goes looking for the board, the board asks how much real risk there is, and the only honest answer available is "we do not know, there is no CVE". By then half the window is gone.
Jake Knott, of the security firm watchTowr, summed it up in Computer Weekly: "There is no known CVE, patch, or additional technical details available – but nobody requests that their entire customer base to unplug production systems over the weekend because of a hunch" [sic]. Both halves of that sentence are true at once: the information was not enough to assess and enough to worry.
The one who did sign was Balonis, and he put it in writing on 28 September, once it was all over: "Telling customers to take production systems offline is not a decision any vendor makes lightly, and we knew exactly what we were asking of them […] We would make the same call again tomorrow." That is the sentence of someone whose authority was clear before he needed it. That is the whole difference, and it cannot be bought: it gets written while things are calm. Not the list of actions — you already have that in the continuity plan nobody has probably rehearsed — but the three lines that come before the actions: what quality of information we accept as grounds to stop, who authorises it, and who gets told. Written on an ordinary Tuesday, they save you the Saturday argument.
In August we covered the flip side of this same coin: your servers can be switched off by somebody you have no contract with, when a failure at your provider's provider's data centre pulls machines out of service without asking you. Here the button is yours and you press it voluntarily. The discomfort runs the other way and the governance gap is identical.
The hours powered off have a gap, and your users fill it
This part appears in none of the write-ups, and it is what would worry us most if the advisory landed on one of our customers tomorrow. When you switch off the platform people exchange files through, the work that depended on it is still standing. If there is a delivery committed for Monday, somebody will send that file anyway, and they will send it however they can: their personal email account, a free transfer service, a USB stick. You have contained a hypothetical risk and opened a real one that, on top of everything, leaves no record anywhere.
A well-executed precautionary shutdown includes the substitute channel, and includes it in writing and by name: which one it is, who authorises it, what size and sensitivity limits it has, whether it is encrypted, where the record ends up and when whatever was uploaded there gets deleted. It looks like bureaucracy right up until the alternative turns up in somebody's personal inbox. And if the honest answer is "we have no other channel", that is also an outcome of the exercise, and it changes the conversation: from security to design.
Shutting down has a procedure; starting up has more
We run Proxmox VE with Ceph in production and handle backups with Proxmox Backup Server and Veeam, so this part comes from the keyboard. Following an advisory like the Kiteworks one means logging into the appliance and shutting it down from inside, and that is where three things bite during an unrehearsed weekend stoppage.
- 1High availability does its job, and its job is the opposite of yours. If you stop the machine from Proxmox itself —
qm stopor the button in the interface— the requested state becomesstoppedand there is no surprise. If you shut it down from inside the guest, which is exactly what a vendor advisory asks for, the manager sees a service instartedstate that has stopped running and brings it back up. Before you log in:ha-manager set vm:100 --state stopped. - 2That night's backup runs anyway. Copying a stopped machine is as disk-consistent as it gets; the problem is application consistency, when the service halted halfway inside a machine that is still alive. And there is a second-order effect people forget: a whole weekend of backups of a powered-down system pushes the good restore points out of retention. Decide beforehand: either disable it that night, or label it.
- 3Monitoring will scream, and rightly so. Without a maintenance window declared in Zabbix (or whatever you use) before stopping, the on-call rota gets dozens of alerts about an incident you caused. And watch the detail: in Zabbix maintenance suppresses the problem, but notifications only go quiet if the action has "Pause operations for suppressed problems" ticked.
And start-up is where the real dependency inventory shows up. Nobody discovers that the application needed the database up thirty seconds earlier until they bring both services back at once on a Sunday. If you are going to stop as a precaution, the order on the way back is as much part of the procedure as the order on the way out, and the cheap way to learn it is on a machine that does not hurt.
What they found inside the window
The end of the story is the part least told. Over the weekend, working with the authorities, Kiteworks found and fixed a critical vulnerability that had not been known before. According to what was published on 29 September, it was "confined to a capability that is enabled for less than 1% of the customer base", there is no evidence it was ever exploited maliciously, and as of that date it had no CVE assigned.
It is easy to read that figure as a criticism: over 99% of customers stopped production over something that did not affect them. We read it the other way round. At the moment of deciding, nobody — not even the vendor — could separate the 1% from the rest, because granularity always arrives after the finding. What the case shows is that continuity decisions get taken on incomplete information, and that a plan which only works once you know what is happening is not worth much.
There is also an asymmetry we have already measured in another case, and here it came out well by a narrow margin: stopping is fast, coming back is not. Two weeks ago we wrote about an intermediary that took 101 minutes to disconnect a supplier and nine days to reconnect it. Kiteworks lifted its advisory in two days. Next time somebody asks you to switch off "for a few hours", the useful question is not how many: it is who decides you can come back, and on what check.
The page your plan is missing
All of this fits on one page and comes out of a one-hour meeting, provided the people who can actually decide are in it. For every platform you genuinely depend on, that sheet has to answer four things, and none of them is technical.
Who. A name and a deputy, and up to how many hours they can sign for without escalating. "We would all decide together" is not an answer; on the Saturday it means nobody decides.
On what. What evidence is enough: a vendor email with no CVE? a CERT advisory? only with indicators? Written down beforehand, because the improvised criterion ends up being whoever is most rattled.
How work carries on meanwhile. The authorised substitute channel, with its limits and its logging, and who tells customers the usual place will not answer during those hours. If you do not say it, they will interpret it.
What gets checked on the way back. A shutdown contains, but it does not investigate: if something was inside, it is still inside when you power on. Reviewing access, new accounts and scheduled tasks before opening the service to the world is the half of the procedure almost nobody writes down.
What we are not claiming
- ✗We do not know whether the flaw they found is the one the intelligence warned about. Nobody has said so publicly; the company itself has given no technical detail on the flaw. The two facts coincide in time, and that does not prove they are the same one.
- ✗There was no confirmed breach. The company stated it had no indication of compromise in its systems or its customers', and its monitoring during the window showed no abnormal activity. This post is not about an attack, but about how the call gets made.
- ✗Nor are we saying shutting down is the right default. For most advisories it is not. What we argue is that the decision should be written down before the email arrives, and that it should cover how work carries on meanwhile.
Sources (verified on 30 September 2026): the nine-hour window in local time zones, the scope (on-premises, AWS and Azure, plus hosted instances), the reference to release 9.5.1 and the statement that there is no indication of compromise — Kiteworks, "Precautionary Shutdown Advisory", 25 September 2026; the six hours in the customer email, the per-time-zone windows, the request to switch off systems not reachable from the internet, and the credit to Heise as the outlet that published it first — BleepingComputer, 25 September 2026; the CISO Frank Balonis quote from the email, his further statement, Jake Knott's (watchTowr) sentence, the six-hour period on Saturday 26 and the company's former name — Computer Weekly, 25 September 2026; the 02:00–08:00 UTC window on 26 September and the Counter Threat Unit's advice to follow the vendor's guidance — Sophos; the restoration of systems, the absence of abnormal activity during the window and the Balonis quotes of 28 September — Kiteworks, 28 September 2026; the finding and fix during the window, the "less than 1% of the customer base", the absence of evidence of exploitation and of an assigned CVE, and the lifting of the advisory on 27 September — The Hacker News, 29 September 2026; the behaviour of the high availability manager — Proxmox VE documentation.
Who would sign off a six-hour stoppage in your company?
We sit down for an hour with whoever decides and whoever operates, and come out with that sheet written for your critical platforms. If needed, we then test it on a real one, which is when the dependencies nobody remembered show up. That is disaster recovery and, for the part about what gets reviewed on power-up, cybersecurity.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN