Designing NAC for Manufacturing and OT Convergence in Federal Industrial Control Environments

Federal agencies operating manufacturing facilities, depots, test ranges, utilities, and other industrial environments face a network access control problem that campus-focused NAC designs were never built to solve. The devices on a plant floor do not authenticate. They do not run agents. Many of them run firmware that has not changed in a decade, communicate over protocols that predate modern TCP/IP stacks, and cannot tolerate a network interruption of even a few seconds without triggering a safety event or a production halt. Applying the same NAC enforcement logic used for a Windows workstation to a programmable logic controller is not a configuration problem. It is an architecture problem.

The convergence of IT and OT networks in federal industrial environments has accelerated over the past several years, driven by modernization mandates, remote monitoring requirements, and the need to integrate plant-floor data with enterprise systems. That convergence creates real security value, but it also collapses the air gaps that historically kept industrial control systems isolated from enterprise threats. When an engineering workstation sits on the same physical network as a historian server and a corporate VPN concentrator, the segmentation assumptions that once protected the control system no longer hold.

Network access control for OT environments has to account for constraints that do not exist in traditional IT deployments. Passive discovery instead of active scanning. Zone-based enforcement instead of flat policy. Availability as a safety requirement, not just a service-level preference. Vendor remote access with time-limited, process-controlled authorization. Exception handling that is documented, reviewed, and auditable rather than informal. These are not edge cases. They are the baseline operating conditions in any serious federal industrial control environment.

This article addresses how to architect NAC specifically for that environment, organized around the industrial zone model, IT/OT convergence patterns, and the enforcement decisions that have to be made differently when the network supports real-time control systems rather than office productivity.

Zone Architecture and the IT/OT Convergence Problem

The Purdue Model, or its functional equivalent in IEC 62443 zone and conduit terminology, gives federal OT architects a structured way to think about where devices live, what they communicate with, and what level of availability they require. The model is not a security framework by itself, but it provides the reference architecture that makes zone-based NAC policy coherent.

Level 0 and Level 1 represent field devices and basic control: PLCs, remote terminal units, sensors, actuators, and the controllers that directly manage physical processes. These devices typically run proprietary firmware, communicate over Modbus, DNP3, PROFINET, or other industrial protocols, and have no authentication capability at the network layer. A NAC policy that attempts to enforce 802.1X authentication or posture assessment against a PLC will either fail silently or cause a control loop interruption. Neither outcome is acceptable.

Level 2 is the supervisory layer: HMIs, SCADA servers, engineering workstations used for PLC programming, and data historians. These systems often run Windows or Linux, which means they have more authentication surface than field devices, but they are also subject to strict change control. Patching cycles are long. Software versions are locked to vendor support matrices. An HMI running a version of Windows that is no longer receiving security updates is not an exception in federal industrial environments. It is common.

Level 3 is the operations network: manufacturing execution systems, batch management, production scheduling, and the data aggregation layer that feeds enterprise reporting. This is where IT/OT convergence typically begins to create real architectural tension. Level 3 systems need to communicate with both the control network below and the enterprise network above. That bidirectional connectivity is where threat actors move laterally, and it is where NAC policy has the most leverage without touching safety-critical segments.

The IT/OT convergence problem is not simply that enterprise devices now connect to OT networks. It is that the security assumptions of each domain are incompatible. IT security assumes that devices can be interrupted, patched, scanned, and reconfigured. OT security assumes that availability is non-negotiable and that any change to a running system requires engineering review. NAC architecture in federal industrial environments has to bridge those assumptions without forcing either domain to abandon its operating model.

Passive Profiling and Device Classification in Industrial Networks

Passive profiling is the only viable discovery method for Level 0 and Level 1 devices. Active scanning, even lightweight ICMP sweeps, can cause unexpected behavior in PLCs and other real-time controllers. Some industrial devices interpret unsolicited network traffic as a command or fault condition. Others simply drop their communication state. The engineering team that manages the control system will not accept a scanning policy that has not been reviewed and approved through the plant’s management of change process, and that review cycle can take weeks or months.

