§ What it is
Not a product. Not a framework. Not a security overlay. The architecture applies the same reasoning a process control system uses for material and energy to information, connectivity, and services: defined inputs, defined outputs, controlled boundaries, rejection of anything outside the operating envelope.
Manufacturing Operations practitioners already understand this thinking. An uncontrolled variable is a hazard. An undefined flow is a leak. An open boundary is a failure mode.
§ Why independence
Most monitoring and security architectures for Manufacturing Operations assume connectivity. They assume a central management plane, cloud dashboards, vendor support channels, license servers, update repositories. Every one of those assumptions is a dependency, and every dependency is a failure mode.
IIA eliminates those dependencies by design. The zone runs its own services, stores its own data, monitors its own boundaries, and makes its own decisions about what to share. If every connection to the outside world is severed, the zone continues to function exactly as it did before. Nothing degrades. Nothing goes dark. Nothing phones home to ask permission.
Independence also means Manufacturing Operations is not a tenant on IT infrastructure. The automation team owns its own services, its own boundaries, its own data narrative. IT governance stops at the boundary. Data crosses on Manufacturing Operations' terms, via contracts Manufacturing Operations defines and enforces. The entity that controls the automation infrastructure controls the operation. IIA ensures that entity is the operator - not a vendor, not a cloud provider, not corporate IT.
§ The boundary problem
The conventional "DMZ" between IT and Manufacturing Operations, as commonly implemented, is not a real boundary between the two domains. It is an IT/IT boundary. The top firewall isolates the plant from the wide area network. The bottom firewall separates manufacturing support servers from the rest of the IT network. Both firewalls are managed by IT, for IT purposes, under IT governance. Nothing about that arrangement gives the control system any authority over what crosses.
A real boundary between the information domain and the control domain requires that Manufacturing Operations controls one side and IT controls the other. Manufacturing Operations dictates what data leaves the control system network, under what conditions, and in what form. If providing that data would interfere with the control system, the data does not leave. That authority is not negotiable. The consequences of getting it wrong are physical, not informational.
IIA places that boundary where it belongs: at the edge of the control system network, governed by the people responsible for the process.
§ There is no single control network
A plant does not have one control network. It has several distinct ones: paint, conveyance, machining, powerhouse, packaging. Each has its own protocols, its own management, its own operational requirements. These networks may have nothing in common with each other. The fieldbus war happened precisely because of this. When two control system domains disagree or converge on shared infrastructure, the dispute gets handed to IT, who speak neither domain's language. That is where things break down.
Each control network is its own sovereign domain. IIA treats each one as an independent zone: its own boundary, its own services, its own contracts governing what crosses.
§ Principles
Self-sufficiency. Every zone contains its own essential services. Manufacturing Operations owns all the services the zone needs to operate: DNS, DHCP, SMB, FTP, NTP, data collection, storage, monitoring, visualization, security. These services are not provided by IT. They are not leased, delegated, or shared. If IT provides your DNS, IT controls your name resolution, and you have a dependency. The zone runs its own. No zone depends on upstream connectivity to function. If the link drops, nothing changes on site. Connectivity is additive. It is never structural.
Selective admission. The default posture is closed. External attack surface is reduced to as few hardened, defined endpoints as possible. Access is granted deliberately, specifically, and revocably. If you can avoid letting anyone in, you do.
Narrative control. The zone is the authority on what it shares, if it shares anything at all. If data leaves, it is pushed outward. Nothing reaches back in. The zone decides what leaves, in what form, on what schedule, and to whom. Manufacturing Operations controls the boundary. If getting you the data would compromise control, you do not get the data.
Boundary enforcement. Functional areas are separated by walled zones. The only paths between them are controlled conduits. These boundaries are not advisory. They are enforced, by software or by hardware, and they are monitored the same way a process boundary is monitored: continuously, with alarms on deviation.
Contractual binding. Every conduit between zones is governed by an explicit contract: what data, in what direction, under what conditions, with what authentication. No implicit trust. No ambient access. The contract is the setpoint. Traffic outside the contract is a deviation, and deviations are rejected.
§ The hard constraints
Never interfere with the process. The architecture observes and reports. It does not act on the process. It does not inject. It does not modify. It does not command. The automation cell is sovereign. IIA monitors the boundary. It does not cross it.
Control signal priority is absolute. Real-time control traffic always has priority over information traffic. AI data, historian data, reporting data, analytics data are all information domain traffic and are all secondary. This is not a preference. It is a traffic engineering requirement. If information traffic would contend with control traffic, the information traffic is the one that gets dropped.
Observe, never intercept. Data collection is passive. Copy, never intercept. Mirror, never inline. The architecture is never in the path of control system traffic. It sees what passes by and takes a copy. It does not insert itself into the data flow, it does not modify packets in transit, and it does not add latency to control communications.
§ Implementation
Service agreements
The architecture is implemented organizationally through managed service agreements (MSA) between manufacturing operations and IT. The MSA defines the relationship at the boundary: what each side provides, what each side controls, and what neither side may do without the other's consent. Annexes to the MSA define the specifics: network address allocations, interlock specifications, priority mapping, and the contracts governing each conduit. The MSA is the organizational expression of the same principles the technical architecture enforces. Without it, the technical controls exist in a governance vacuum and will be eroded by the first person with admin credentials and a business justification.
Read a sample MSA and its five annexes (address allocations, interlocks, troubleshooting runbook, firewall register, switch families) under Documentation.
Enforcement
These principles do not change between deployment modes. What changes is the enforcement mechanism.
Software enforcement uses cryptographic identity, mutual authentication, contract catalogs, kernel-level firewalling, and attestation to implement zones, conduits, and contracts. The assurance comes from the software stack.
Hardware enforcement adds physical separation: data diodes for one-way flow, dedicated interfaces per zone, air gaps where required. The assurance comes from physics.
The principles govern both. A virtual deployment that violates the principles is not IIA. A physical deployment that follows them is. The enforcement mechanism is an implementation decision, driven by risk tolerance, regulatory requirements, and the operational reality of the specific environment.
No blanket prescriptions
The architecture defines principles, constraints, and recommendations. It does not prescribe a single implementation. How the principles are realized depends on what is being built, for what environment, under what operational and regulatory constraints. On a poultry farm, the entire stack might be containerized services on a single box. In a nuclear plant, it might be multiple redundant, highly available hardware pairs. Same principles. Same constraints. Same contracts. Entirely different physical realization. Any document or product that claims to be IIA-aligned but mandates a single topology for all environments has missed the point.
COTS hardware
IIA targets commercial off-the-shelf hardware. No custom silicon. No proprietary appliances. No vendor-specific platforms. Commodity hardware that anyone can source, anyone can replace, and nobody controls the supply of. The moment the architecture depends on a specific vendor's box, it has a dependency, and the entire purpose of the architecture is to eliminate dependencies. If it cannot be built from parts available to anyone, it is not independent.