IIoT and Critical Infrastructure: The Systems Engineering Challenge Nobody Is Talking About
Industrial IoT is not a new idea. SCADA systems have monitored pipelines and substations for decades. Distributed control systems in refineries have run on networked architectures since the 1990s. What is new is the scale, the connectivity, and the exposure. Sensors that once reported to isolated control rooms now send data to cloud analytics platforms. Firmware updates arrive over cellular links. Vendor remote access is standard practice. The attack surface has expanded by orders of magnitude, and the engineering organizations responsible for these systems are catching up.
The result is a quiet, ongoing crisis in systems engineering practice. Not the dramatic crisis of a major breach or a Stuxnet-scale event — though those happen — but the slow-moving structural crisis of organizations deploying connected infrastructure they do not have the engineering frameworks to fully specify, verify, or change safely.
This article examines what is actually happening in industrial IoT systems engineering for critical infrastructure, where the standards frameworks are maturing, and where the field remains dangerously immature.
The Installed Base Problem
Start with the physical reality. A water treatment plant built in 1998 may have PLCs from three different vendors, a SCADA system that runs on an end-of-life Windows operating system, and analog instrumentation that was never designed to coexist with IP-networked devices. A power transmission operator may manage hundreds of substations with relay protection hardware spanning five generations of technology. An oil and gas operator runs pipelines instrumented with RTUs that communicate over leased telephone lines alongside new installations running IEC 61850 over fiber Ethernet.
When an industrial IoT project begins in this environment, the new IoT infrastructure — edge gateways, cloud-connected sensors, analytics platforms — does not replace the legacy OT. It integrates with it. The legacy systems become fixed constraints in the system architecture, and all the requirements for safety, security, and interoperability pile onto the new layer.
This creates a fundamental problem for systems engineers: the thing you are engineering is not a new system. It is a new layer on top of existing systems you did not design and may not fully understand. The “system” in your system requirements document is a fiction. The actual system includes firmware you cannot update, communication protocols you cannot modify, and failure modes that were characterized before cybersecurity was considered part of functional design.
Systems integrators who have been in this space for more than five years will tell you this is the central challenge. Not the technology — edge computing is mature, MQTT and OPC-UA work — but the requirements discipline required to safely specify a connected architecture on top of infrastructure that was never designed to be connected.
Two Standards That Were Not Designed to Meet
IEC 62443 is the dominant cybersecurity standard for industrial automation and control systems. IEC 61511 is the functional safety standard for safety instrumented systems in the process industries. Both are well-established, widely cited in regulatory frameworks, and technically rigorous. They were also written by different communities, with different assumptions, and they interact in ways neither standard fully addresses.
The core tension is this: IEC 61511 is built on a deterministic safety model. A safety instrumented function (SIF) — say, an emergency shutdown triggered by a high-pressure sensor — has a required probability of failure on demand (PFD). That PFD is calculated from component failure rates, redundancy architecture, and proof test intervals. The model assumes the failure modes are random hardware failures, not intentional attacks.
IEC 62443 addresses intentional attacks. It defines security levels (SL 1-4) and requires that countermeasures be applied to bring the achieved security level up to the target. But it does not provide a method for quantifying how a successful cyberattack changes the PFD of a safety instrumented function. That calculation — the interaction between a security vulnerability and a safety function’s probability of failure — is left to the systems engineer.
Some guidance exists. ISA-84 has published technical reports. IEC has working groups. The UK’s Health and Safety Executive has published position papers. But there is no consensus method for calculating the safety impact of a cybersecurity failure at the SIF level, and there is no standard that tells you how to write a requirement that simultaneously satisfies both frameworks.
In practice, systems integrators handle this in three ways. The most common is segregation: treat cybersecurity and functional safety as separate domains, maintain air gaps or security zones between safety systems and networked systems, and prevent them from interacting. This is defensible in a greenfield design and increasingly untenable in connected infrastructure where the economics and operational benefits of IIoT integration are the entire point. The second approach is manual cross-referencing: maintain a functional safety analysis and a security risk assessment in parallel, rely on experienced engineers to identify conflicts, and document the reconciliation in meeting minutes. This works until someone changes something. The third approach — emerging among more sophisticated integrators — is to model the interaction explicitly, treating security zone assignments and SIF integrity levels as linked requirements that must be co-managed.
That third approach demands tooling that most teams do not have.
What Good Looks Like: Emerging Practice
The integrators doing the most credible work in this space share some common practices.
Explicit security zone / safety layer mapping. Rather than treating Purdue model zones and functional safety layers as separate architectural concerns, leading teams model them together. A process sensor that feeds a safety instrumented function and also connects to an IIoT data aggregation platform has requirements in both domains. That connection is a risk surface that needs to be tracked as a single system element, not handled in two separate documents.
Threat-informed safety analysis. Some teams are extending their HAZOP and LOPA methodologies to include threat scenarios alongside process deviation scenarios. This is not mainstream practice, but it is appearing in the most security-mature process industry projects, particularly in nuclear-adjacent facilities where regulators are starting to ask for it.
Requirements traceability that spans OT and IoT. The traditional approach — one requirement document for the DCS, one for the safety system, one for the SCADA — breaks down when the system under analysis spans all three plus a cloud analytics platform. Change management is where this fails visibly: a firmware update to an edge gateway changes the latency characteristics of a control loop, which affects a safety function’s response time, which may change the SIL classification. If those requirements are in separate documents with no mechanical linkage, the change propagates only as far as the person doing the change analysis bothers to look.
Formal interface requirements for legacy OT. Rather than treating legacy systems as a black box, sophisticated teams are writing explicit interface requirements that document what the legacy system does, what its failure modes are, and what constraints the new IoT layer must respect. This is painstaking work — it requires reverse engineering specifications that may not exist — but it converts the legacy system from an uncontrolled variable into a specified component.
Where the Field Is Still Immature
Several areas remain genuinely underdeveloped.
Cybersecurity requirements for field devices. IEC 62443-4-2 defines security requirements for components, but adoption in the field device market is inconsistent. Many IIoT sensor vendors have strong connectivity stories and weak security stories. Purchasing specifications at major operators are improving, but the installed base is full of devices that would fail a basic security evaluation. Systems integrators are compensating with network-level controls rather than device-level security, which is a reasonable short-term approach and a fragile long-term architecture.
Supply chain requirements. Software bill of materials (SBOM) requirements are becoming standard in IT cybersecurity frameworks. In OT and IIoT, SBOM awareness is low, and the firmware supply chain for industrial devices — where a gateway may run an embedded Linux build with dozens of open-source components — is poorly characterized. When a critical vulnerability appears in an open-source component embedded in a field device, most operators have no systematic way to identify affected assets.
Requirements management for continuous change. Critical infrastructure is not deployed and left alone. Pipelines are extended. Substations are upgraded. Manufacturing lines are reconfigured. The engineering documentation that described the system at commissioning drifts from the as-built reality, and the as-built reality drifts from the currently operating system. In high-consequence environments, this gap is not acceptable — but the process discipline and tooling required to maintain living requirements across the operational lifecycle of a 30-year asset are not standard practice.
Failure mode interaction modeling. When a safety instrumented system and a connected control system share a process measurement — common in modern IIoT-integrated designs — common cause failures become a concern. A compromised sensor feeding both the basic process control system and the SIS creates a scenario that neither IEC 61511’s common cause analysis nor IEC 62443’s threat modeling was designed to evaluate. The field needs analytical methods and requirements frameworks for this interaction. Right now, it largely does not have them.
Tooling: Document-Centric Approaches Are Showing Their Limits
The requirements management tools most widely deployed in industrial systems engineering were designed for document-centric, milestone-driven development. IBM DOORS and its successor DOORS Next are the standard in many large-scale OT programs, particularly in nuclear and defense-adjacent industries where regulatory documentation requirements drive tool selection. Jama Connect has gained adoption in process safety programs that need structured traceability. Polarion and Codebeamer serve automotive and industrial segments with strong configuration management integration.
These tools do what they were designed to do. DOORS Next handles large, complex requirement sets with formal change management. Jama provides readable traceability and good review workflow. Polarion connects requirements to test execution effectively.
The limitation that shows up in IIoT critical infrastructure programs is the gap between static requirement structures and dynamic, interconnected system architectures. When a requirement in one domain — a security zone boundary, a network latency constraint, a safety function response time — has logical dependencies on requirements in three other domains, a row-and-column RTM is a poor representation of that relationship. Changes that should trigger cascading reviews do not, because the connection between requirements is implicit in the engineer’s head rather than explicit in the model.
This is the specific problem that graph-based requirements modeling addresses. Tools like Flow Engineering, built natively around a connected model of system elements and requirements rather than a document hierarchy, make those cross-domain dependencies explicit and queryable. When a security requirement changes — say, a new network segmentation policy creates a latency path that did not previously exist — the impact on connected functional and safety requirements is immediately visible in the model. That kind of change impact analysis, which takes days of manual cross-checking in a document-centric tool, becomes a structured query.
For systems integrators managing IIoT-connected critical infrastructure programs, where the requirement relationships between OT, IoT, safety, and cybersecurity domains are exactly this kind of dense, interconnected graph, that capability is not a nice-to-have. It is the difference between change management that catches problems before commissioning and change management that discovers them in the field.
Flow Engineering’s focus is on hardware and embedded systems programs rather than large-scale process safety documentation workflows, which means it is not a replacement for the compliance documentation tooling that regulators and auditors expect to see in nuclear or pipeline safety cases. But for the requirements engineering work that precedes and informs that documentation — the architecture modeling, the cross-domain dependency mapping, the change impact analysis — it represents a different and more capable approach than what most industrial programs are currently using.
Honest Assessment
Industrial IoT in critical infrastructure is real, is growing, and is creating genuine engineering value. Predictive maintenance on pipeline compressors works. Remote monitoring of water treatment chemistry reduces operator burden and improves response time. Connected substation protection reduces fault isolation time from hours to seconds.
The systems engineering discipline required to do this safely has not kept pace with the deployment rate. The standards frameworks are incomplete, particularly at the intersection of cybersecurity and functional safety. The tooling most teams use was not designed for the kind of cross-domain requirements management that IIoT integration demands. The installed base creates constraints that are poorly characterized and frequently underestimated.
None of this means IIoT critical infrastructure programs should stop. It means they should be honest about where the engineering rigor is solid and where it is not. The teams doing the best work are the ones who have made that assessment explicitly — who know which parts of their requirements are well-specified and which are held together by experienced engineers who have not documented their reasoning.
That gap, between what is known and what is written down, is where the field needs to mature. The technology is ready. The engineering practice is catching up.