The Containment Tax: When OT Outages Aren't OT Attacks

Quick answer: Boston Scientific disclosed on September 8, 2026 that a cyberattack detected on August 25 disrupted manufacturing and order fulfillment for roughly two weeks, enough that the company no longer expects to meet its third-quarter and full-year guidance. The company has said the intrusion was limited to on-premises IT systems. Production stopped anyway, because several systems a plant depends on to run a shift - order release, scheduling, quality, identity - sit in enterprise IT and were taken offline to contain the incident. Many OT security programs secure the controllers but never fully map those dependencies. That gap is the containment tax.

What actually stopped at Boston Scientific

Boston Scientific detected unauthorized activity on its IT systems on August 25 and responded the way most companies would: it took affected systems offline while it investigated. That decision cut employees off from the applications they use to process and ship orders, and the effect reached the plants the same day. Staff at the company's Cork, Ireland site were sent home on August 25 because the systems their shift depends on were unavailable. Two weeks later, on September 8, the company told investors in a Form 8-K that it no longer expected to meet its third-quarter and full-year 2026 net sales growth and adjusted EPS guidance, with a revised outlook to follow with its third-quarter results on October 28. It added that it does not expect a material impact on its long-term financial condition. On September 9 it reported that manufacturing, order fulfillment and shipping were fully restored.

What makes this incident worth studying is how little the attacker appears to have done relative to what it cost. In an August 30 update the company said the unauthorized activity was limited to certain on-premises systems, that its cloud systems were unaffected, and that investigators had found no indication of unauthorized activity in its environment after August 25. The attacker was contained within a day. The outage ran for two weeks and forced a revision to guidance.

The company's own description of what went down is the most useful sentence in the record. It listed the affected systems as operational technology support functions and the business applications required to manufacture products, process customer orders, and ship devices. Nothing in the public record says a controller, an HMI, or anything on the plant network was touched. On the record this is not an OT compromise; it is an OT outage, caused by an IT containment decision. For the people running the line, that distinction did not change what the outage cost. It does change what would have prevented it.

Two halves of securing a plant

Most of the conversation about OT security, including a good share of what we have published, is about one problem: protecting the equipment that touches the physical process. Segmenting the controllers, brokering vendor remote access, inventorying devices that cannot take an agent, watching the engineering workstations that program the PLCs. That work is still needed and most plants are nowhere near done with it. But it is one half of securing a plant floor, and it addresses only one of the two ways a plant fails. The other half is staying available. Boston Scientific's outage came from the second half, while the first half, as far as anyone has said, held.

Consider what a plant needs to run a single shift. An order has to be released from the ERP and a schedule has to reach the MES. Materials are issued and lots are traced. In a regulated medical device plant, sterilization and quality release have to be scheduled and recorded before anything ships. Labels print from a system that pulls from the ERP, and operators log in against a directory service. It is very common for all of these services to live in, be operated by, and be connected to the IT space. They serve the plant floor, though not always solely, and they are serviced by internal IT resources rather than the plant team. Boston Scientific called them "OT support functions." CI Fortify, the joint isolation guidance CISA and its international partners published in July, calls them enabling systems. Either name is fine; what matters is that they get counted.

In the Purdue reference model that most OT architectures still map to, the physical process and its controllers sit at Levels 0 through 2, plant operations systems like MES and historians at Level 3, and the enterprise systems above them at Level 4. OT security programs are usually scoped to the lower levels, and for good reason: that is where the safety and integrity risk lives. The systems at Level 3 and above play a dual role that is easy to miss. To the IT organization they are business applications with an uptime SLA. To the plant they are production infrastructure, and when one is offline the line stops just as surely as if a controller had failed. Neither team is wrong about its scope. The gap is a shared understanding of which systems play both roles, and what the plant looks like when one of them is deliberately switched off.

The half of CI Fortify that gets overlooked

CI Fortify, published July 28, 2026 by CISA, ASD's ACSC, the FBI, NCSC-UK, and the Canadian Centre for Cyber Security, is titled Advice for Isolating Vital Systems. Its scope, stated on the first page, is vital OT and enabling systems. Operators are asked to record every interconnection between those systems and the corporate network, vendors, and cloud services, to mark the isolation points, and to test isolating all vital systems together, because testing one system at a time will not surface the dependencies between them.

Much of the industry's response, including our own When "Prepare to Disconnect" Becomes Official Guidance, concentrated on the first half of that scope. We wrote about flat plant networks that have no pre-built isolation points to execute, and about making isolation a tested policy rather than an emergency improvisation. That post also drew a boundary we can now put a name to: isolating quickly and operating in isolation for an extended period are two different capabilities, and while a kill switch answers the first, the second depends on knowing which enabling systems the plant needs and whether it can run without them.