Passive profiling works by monitoring network traffic at strategic collection points, typically span ports on switches at zone boundaries or inline taps on conduit links, and building device profiles from observed traffic characteristics. Protocol fingerprinting identifies industrial protocols. MAC OUI lookups identify hardware vendors. Traffic behavior patterns, including polling intervals, packet sizes, and communication partners, help classify device function even when the device itself provides no authentication signal.

The output of passive profiling is a device inventory organized by zone, protocol, communication pattern, and risk classification. That inventory becomes the foundation for NAC policy. Before any enforcement decision is made, the program needs to know what is on the network, where it communicates, and what its availability tolerance is. In most federal industrial facilities, the first passive profiling pass reveals devices that no one in the IT organization knew existed, including legacy PLCs, unsupported HMIs, and vendor-installed monitoring equipment that was never formally documented.

Device classification in OT environments requires more granularity than a standard IT NAC deployment. The classification schema needs to distinguish between field devices that cannot authenticate, supervisory systems that can authenticate but have constrained patch states, engineering endpoints that carry enterprise credentials and move between zones, and vendor devices that connect temporarily for maintenance. Each classification drives a different enforcement posture, and the policy engine needs to handle all of them simultaneously without requiring manual intervention for every new device that appears on the network.

Enforcement Models Across Industrial Zones

The enforcement model for OT NAC is not a single policy applied uniformly across the facility. It is a layered set of zone-specific postures that reflect the availability tolerance, authentication capability, and operational risk of each segment. Applying enterprise NAC enforcement logic to a plant floor without zone differentiation is one of the most common ways OT NAC programs fail.

The table below summarizes the enforcement posture appropriate for each Purdue Model zone, along with the primary authentication method, discovery approach, and enforcement action available given the constraints of that zone.

Purdue Zone	Typical Devices	Authentication Method	Discovery Approach	Enforcement Posture
Level 0 / Level 1	PLCs, RTUs, sensors, actuators	None (MAC-based allowlist)	Passive only	Monitor-only; alert on anomaly
Level 2	HMIs, SCADA servers, historians	MAC allowlist; limited 802.1X	Passive; selective active in maintenance windows	Conditional quarantine; no hard block without change review
Level 3	MES, batch systems, OT DMZ servers	802.1X; certificate-based preferred	Passive and active	Full enforcement; quarantine on policy violation
IT/OT DMZ	Data diodes, jump servers, remote access gateways	Certificate-based; MFA required	Active	Full enforcement; strict allowlist for inbound sessions
Level 4 / Enterprise	Corporate endpoints, ERP, business systems	802.1X; domain certificate	Active	Standard enterprise NAC enforcement

Monitor-only enforcement at Level 0 and Level 1 is not a temporary concession. For devices that cannot tolerate a dropped connection without a physical consequence, monitoring and alerting is the correct long-term posture. The security value comes from detecting anomalous behavior, such as a PLC communicating with a destination it has never contacted before, not from blocking the device at the port level. That anomaly detection feeds the incident response process, not the NAC enforcement engine directly.

Conditional quarantine at Level 2 means that a device flagged for a policy violation is moved to a restricted VLAN that allows it to continue communicating with its required control partners while blocking enterprise-bound traffic. This requires the NAC policy engine to understand the device’s legitimate communication baseline, which is derived from the passive profiling data collected during the discovery phase. Without that baseline, conditional quarantine either blocks too much or too little.

Engineering Workstations and Vendor Access Governance

Engineering workstations occupy a uniquely dangerous position in OT network architecture. They carry enterprise domain credentials, connect to the internet for software updates and vendor support, and also connect directly to PLCs and HMIs for programming and configuration. A compromised engineering workstation is a direct path into the control network, and in federal industrial environments, that path often bypasses every perimeter control that protects the enterprise network.

NAC policy for engineering workstations needs to enforce zone-aware access. When a workstation is operating in the enterprise zone, it should be subject to standard enterprise NAC enforcement, including posture assessment and certificate validation. When it connects to the control network, the NAC policy should restrict its network access to the specific PLCs or HMIs it is authorized to reach, based on role and current work order, not a standing broad-access policy. That restriction should be enforced at the switch port or VLAN level, not just at the application layer.

Vendor Remote Access in OT Environments

