For Windows administrators, the uncomfortable question is straightforward: which systems on your server inventory also belong in your production-risk assessment? A manufacturing execution server, its virtualization host, or an authentication service may have an IT owner while carrying consequences that reach well onto the factory floor.
A production outage is not proof of controller compromise
Fairlife provides a concrete example of disruption, but not a publicly established technical attack path.
In its July 27, 2026 update, Coca-Cola said its dairy subsidiary had resumed the majority of production at its four U.S. facilities following a ransomware event. The company confirmed unauthorized access to part of its systems, the taking of certain data, and a temporary production suspension. It also said product quality and safety were unaffected, while existing inventory had largely protected retail availability.
That statement does not identify a compromised programmable logic controller, manufacturing execution system, or hypervisor. It therefore supports a narrower conclusion: a cyber incident interrupted production, but the disclosed facts do not establish precisely which technical dependencies failed.
Dragos’s broader research explains why that distinction matters. Its Q2 2026 analysis identified 1,140 ransomware incidents affecting industrial organizations worldwide, including 747 in manufacturing—approximately 65%. Those figures draw on publicly disclosed victim information and ransomware-group leak-site postings; they should not be read as 1,140 independently confirmed production shutdowns.
Within the cases it observed that quarter, Dragos reported no direct control-system manipulation by ransomware operators. Where operational disruption occurred, it followed encryption or precautionary shutdown of enterprise and virtualization systems supporting OT. That is a quarter-specific observation, not a claim that controllers are never attacked.
The practical distinction: controller compromise and production disruption are different outcomes. A security program needs to anticipate both.
Why a Windows system can be production-critical
Witucki’s argument is fundamentally about scope. An inventory can be technically accurate yet operationally incomplete if it records controllers but overlooks the systems supplying their work orders, operator access, or supporting infrastructure.
Dragos calls its broader approach extended operational technology, or xOT. Rather than classifying equipment solely by operating system, ownership, or device category, the framework asks whether it can influence a physical process. Dragos illustrates the problem with a Windows-based human-machine interface: familiar software does not make the machine’s operational role any less significant.
The printer example makes the distinction particularly clear. A printer producing nonessential reports has a different operational consequence from an otherwise similar printer producing labels without which a packaging line cannot run. The important property is the dependency, not the device badge.
However, xOT should be identified as Dragos’s terminology and framework, not presented as a universally adopted standard. Dragos also markets commercial security products around it. The useful assessment question does not require buying into a particular platform.
There is independent support for looking beyond traditional controllers. NIST’s Guide to Operational Technology Security, SP 800-82 Revision 3, explicitly identifies control-network dependence on IT-hosted DNS and DHCP services as a potential vulnerability: the supporting IT network may not meet the reliability and availability requirements of OT.
In other words, the dependency problem exists whether an organization adopts the xOT label or simply calls it production resilience.
Turn the walk-through into a dependency map
Witucki recommends bringing the plant manager and IT lead onto the floor together. A useful way to structure that exercise is to produce a shared dependency record—not merely a longer equipment list.
The following workflow synthesizes his operational-impact test with NIST’s inventory and data-flow guidance:
- Start with a production function. Identify the line, process, or quality check being supported. Ask what happens if each connected system becomes unavailable or behaves incorrectly.
- Trace supporting systems. Follow the manufacturing execution terminal to its server and virtualization host. Establish whether operator access depends on Active Directory. Include vendor gateways and cellular support connections in the assessment rather than assuming another team has them covered.
- Record responsibility alongside technology. Capture the asset identifier, location, software or firmware version, operational role, and responsible teams. NIST specifically recommends documenting asset ownership and operational, maintenance, and cybersecurity responsibilities.
- Map necessary communications. Document which systems exchange data and why. NIST notes that data-flow diagrams help establish expected network behavior and support troubleshooting, incident response, and recovery.
- Review protection against operational consequences. Use the resulting map to assess segmentation, remote access, and monitoring. A system should not fall out of production-security planning simply because IT maintains it.
Success is a record that explains what production depends on, who is accountable, and which protections require attention. Adding an “OT” tag alone is not the outcome.
Discovery must not become the outage
There is an important caution for administrators accustomed to automated enterprise discovery: do not treat this exercise as permission to scan every production subnet indiscriminately.
NIST warns that active scanning and some automated mapping methods can negatively affect OT systems. It recommends testing asset-management tools on offline systems or components before deploying them in production, and considering manual inventory processes where automation is unsuitable.
Likewise, bringing supporting systems into scope should not mean applying identical settings to every asset. NIST’s guidance explicitly accounts for OT’s distinctive performance, reliability, and safety requirements. The sensible objective is coordinated protection appropriate to the process—not a copy-and-paste security baseline.
The strongest lesson is therefore organizational as much as technical. Keep ownership clear, but assess dependencies across ownership boundaries. The next production-critical system may already be on the Windows team’s inventory; the missing field is what happens to the factory when it disappears.