- › Coca-Cola suspended US production at its Fairlife dairy after ransomware, a brand estimated at $4 billion in sales by 2024.
- › The disclosure says production-related systems were affected. It does not say attackers reached the machinery, and the plant stopped regardless.
- › Most production halts after ransomware are precautionary. The business stops because it cannot prove the plant is clean, not because the plant is broken.
- › That makes your recovery time a function of what you can verify, and verification is an architecture decision you make before the incident.
- › Segmentation, a current asset inventory, and a tested manual-operations plan are what convert an indefinite shutdown into a measured one.
Coca-Cola disclosed on July 16 that a ransomware attack on its Fairlife dairy subsidiary affected “some of its systems, including its production-related systems,” and that production across its United States facilities is “temporarily suspended while the company responds to the incident and restores impacted systems” (BleepingComputer). Canadian operations kept running. Fairlife was estimated at $4 billion in sales by 2024 (TechCrunch).
Read that disclosure carefully, because of what it does not say. It does not say attackers encrypted a programmable logic controller. It does not say anyone reached the filling lines or the pasteurizers. It says production-related systems were affected and that production is suspended while the company restores.
Those are two different sentences, and the gap between them is where the money goes.
The Shutdown Is Usually a Decision, Not a Result
Picture what you expect when you hear that ransomware stopped a factory: an attacker reaching into the plant, seizing the machines, and halting the line. That happens, and it is the scenario every operational technology security program is built to prevent.
It is rarely what stops the plant.
A person stops the plant. Somebody senior gets told that ransomware is in the corporate network, and asks a simple question: can you tell me it is not in the plant? If the answer is anything other than a fast, evidence-backed yes, that person halts production. They are not being timid. They are making the correct call with the information they have, because the alternative is running a food production line on a network you cannot vouch for.
That decision is rational every single time. And it means your shutdown duration is not set by how good the attacker was. It is set by how quickly you can prove a negative.
You can spend years hardening the plant floor and still lose a week of production to an incident that never came within three network hops of it, because nobody could demonstrate that fast enough to keep the line running.
Why “Production-Related Systems” Covers So Much Ground
The phrase in the Coca-Cola disclosure is doing a lot of work, and it is worth unpacking for your own environment. Production-related does not have to mean the machines. In most plants it includes:
- The manufacturing execution system (MES) that tells the floor what to run and in what order.
- The enterprise resource planning (ERP) system that holds the orders, the bills of material, and the inventory positions.
- The warehouse management system that knows where the pallets are.
- Quality and lab systems that hold the test results you legally need before product ships.
- Labeling and coding systems that print lot codes and expiration dates.
- Scheduling, time and attendance, and shipping paperwork.
Every one of those lives on the corporate network, in the information technology (IT) estate, not behind the plant firewall. And every one of them can stop production cold while the machinery sits there in perfect working order.
A dairy is a useful example precisely because the constraint is not mechanical. If you cannot generate a lot code, you cannot ship. If you cannot pull a quality result, you cannot release. If you cannot confirm which tank holds which batch, food safety says stop. The line is fine. The paperwork is gone, and the paperwork is the product’s permission to exist.
Key point for owners: ask your plant manager which systems, if unavailable for 72 hours, would force a stop. Most of the answers will be in IT, not on the floor. That list is your real production dependency map, and most businesses have never written it down.
The Business Math Nobody Runs Until It Is Too Late
Every operator I work with can tell me their cyber insurance premium. Very few can tell me their cost per hour of stopped production. That asymmetry is the whole problem, because the second number is the one that decides how much the first one should be.
Run it honestly for your own operation:
- Direct output loss. Units per hour times margin per unit. This is the easy one, and it is the one people stop at.
- Spoilage and scrap. In food, chemicals, or anything with a cure or cold chain, an unplanned stop destroys work in progress. Product in a tank at hour zero is waste by hour twelve.
- Restart cost. Lines do not resume by flipping a switch. Clean in place, requalification, first article inspection, and the yield loss on the first runs after a cold start.
- Contract exposure. Service level penalties, missed delivery windows, and the retailer that charges you for the empty shelf space.
- Shelf position. This is the one that outlives the incident. A competitor’s product sits in your slot for three weeks, shoppers try it, and some fraction never comes back. That loss does not appear on the incident report and it never fully reverses.
- Labor. You are paying a shift that cannot produce, or you are sending them home and paying the retention cost of the ones who find other work.
Add those up per hour, multiply by a realistic outage window, and you have the number that should govern your security budget. For most mid-sized manufacturers I have seen, the honest total lands high enough that segmentation work paying for itself in a single avoided day is a routine result, not a stretch.
The reason this matters: security investment framed as “reducing risk” loses every budget argument to something with a return attached. Security investment framed as “cutting a seven-figure outage down to a six-figure one” wins, because it is the same kind of math the rest of the business already runs.
Segmentation Is a Business Control, Not a Network Diagram
Network segmentation gets filed as a technical project, which is why it stalls. It belongs in the operations budget, because what you are buying is not tidier architecture. You are buying the ability to answer the executive’s question fast.
Segmentation converts an unbounded question into a bounded one. Without it, “is the plant affected?” requires investigating everything, because everything can reach everything. With a real boundary between IT and operational technology (OT), the question becomes “did anything cross this one documented path, and what does the log say?” That is a question with an answer, and you can get it in hours instead of days.
That is the return. Not fewer incidents, though you will have fewer. A shorter, cheaper, more defensible version of the incident you were always going to have eventually. We laid out the layered model this sits inside in our ransomware prevention framework, and the plant-floor specifics in our guide to OT security for critical infrastructure.
The same logic explains why the cyber and physical sides cannot stay in separate rooms. A ransomware event becomes a physical operations event within about an hour of the first alert, and if your cyber incident commander and your plant leadership meet for the first time during that hour, you are already losing. That is the practical case underneath a converged security operations center: the decision to stop or keep running is made by both, or it is made badly.
Where Phoenix Operators Should Look First
The Valley has become a manufacturing region, and a lot of the exposure here is newer than the security programs around it. Semiconductor fabrication and its supplier base, food and beverage production, the aerospace suppliers around Mesa and Goodyear, the cold chain moving through the I-10 corridor, and the data centers everyone else depends on.
Two things make our situation specific.
Heat is a hard constraint. An unplanned stop in a Phoenix summer is not the same event it is in a temperate climate. Cold chain has less margin for error, product in process degrades faster, and the equipment you restart has been sitting in ambient conditions that machinery in Ohio never sees. Your outage tolerance is genuinely shorter here, which means your recovery capability has to be genuinely better.
Growth outran the architecture. Most Valley operations that expanded over the last decade added capacity by adding equipment to whatever network was already there. The result is a flat network holding a modern plant, built by people solving an urgent problem correctly at the time. Nobody made a bad decision. The decisions just accumulated, and the resulting blast radius is the thing nobody ever sat down and drew.
What To Do About It, In Order
This is where the assessment earns its keep, because none of the above tells you what is true in your specific building. Generic advice does not survive contact with a real plant. But the sequence is consistent:
- Map the production dependency chain. Every system that has to be available for product to ship, whether it lives in IT or OT. Most operations have never written this down, and writing it down is free.
- Find the paths. Every route between the corporate network and anything that touches production. Include the ones you did not sanction: the vendor’s remote support tunnel, the engineering laptop that goes both places, the historian pulling data out to a dashboard, the wireless the contractor stood up.
- Price the hour. Do the math above. Get a real per-hour number and put it in front of whoever approves budgets. Everything after this is easier once that number exists.
- Cut the paths you do not need, control the ones you do. A documented, monitored, authenticated boundary. Nothing exotic. The goal is a small number of known doors instead of an unknown number of open ones.
- Write the manual operations plan, then test it. What can you run without the MES? What can ship on paper? Which quality checks have an offline path? An untested plan is an assumption.
- Rehearse the decision, not just the response. Put your plant manager and your incident commander in a room and run the scenario. Who decides to stop? What evidence would let them keep running? How fast can that evidence exist? Get the disagreements out now, when the answer costs a meeting instead of a week.
Do not wait for the incident to discover these answers. Every item on that list is cheaper to do on a normal Tuesday than at 3am with a ransom note on a screen and a plant manager asking whether to keep the line up.
The Takeaway
Coca-Cola will be fine. A company that size absorbs a suspension, restores its systems, and moves on, and the specific facts of this incident will look different once the full picture emerges.
Your operation may not have that cushion. And the lesson from Fairlife does not depend on how the details land, because the mechanism is the same everywhere: the attacker does not have to reach your machines to stop them. They only have to reach far enough that you cannot prove they did not.
That distance is something you control. It is set by your architecture, your inventory, and your ability to answer one question quickly under pressure. All three are decisions you make long before anyone asks.
If you run a facility in the Valley and you cannot currently say how far a ransomware event in your office network could reach toward your plant floor, that is the gap worth closing first. Contact Grab The Axe for a converged assessment that looks at both halves, or start with our free Human Attack Surface Score to see where the paths into your organization actually run.
A leader defined by a 'bias for action,' Dusten specializes in physical security assessments that impact profitability. He leverages high-logic strategies to pinpoint high-ROI vulnerabilities, ensuring defense measures actually scale with the business.
View Author Page →