Vendor remote access is one of the most poorly governed access paths in federal OT environments. The typical pattern is a standing VPN credential issued to a vendor support team, with access to a broad segment of the control network and no session logging integrated with the NAC policy engine. That credential is often shared across multiple technicians, renewed automatically, and never reviewed against current support contract scope.

A properly governed vendor access model uses time-bounded sessions tied to a specific work order or maintenance window. The NAC policy engine provisions access when the session is authorized and revokes it when the window closes, without requiring manual intervention from the network team. The session is logged at the network layer, not just at the VPN concentrator, so that the security operations team can correlate vendor activity with any anomalies observed in the control network during the same window.

Role-scoped network access means the vendor’s session reaches only the specific devices relevant to the current work. A vendor supporting a specific PLC model should not have network-layer access to the historian server or the SCADA workstation. That scope is enforced through the NAC policy engine by assigning the vendor session to a dynamically provisioned VLAN or ACL that reflects the authorized access boundary, not the full control network segment.

Implementing Network Access Control (NAC) with vendor session governance integrated into the policy engine requires coordination between the NAC platform, the remote access gateway, and the identity management system. That integration is not trivial, but it is the difference between a vendor access program that is auditable and one that is a standing liability.

Conduits, Segmentation, and Policy Boundaries

IEC 62443 defines conduits as the communication paths between zones. A conduit is not just a network link. It is a defined, documented, and controlled communication relationship that specifies what protocols are permitted, what devices can communicate, and what security controls govern the path. NAC policy in OT environments should align to conduit definitions, not to physical switch topology.

In practice, federal industrial facilities often have conduits that were never formally defined. The network evolved organically as systems were added, and the actual communication paths between zones reflect operational necessity rather than security design. The passive profiling phase reveals what conduits actually exist, which is frequently different from what the network diagram shows. Before NAC enforcement can be applied at zone boundaries, those actual conduits need to be documented, reviewed by both the engineering and cybersecurity teams, and either formally authorized or remediated.

Segmentation enforcement at conduit boundaries is where NAC has the most leverage in OT environments. A firewall or industrial demilitarized zone between Level 2 and Level 3 controls what protocols and destinations are permitted. NAC at the same boundary controls which devices are permitted to initiate or receive connections at all. The combination of protocol filtering and device identity enforcement creates a much stronger control than either approach alone.

The IT/OT DMZ is the most critical enforcement point in a converged federal industrial network. All traffic between the enterprise network and the control network should pass through the DMZ, and the NAC policy at that boundary should enforce strict allowlists for both inbound and outbound sessions. Data diodes, where appropriate for the data flow direction, eliminate the possibility of inbound connections to the control network entirely. Where bidirectional communication is required, the DMZ hosts the intermediary systems, such as historians and data aggregation servers, that broker the exchange without creating a direct path between enterprise and control segments.

Common Mistakes

The most consequential mistake in OT NAC programs is treating the control network as a slower version of the enterprise network. The enforcement logic, the discovery methods, the authentication requirements, and the acceptable response to a policy violation are all different. Programs that import enterprise NAC policy templates into OT environments without zone-specific adaptation create enforcement actions that disrupt production or, worse, create safety events that the program office then has to explain to plant management and agency leadership.

Skipping the passive profiling phase to accelerate deployment is another common failure. The device inventory that comes out of passive profiling is not a nice-to-have. It is the data that makes every subsequent enforcement decision defensible. Programs that move directly to enforcement without a validated inventory end up blocking legitimate devices, creating exceptions under pressure, and building a policy exception registry that grows faster than the enforcement policy. That exception registry becomes its own audit liability.

Treating the IT/OT DMZ as a pass-through rather than an enforcement boundary is a structural mistake that undermines the entire segmentation architecture. If the DMZ allows broad protocol access between enterprise and control segments without device-level enforcement, it provides the appearance of segmentation without the security value. Threat actors who compromise an enterprise endpoint can reach control network systems through the DMZ as easily as if no boundary existed.

