When the System Goes Dark, Can You Still Ship?

Boston Scientific has been working through a cyberattack since August 25. The lesson isn't about hackers. It's about what your operation can still do the day the ERP isn't there.

By Rodolfo Kong | ARMKU LLC | September 2026

On August 25, 2026, one of the world's largest medical device makers discoverediscovered its network had beehad been compromised. Within hours, Boston Scientific had a network outage, manufacturing was disrupted, and the company could no longer process or ship customer orders. Not "slower." Could not. A week later, shipping was returning to the major distribution centers, but the company's own words in its September 3 update are worth reading twice: "It will take time to work through the existing backlog of orders," and "Timeline for full restoration is not yet known."

These are pacemakers and stents. The hospitals that order them did not stop having patients. And the one thing that kept working, according to the company, was that they could still take orders electronically via EDI and queue thequeue them. Intake survived. Everything after intake did not.

I don't know what happened inside Boston Scientific's network, and neither does anyone writing about it this week. But I have run operations long enough to know the part of this story that is not about security at all. It is about what a company can still do with its hands when the screen goes blank.

The lie we tell ourselves in the budget meeting

Every operations leader has heard some version of "we have backups" or "IT has a plan for that." I have said it myself. It sounds like an answer. It is not.

A backup restores your data. It does not restore your operation. Between "the data exists somewhere" and "a truck left the dock with the right product on it," there is a chain of people, screens, printers, scanners, carrier integrations, and approvals that all assume the system is up. When it is down, most companies discover that nobody under the age of forty has ever shipped an order without it, and nobody over forty remembers how.

That is not an IT problem. It is an operations problem wearing an IT costume. And the more integrated your ERP is, the bigger the costume. The same integration you bought because it connects order to pick to ship to invoice in one flow means that when the flow stops, everything stops at once.

What the data actually says

This is not one unlucky company. Manufacturing has been the most attacked industry in the world for five straight years. IBM's 2026 X-Force Threat Index puts manufacturing at 27.7% of all incidents it responded to last year, and reports that active ransomware and extortion groups grew 49% year over year. Nobody is safer in 2026 than they were in 2025.

Look at what a stopped plant actually costs. When Jaguar Land Rover was hit in September 2025, production stayed down for roughly five weeks. The estimates that circulated were around £50 million per week for the company, and about £1.9 billion in total damage to the UK economy, including the supply chain. That second number is the one I keep coming back to. Suppliers that had done nothing wrong were laying off people within weeks, because their only customer stopped calling for parts.

In July of this year, Coca-Cola suspended U.S. production at its Fairlife dairy unit after a ransomware attack. A billion-dollar brand, and the plants stoppeplants stopped. Now Boston Scientific. Three companies with security budgets larger than most of my clients' entire revenue. If it can happen to them, the question for the rest of us is not "will it happen?" It is "what do we do on day one?"

The operator's read

Twenty years ago, a warehouse could ship from a printed pick list and a phone call. That resilience was not a strategy. It was an accident of how little was integrated. We have spent two decades removing that accident on purpose, and for good reasons: fewer errors, faster cycles, real-time inventory. But we removed the fallback along with the friction, and nobody wrote down what to do when the single system everything runs through is the thing that fails.

One detail from Boston Scientific is worth holding onto. The incident hit certain on-premises systems. Cloud-based applications, according taccording to the compancompany, were not affected. That is why order intake kept working while fulfillment stopped. The boundary between the two systems decided the size of the damage. Most mid-sized companies have no such boundary. One server, one database, one login for everything. Convenient, right up until the day it isn't.

The operational translation

None of this requires buying a security product. It requires the same discipline you would apply to any other operational risk. Here is where I would put the energy, in order:

• Write the day-one list. The ten things that must keep happening if every screen goes dark tomorrow morning: take orders, ship what is already picked, receive critical materials, pay people, tell customers the truth. For each one, a manual procedure on paper, with names on it. If the procedure exists only in the ERP, it does not exist.
• Separate intake from processing. Boston Scientific could still take orders because that channel did not live on the same systems that went down. Your customer-facing intake, your web shop, your EDI, your inbox, should survive your back office failing. Test it by unplugging the back office, not by reading the architecture diagram.
• Restore, don't just back up. A backup you have never restored is a hope. Run a timed restore onto clean infrastructure once a year, and recorrecord the number of hours. If nobody in the company can say how long it takes to get from "dark" to "working," you do not have a recovery plan. You have a file.
• Put a wall between the plant and the office. Machines, controllers, and warehouse devices should not share a network, credentials, or a domain with the laptops used to accesused to access email. That wall is what turns a company-wide outage into a department-wide one.
• Ask your suppliers the same questions. JLR's suppliers went down with JLR. If one vendor is your only source for a critical part, their recovery plan is your recovery plan. Ask your top twenty for theirs. The silence you get back is data.
• Decide now who can say "ship anyway." In the first hours, someone has to decide whether to ship from paper records and reconcile later, or hold and protect the data. That call is much easier to make on a calm Tuesday than at 3 a.m. with a customer on the line.

Every one of these is a two-week project, not a two-year one. Every one of them was cheaper last year than it will be next year. None of them show up in a vendor demo, which is exactly why they get skipped.

If your operation runs through one system, and most do, the honest question is not whether that system is secure. It is whether your people can run the business for a week without it. That is the work we do with clients at ARMKU: mapping what has to keep moving, testing the recovery with a stopwatch, and writing the fallbacks before they are needed. If that question has been sitting in the back of your mind, let's talk before it becomes a phone call.