Security at the OT/IT Boundary: Protecting the Rig's Network as Models and Data Cross It
Every data path this series has drawn crosses the same line: the boundary between the rig's operational network and the outside IT world. That line is a trust and cybersecurity boundary as much as it is a control-authority one, and each crossing has to be designed to respect it.
Figure 1. The rig's operational network and the outside IT world meet at one boundary. Everything the series has moved across it - models, updates, refined data - crosses that same line. Illustrative.
📏 The line the whole series has been drawing
Across this series the picture has filled in one loop at a time. Standards moved rig data into a shared shape. High-frequency analytics moved decisions to the edge. A two-loop fabric carried refined information from rig to office and let models improve across a fleet without centralizing every rig's raw data. Each article added another path for something to travel: a trained model out to the rig, a model update back from it, decision-grade evidence out to the people who act on it.
Every one of those paths crosses the same line. On one side sits the rig's operational network: the sensors, the control system, and the edge that now runs analytics next to them. On the other side sits the outside world of enterprise IT and the cloud, where the office, the operations center, and the fleet-level model aggregator live. The industry calls this the OT/IT boundary, operational technology on the rig side and information technology on the office side, and the convergence of the two is the defining infrastructure story of digital drilling.
The earlier articles treated that line mostly as a control-authority boundary: the question of what a remote model is allowed to do, framed in the third article as a ladder from observe, to advise, to request intent, to command. This article makes the second claim that has been implicit all along. The same line is a trust and cybersecurity boundary. A path that carries a model or an update across it is also a path an attacker could use, and a boundary that governs authority has to govern access in the same breath. Naming each crossing, and the risk it carries, is what turns a diagram of data flows into a design that can be secured.
Figure 2. One line, four crossings. The trained model and the static engineering data move office to rig; the local model update moves rig to aggregator; refined evidence moves rig to office. Each crossing carries its own risk and the control that answers it. Conceptual architecture. WillCo analysis.
⚖️ Two worlds that do not share the same rules
The reason the boundary is hard is that the two sides weight their priorities differently. Traditional enterprise IT often gives greater weight to confidentiality and access control: keep data from the wrong eyes, and when in doubt, deny access. Operational technology has to weight availability, integrity, safety, and deterministic operation just as heavily, because the physical consequence of a stalled control system or a corrupted measurement is not an inconvenience, it is a well being drilled on bad information. A control network will often accept a patch late precisely because taking the system down to patch it carries its own operational risk. Those priorities overlap, but the operational consequences and the maintenance constraints are different, which is why security controls have to be adapted to the rig's operating context rather than copied unchanged from enterprise IT.
Figure 3. Enterprise IT and operational technology weight their priorities differently, which is what makes the boundary between them hard to secure. Framing per NIST SP 800-82r3. WillCo analysis.
Industrial cybersecurity handles that difference with structure rather than instinct, and it has a shared vocabulary for the structure. The most widely used organizing picture is the Purdue reference model, drawn from the Purdue Enterprise Reference Architecture, which arranges an industrial network into levels: the physical process at the bottom, basic control above it, area and supervisory control above that, site operations higher still, and enterprise IT at the top. The Purdue model is a reference model rather than a certification standard; the level hierarchy it made familiar is formalized in the ISA-95 / IEC 62264 standard for enterprise-control integration. Sitting between the operational levels and the enterprise levels is a construct that was not in the original model but is now standard practice: an industrial demilitarized zone, often called Level 3.5, a buffer that brokers traffic so that nothing on the office side ever holds a direct connection into the control network.
That buffer is the whole idea in miniature. The point of the boundary is not a firewall in the sense of a single wall with a single door. It is that the two worlds are designed not to touch directly: everything that passes between them is meant to be mediated, inspected, and constrained to exactly what the crossing is supposed to carry, and nothing else.
Figure 4. The Purdue reference model levels, with the Level 3.5 industrial DMZ between the operational and enterprise sides, and the ISA/IEC 62443 idea of zones connected by conduits. The level hierarchy is formalized in ISA-95 / IEC 62264; the zones-and-conduits framing and the security levels are from ISA/IEC 62443. Illustrative.
📜 The standards that name the boundary
Two bodies of published work carry most of the weight here, and both are worth naming precisely rather than gesturing at.
The first is the ISA/IEC 62443 series, the leading consensus standard for the cybersecurity of industrial automation and control systems. Its central design idea is to divide a system into zones, groupings of assets that share the same security requirements, connected by conduits, the defined communication paths between zones. Traffic that stays inside a zone is one problem; traffic that moves between zones through a conduit is where the controls concentrate. The series also defines Security Levels that describe resistance to classes of attacker capability, scaling from SL 1, protection against casual or accidental misuse, through SL 2 and SL 3, up to SL 4, protection against a sophisticated attacker with IACS-specific skills, extensive resources, and high motivation. Those levels are not a single traffic-ranking dial. A risk assessment establishes the target security level (SL-T) for each zone and conduit; the design is then evaluated for the capability it provides (SL-C) and the level it actually achieves (SL-A), and the three should not be treated as interchangeable. The value of that method is that it forces the decision to be explicit and risk-based: the target level for the conduit that carries a model onto the control network is set by the consequence of getting it wrong, not by assuming that any conduit outranks another, and 62443 gives a language for saying so.
The second is NIST Special Publication 800-82, whose current version is Revision 3, the Guide to Operational Technology (OT) Security, published in September 2023. Revision 3 broadened the guide from industrial control systems to the wider category of operational technology and added an OT overlay that tailors a catalog of security controls into baselines for low, moderate, and high-impact OT environments. For the boundary specifically, it is the standing reference for network segmentation and defense-in-depth in OT, and it is where controls such as unidirectional gateways sit in a recognized framework rather than a vendor pitch. NIST SP 800-82 Revision 3, published in September 2023, remains the current final guide. NIST released the initial public draft of Revision 4 on September 21, 2026, with public comments due November 30, 2026, so Revision 3 is the version to cite.
Neither document is a drilling document, and that is the point. The rig is a late and demanding entrant to a problem that power, water, and manufacturing have been formalizing for years. These standards continue to evolve, but the drilling-specific work is not inventing new security theory; it is applying this established structure to the specific crossings this series has drawn.
🔀 What crosses the line, and the risk on each crossing
The signature figure above named four crossings. Each deserves its own look, because the risk on each one is different and so is the control that answers it.
Crossing 1: the trained model, office to rig
In the two-loop fabric, a model trained or refined in the office is deployed onto the rig's edge to run next to the data. That deployment is a file, or a set of parameters, moving from the enterprise side onto or near the operational side. The risk is integrity: a model that is tampered with in transit, or a malicious artifact dressed up as a legitimate update, becomes code with influence running inside the operational zone. The closer that model sits to anything with control authority, the more serious the consequence of accepting a bad one. The first control is authentication and integrity of the artifact itself: the rig accepts a model only if it is cryptographically signed by a trusted source and verified on arrival, so that "where did this model come from and has it been altered" has a hard answer before the model is considered. A valid signature proves source and integrity, but it is not by itself the safety case: it does not prove the model is compatible with the rig, accurate for the current well state, or free of harmful behavior from an authorized-but-mistaken source. Signed verification is therefore one control in a chain. The rig should also confirm the model against a controlled registry and its provenance, check version and compatibility, validate it in a staged or shadow mode before it can influence anything, run it under restricted privileges, monitor its behavior, and keep a tested rollback path, with an explicit approval step before the model is promoted to live use.
Crossing 2: the static engineering data, office to rig
Alongside the trained model, a steady stream of static engineering data moves the same direction, from office to rig: the drilling program, the geological prognosis, offset-well data, the casing and mud programs, pore-pressure predictions, and the daily morning reports that frame each tour. This is reference information rather than executable code, and that is exactly why it tends to get waved through, because it looks like paperwork. It carries two distinct risks. The first is the integrity of the content itself: the crew and the engineers plan and drill against these inputs, so a prognosis, a program, or a pore-pressure prediction that is altered or spoofed in transit puts real decisions on false ground, and the consequence is a well-engineering and safety consequence, not merely a bad file. The second is that the delivery itself is an inbound path: documents and datasets moving from the enterprise side into the operational zone are a classic way to carry a malicious payload across the line, and an office-to-rig channel is attack surface whether it is carrying a model or a drilling program. The control is to treat this traffic as a governed conduit rather than a convenience. Route it through the Level 3.5 buffer rather than a direct office-to-rig connection, authenticate the source and verify integrity on arrival so that "where did this program come from and has it been altered" has a hard answer, and inspect and sanitize the files, through file-type validation and malware screening, before they are allowed into the operational zone. Then keep the data in its place: a program or a prognosis is reference for people and planning, not an input with control authority, so it informs the crew and the engineers without auto-configuring any control system, and version and provenance control tells the rig which revision is authoritative, with a human review step before it is acted on.
Crossing 3: the model update, rig to aggregator
The second loop of the fabric is federated learning: each rig trains locally and sends model updates, not raw data, to a fleet-level aggregator that combines them into an improved shared model. Exchanging updates instead of raw data reduces exposure, but it does not eliminate it, and the published risk taxonomy is explicit about how. The first risk is poisoning. In data poisoning a participant corrupts the shared model through manipulated training data; in model poisoning it does so through manipulated updates, and NIST identifies model poisoning as characteristic of federated learning precisely because clients submit local updates to the aggregating server. The second risk is confidentiality: the updates themselves can leak information about a participant's private data, which matters most in a cross-operator setting where several companies contribute to one model and none of them intends to expose its own wells to the others. The control is validation and governance at the aggregator, and the published taxonomy names the mechanisms rather than leaving them to "checked and weighed." The aggregator should authenticate each client, preserve the provenance of every update, screen for anomalous or poisoned contributions, and combine updates with a robust, Byzantine-resilient aggregation rule chosen for the threat model rather than a naive average that trusts every client equally. The candidate global model is then validated before release, the approved model is signed, and a rollback path is retained. Where the cross-operator confidentiality risk justifies it, privacy controls such as secure aggregation or differential privacy can be added, at a cost in model utility and complexity. NIST is explicit that these defenses reduce risk rather than remove it: a motivated attacker can bypass some of them, and accuracy tradeoffs remain, so governance is a continuing discipline, not a one-time setting.
Crossing 4: the refined evidence, rig to office
The first loop carries decision-grade information from the rig out to the people and systems that act on it. This is the highest-volume, most continuous crossing, and its risk is the plainest: most bidirectional network paths opened for outbound data also create a return channel unless the architecture enforces one-way transfer. A conventionally routed connection opened so that data can flow out is, by default, a connection an attacker could try to reverse, and the more such paths exist the larger the attack surface on the operational network becomes. The control here is the one the boundary was built for, and it is where the OT world has an option the IT world usually does not: enforce the one-way nature of the flow in hardware. A data diode, or unidirectional security gateway, is a device that is physically capable of passing data in only one direction. It lets operational data flow out to the historian, the office, and the fleet aggregator while making an inbound connection or command physically impossible, not merely disallowed by a rule that a misconfiguration could undo. NIST SP 800-82r3 presents unidirectional gateways as an OT network-architecture option, and where the requirement is genuinely one way and the consequence justifies it, a diode is the strongest control this crossing can have. It is not a universal fixture, though: a diode cannot carry acknowledgments, interactive remote support, or federated-update return traffic on the same conduit, so any crossing that needs return traffic belongs on a separate, tightly governed conduit rather than through the diode.
Figure 5. A decision aid for the outbound crossing: whether a path should use a hardware data diode depends on whether it needs return traffic and on the consequence of a reverse channel. Decision logic per NIST SP 800-82r3, which presents unidirectional gateways as an option. WillCo analysis.
🛡️ Defenses that respect both loops
The controls above can form a layered defense that works together, which is what defense-in-depth means in the OT-security literature: no single control has to be perfect, because the next one is behind it. Layering does not remove the need to choose, though. ISA/IEC 62443 and NIST both require controls to be selected and tailored to risk, and the required combination for any given crossing depends on that conduit's function, threat model, consequence, and operational constraints.
Start with segmentation. The zones-and-conduits model gives the rig's operational network its own security perimeter, separate from the office, so that a compromise of an office laptop does not put the control system one hop away from the attacker. Every crossing in the signature figure becomes a defined conduit with a stated security level rather than an ad-hoc connection, and the Level 3.5 buffer brokers traffic so the two sides are not directly connected. Then add the crossing-specific controls: signed and verified models on the inbound deployment path, verified and sanitized transfers for the static engineering data that travels the same inbound path, validated and governed aggregation on the update path, and a unidirectional gateway on the high-volume outbound path so the biggest surface is also the hardest to reverse. Around all of it sits governance: an explicit statement of what is allowed to leave the rig and what is allowed to arrive, so that "what crosses the boundary" is a deliberate list, not whatever the network happens to permit.
Figure 6. The whole architecture in five controls, each answering a specific crossing risk. Anchored in ISA/IEC 62443, NIST SP 800-82r3, NIST AI 100-2e2025, and ISA-95 / IEC 62264. WillCo analysis.
None of these layers breaks the two loops. Detection still runs at the edge; refined evidence still reaches the office; the fleet model still improves. The loops are the same; what changes is that each path across the boundary is now a governed conduit with a control matched to its risk, instead of an open connection whose security was assumed.
🚪 Security must never become a backdoor to control authority
There is one failure mode that matters more than any single attack, and it is the reason this article belongs in a series about autonomy rather than in a general security guide. The whole architecture is built to keep operational authority on the rig: the third article's ladder puts a remote model at observe or advise, and reserves command for the certified rig-control environment. A security design can quietly undo that.
The way it happens is not dramatic. A remote-access path is opened for a good reason, to push an urgent model update, to let a specialist see a live screen, to allow a vendor to troubleshoot. If that path is not held to the same authority boundary as everything else, it becomes a way for something on the office side to reach into the operational side and act. The convenience is real and the intent is legitimate, and that is exactly what makes it dangerous: an authority boundary that holds for the designed data paths but relaxes for the emergency one is not an authority boundary. The rule has to be stated plainly, and it is worth being clear about its status: this is the design principle WillCo applies to the architecture proposed in this series, not a clause of ISA/IEC 62443 or NIST SP 800-82. For this architecture, remote data and model paths do not grant command authority; command remains inside the certified rig-control environment. A crossing may carry information in either direction, and it may carry a model inbound under signature and verification, but no crossing, however it is justified, is designed to grant a remote actor the authority to command the rig. Security controls exist to enforce that boundary, and they must never be configured in a way that becomes the exception to it. This is distinct from authorized, certified remote control, which a later article may treat on its own terms; the line drawn here is against uncontrolled remote access becoming a silent control path.
Figure 7. The failure mode the rule guards against. A remote path opened for a good reason becomes a way to reach the operational side and act, unless data and models are allowed to cross but command never is. Illustrative scenario. WillCo analysis.
💡 The OT/IT boundary is where the series' two big ideas meet: what a remote model is allowed to do, and what an attacker could try to do. They are the same line, and a design that secures one without the other secures neither.
🎯 The takeaway
The convergence of operational and information technology is what makes digital drilling possible, and it also expands the number and the importance of the paths between the rig's control network and external systems. The series drew the data paths; this article names the line they all cross and the discipline that keeps crossing it safe. Divide the network into zones connected by governed conduits. Match each crossing's control to its risk: signed models and sanitized data inbound, validated aggregation on updates, a one-way gateway on the high-volume outbound flow. Govern what is allowed to cross at all. And hold one line above the rest: security may protect the boundary, but it must never become the path that carries control authority across it. The rig keeps command. The boundary is how it keeps it.
This is the fifth article in the WillCo drilling-data-architecture series. Read the full series and more analysis at willcodrilling.com.
📚 The series so far
From Rig Data to Drilling Autonomy: WITS, WITSML, ETP, and OSDU
Beyond WITSML: Turning High-Frequency Rig Data into Edge Decisions
One Rig Data Fabric: Connecting High-Frequency Edge Analytics to WITSML and Federated Learning
Reevaluating the RTOC: From Watching Screens to Intelligent Anomaly Detection
🔗 References and further reading
Industrial cybersecurity standards and reference models
ISA / IEC, ISA/IEC 62443 Series of Standards, International Society of Automation (ISA99 committee) and IEC. Source for the zones-and-conduits model and the four Security Levels (SL 1 to SL 4) referenced here.
K. Stouffer et al., Guide to Operational Technology (OT) Security, NIST Special Publication 800-82 Revision 3, September 2023. DOI 10.6028/NIST.SP.800-82r3. Source for OT network segmentation, defense-in-depth, the OT control overlay, and unidirectional gateways among recommended OT network-architecture controls.
ISA / IEC, ISA-95 / IEC 62264, Enterprise-Control System Integration. Source for the standard that formalizes the hierarchical level structure popularized by the Purdue reference model.
Software Toolbox, "What is the Purdue Model?" Industry explainer (Software Toolbox is a commercial vendor) used here for a practical description of the Purdue levels (Levels 0 to 5) and the commonly used Level 3.5 industrial DMZ convention; it is not relied on to establish that Level 3.5 is mandatory or universally standard.
Federated learning security
NIST, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025, March 2025. DOI 10.6028/NIST.AI.100-2e2025. Source for data and model poisoning, the note that model poisoning is characteristic of federated learning where clients submit local updates to an aggregating server, and for privacy leakage from shared updates.
J. Liang et al., "A Survey on Federated Learning Poisoning Attacks and Defenses," arXiv:2306.03397, 2023. Supplementary preprint survey of federated-learning poisoning attacks and defenses; the authoritative basis for the poisoning claims here is NIST AI 100-2e2025.
Unidirectional controls and incident context
ISA Global Cybersecurity Alliance, "The Role of Data Diodes in the Evolving Landscape of OT Cybersecurity." Supporting reference for data diodes as an established one-way OT control.
Halliburton Company, Form 10-Q for the quarter ended September 30, 2024 (SEC EDGAR). Reports approximately $35 million of cybersecurity-incident-related expenses recognized in that quarter, covering external advisers, remediation and restoration, legal fees, payroll, and other incident costs. This is a company disclosure for that quarter, not an industry benchmark or a complete estimate of total loss.
Sources: the zones-and-conduits model and Security Levels draw on ISA/IEC 62443; OT segmentation, defense-in-depth, and unidirectional gateways on NIST SP 800-82r3; the Purdue level hierarchy on the Purdue reference model as formalized in ISA-95 / IEC 62264; federated-learning poisoning and confidentiality risks on NIST AI 100-2e2025 and arXiv:2306.03397; and the incident-cost figure on Halliburton's own 10-Q disclosure, retrieved September 2026.
🔤 Acronyms
AI - Artificial intelligence
DMZ - Demilitarized zone (a buffer network segment)
IACS - Industrial automation and control systems
IDMZ - Industrial demilitarized zone
IEC - International Electrotechnical Commission
ISA - International Society of Automation
IT - Information technology
ML - Machine learning
NIST - National Institute of Standards and Technology
OT - Operational technology
PERA - Purdue Enterprise Reference Architecture
RTOC - Real-Time Operations Center
SEC - U.S. Securities and Exchange Commission
SL - Security Level (ISA/IEC 62443); SL-T target, SL-C capability, SL-A achieved
WITSML - Wellsite Information Transfer Standard Markup Language
Reuse and citation. This article may be reproduced in whole or in part, for any purpose, provided WillCo Drilling Consulting is credited as the source and a link to willcodrilling.com is included. Suggested citation: WillCo Drilling Consulting, "Security at the OT/IT Boundary: Protecting the Rig's Network as Models and Data Cross It," willcodrilling.com, September 2026.
Comments