Failing to integrate vendor access governance with the NAC policy engine leaves one of the highest-risk access paths outside the enforcement boundary. Standing vendor credentials with broad network access are a persistent vulnerability in federal OT environments, and they are frequently the access path used in industrial control system incidents. Governance that exists only in a spreadsheet or a help desk ticket is not governance that survives an audit or an incident.

Conflating RMF compliance with operational security is a mistake that affects OT NAC programs specifically because the RMF control set was not designed with Level 0 and Level 1 device constraints in mind. A system security plan that documents NAC controls as implemented when the actual enforcement posture at the control layer is monitor-only creates a compliance record that does not reflect operational reality. The correct approach is to document the actual enforcement posture, the rationale for zone-specific limitations, and the compensating controls that address the residual risk. Assessors who understand OT environments will accept that documentation. Assessors who find the discrepancy during an assessment will not.

Underestimating the staffing requirement for OT NAC sustainment is a planning failure that shows up after deployment. Passive profiling generates a continuous stream of device alerts, anomaly notifications, and policy exception requests. Someone has to review those alerts, coordinate with the engineering team on device changes, manage the exception registry, and update the communication baselines when production processes change. In federal environments where the IT and OT teams are organizationally separate, that coordination function is often unassigned until an incident forces the question.

Recommended Federal Approach

Start with a joint assessment that includes both the IT security team and the OT engineering team. The two groups have different vocabularies, different risk tolerances, and different definitions of what constitutes an acceptable control. That assessment should produce a shared understanding of the zone architecture, the existing conduit map, the device inventory gaps, and the operational constraints that will govern enforcement decisions. Without that shared foundation, the NAC program will generate conflict between the security and engineering organizations rather than a coherent policy.

Define the zone policy framework before selecting or configuring any NAC platform. The zone policy framework specifies the enforcement posture for each Purdue level, the authentication methods available at each level, the acceptable enforcement actions for each device classification, and the escalation path when a device violates policy. That framework should be reviewed and approved by both the ISSO and the plant or facility engineering authority before any enforcement configuration begins.

Deploy passive profiling sensors at zone boundaries and run them for a full operational cycle before making any enforcement decisions. A full operational cycle includes normal production, planned maintenance windows, shift changes, seasonal variations, and any periodic vendor support activities. Thirty days is a minimum. Sixty days is more reliable for facilities with complex production schedules. The profiling data from that period becomes the authorized communication baseline that drives enforcement policy.

Sequence enforcement from the outside in. Start at the IT/OT DMZ, where enforcement actions carry the lowest operational risk and the highest security value. Validate that enforcement at the DMZ does not disrupt any legitimate production workflow before moving inward to Level 3. At Level 3, implement enforcement with conditional quarantine policies tied to the communication baselines. At Level 2, implement monitoring with anomaly alerting. At Level 0 and Level 1, maintain monitor-only posture unless a specific device or segment has been reviewed and approved for enforcement by the engineering authority.

Build the exception registry as a formal program artifact, not an informal list. Every device that cannot meet the standard enforcement policy for its zone should have a documented exception that includes the device identifier, the zone, the reason for the exception, the compensating controls in place, the review date, and the approving authority. That registry feeds the RMF documentation and provides the audit trail that assessors and inspectors will ask for.

Integrate vendor access governance into the NAC policy engine during the initial deployment, not as a later phase. Vendor access is a high-risk path that is present from day one of operations. Time-bounded session provisioning, role-scoped network access, and session logging should be operational before the facility goes live with any remote vendor support capability.

Plan for sustainment from the start. Assign clear ownership for the OT NAC program, including responsibility for alert review, exception management, baseline updates, and coordination with the engineering team on device changes. Define the process for updating NAC policy when production processes change, when new devices are added, or when vendor support relationships change. Document that process in the system security plan so that it survives personnel turnover, which in federal environments is a near-certainty over any multi-year program lifecycle.

Measure the program against operational outcomes, not just compliance checkboxes. The relevant metrics for an OT NAC program include the percentage of devices with validated communication baselines, the time to detect and alert on anomalous device behavior, the percentage of vendor sessions governed through time-bounded provisioning, and the number of open exceptions with overdue review dates. Those metrics tell you whether the program is providing security value. The RMF documentation tells you whether the program is compliant. Both matter, but they are not the same thing.