The Boston Scientific outage is the problem that second capability exists to solve. The guidance itself warns that disconnecting will stop equipment that was never damaged if authentication, name resolution, or other required services sit outside the isolation boundary. That is a fair description of a medical device plant with the ERP and the directory turned off. The enabling-systems half of CI Fortify is the half that would have mattered here, and it gets overlooked partly because there is no sensor or appliance that addresses it. It is an architecture and dependency-mapping problem, which makes it harder to sell as a product and easier to postpone.

The containment tax, measured

Boston Scientific is one instance of a pattern that has been visible for years. Set aside the genuine OT compromises - the 2017 Triton attack on safety controllers at a petrochemical plant, or the December 2025 wiper attack on Poland's energy sector that damaged remote terminal units at more than thirty wind and solar sites - and look at the incidents that made "OT" headlines without any operational technology being attacked. They sort into two groups.

• Precautionary shutdown, OT untouched. Colonial Pipeline in 2021 shut the pipeline for about six days, reportedly over concern about its billing systems rather than its control systems. Toyota idled fourteen plants for a day in 2022 because a parts supplier, not Toyota, had been hit. Nucor in May 2025 disclosed that, in an abundance of caution, it had proactively halted certain production operations at various locations while it took potentially affected IT systems offline.
• Dependency collapse: plants fine, product can't ship. Clorox in 2023 fell back to manual order processing, reported significant product outages, and booked $49 million in costs by year end. Asahi in 2025 lost its ordering and shipping systems in Japan; a company spokesperson told AFP that production was not directly affected but had been halted because shipments were suspended, and shelves ran short of beer. Jaguar Land Rover in 2025 stopped production for roughly five weeks after an IT shutdown and needed a £1.5 billion government-backed loan guarantee to stabilize its supplier base. Boston Scientific joins this group.

In each case the number that showed up in the disclosure was not dwell time or the attacker's reach. It was the gap between how long the intrusion lasted and how long the outage lasted. At Boston Scientific that gap is roughly one day against fifteen: the last unauthorized activity the company has reported was on August 25, and it declared operations fully restored on September 9.

That gap is the containment tax: the cost of the only containment option the architecture allowed, which took plant availability down with it even though the attacker never caused that directly. The tax has several line items. Lost production days are the visible one. Behind them sit the cost of running manual processes, the backlog and expedite costs once systems return, the rebuild and validation effort in a regulated environment, and in this case a public revision to guidance. Every one of those was paid whether or not the attacker ever intended to reach a plant, because the architecture gave responders one option, and it disconnected the plant along with the compromised systems.

Isolating the enterprise without isolating the plant

The tax is paid because containment in most environments is binary. Once an intrusion is confirmed in enterprise IT, responders have one action that is guaranteed to work, and it takes the plant's dependencies down as a side effect. More detection on the plant network does not change that calculus; a sensor there would have reported a healthy, idle plant for two weeks.

What changes the calculus is enforcement at the seam where the plant meets the enterprise. In Purdue terms that seam is Level 3.5, the industrial DMZ, and in most plants it is a firewall pair with a route table behind it. Once an enterprise incident is confirmed, the only containment available is to close that boundary, and every Level 3 system that depends on Level 4 goes down with it. Zero Trust Branch replaces that boundary with policy. Deployed at Level 3 and 3.5, it brokers each flow between the plant's operations systems and the enterprise - MES to ERP, quality release to the directory, label printing to the order system - as an explicit, identity-based connection through the Zero Trust Exchange rather than an implicit path across a DMZ. Two things follow. A containment action can be scoped to the tier that is actually affected, because there is a specific policy to revoke rather than a whole boundary to close, and the plant's paths to the enabling systems it still needs are defined connections that can be kept open while the rest of the enterprise is cut off. Zero Trust Segmentation applies the same principle inside Level 3 and below, so a compromise that does reach an operations system cannot spread to the controllers, and Privileged Remote Access brokers the contractor paths into both layers, one of the most common entry points in industrial incidents. None of this maps the dependencies for you or decides which enabling systems are vital; that remains the operator's work under CI Fortify, and it is the input that makes scoped containment possible. 

Run the dependency test

Pick one plant and one shift. List everything that has to be up for that shift to release product, then mark each item as living on the plant floor or in enterprise IT, and for each enterprise item write down what happens to the line if it is offline for a day. The list is usually longer than expected, and the enterprise items on it have often never been in scope for the OT security program, not through anyone's neglect but because the dual role of those systems was never written down. That list is your CI Fortify connection map, and it is also the scope of your next containment decision.

If you would rather work through that exercise with someone who has done it before, request an OT architecture workshop and we will map vital systems, enabling systems, and isolation points against the CI Fortify model with your team.