NAC for OT Networks: MAB, Profiling and Safe Enforcement

Network access control designed for offices can take a production line down: a port shut on a PLC that failed authentication, a re-authentication that bounces a ring port, or an active probe that crashes a fragile network stack. Yet OT networks need to know what is plugged in, because unauthorised laptops, vendor equipment and rogue devices are a common route to control systems. This guide covers NAC in industrial environments specifically: passive profiling to build the device list, which enforcement modes are safe for which device classes, the constraints of industrial switches, and a monitor-only rollout that never surprises operations. It is written for OT network engineers, control system owners and security teams. The protocol basics of 802.1X, EAP, RADIUS and MAC Authentication Bypass (MAB) are covered in our Network Access Control (NAC) Guide and are not repeated here.

Key takeaways

Visibility is the first deliverable, not blocking. In most plants the realistic goal for controllers is detection of new or changed devices, with enforcement reserved for transient laptops, engineering workstations and open ports.
Profile passively. NIST SP 800-82r3 warns that active scans can destabilise devices or disrupt process state; passive collection from switch mirror ports and taps sends nothing to the devices.
Enforcement is chosen per device class. Windows HMIs and engineering workstations can run 802.1X with certificates; PLCs and safety controllers usually cannot, and should get MAB with alerting or physical controls instead.
Design for RADIUS failure. If the policy server is unreachable, ports with existing control devices must stay open. Fail-closed is only acceptable on ports for transient equipment.
Change of state is a process event. Port bounces, VLAN moves and re-authentication timers can break control traffic or ring redundancy, so treat every NAC action on a control network as a managed change.

Why OT changes the NAC design

Corporate NAC assumes devices that run a supplicant, get addresses from DHCP, can be moved between VLANs and tolerate a reconnect. Control networks break each assumption.

Fragile stacks: many controllers, remote I/O and drives have small embedded network stacks. NIST SP 800-82r3 says owners should be extremely cautious about active scanning on an operational network and should schedule active scans during planned outages where possible.
No supplicant: most PLCs, I/O modules and field devices cannot run 802.1X. MAB is the only switch-side option, and a MAC address is an identifier, not a credential.
Static addressing and fixed peers: control devices are configured with static IP addresses and talk to a fixed set of peers. Moving one to another VLAN breaks the process, so dynamic VLAN assignment is rarely usable.
Availability and safety first: an incorrectly blocked device is a production or safety event, not a help desk ticket. See the OT Cyber Physical Risk and Safety Guide.
Vendors and integrators connect equipment: commissioning laptops, diagnostics kit and replacement parts are brought in by third parties. ATT&CK for ICS T0864 Transient Cyber Asset describes adversaries using devices compromised outside the plant to reach ICS networks.

Passive profiling: building the device list

NAC in OT depends on a trustworthy list of what should be on each port. Build it from traffic and records, not from probes. The joint CISA-led Foundations for OT Cybersecurity: Asset Inventory Guidance (August 2025) lists high-priority attributes that include MAC address, IP address, manufacturer, model, communication protocols, ports and services, physical location and asset criticality; these map directly onto the fields a NAC policy needs.

Method	What it yields	OT suitability
Switch mirror port or network tap with passive monitoring	MAC and IP pairs, peers, industrial protocols in use; with protocol decoding often vendor, model and firmware	Preferred. Sends no traffic. Misses devices that are silent during the capture period and can take days to complete
Switch tables (MAC address table, LLDP neighbours) read from the switch	Which MAC is on which port; neighbouring switches and some device types	Good. Query the switch, not the end devices; schedule polling at a modest rate
RADIUS accounting in monitor mode	MAB requests per port with timestamps	Good once switches are configured; the data the enforcement policy will actually use
Engineering records (project files, drawings, purchase records)	Intended devices, locations and owners	Essential for confirming what traffic shows; often out of date
Hybrid "safe" active queries	Extra detail gathered with device-specific protocol requests after passive learning	Use only where the vendor supports it and the owner approves; NIST describes this as an option to gather detail without risking operations
Generic active scanning	Open ports and services	Avoid on live control networks; use only during planned outages or in a test cell

Profiling data is also how you detect MAC spoofing: if a MAC registered to a PLC starts speaking a Windows file sharing protocol, the device behind the port has changed. The monitoring side is covered in the OT Asset Visibility Guide and the OT Network Security Monitoring Guide.

Enforcement modes and device classes

Choose a mode per port group rather than per site. The modes below run from least to most intrusive.

Mode	What happens to an unknown device	Where it fits in OT
Monitor only	Access allowed whether authentication passes or fails; event logged	Starting point everywhere; long-term mode for controller and safety networks
Monitor with alert and response	Access allowed; SOC or control room alerted to a new or changed MAC on the port	Level 1 and Level 2 ports with PLCs, I/O and drives
Restricted for unknowns	Known devices keep full access; unknown MACs get a filter allowing only defined services or nothing	Supervisory and HMI networks once the device list is stable
Closed with 802.1X	No traffic until certificate-based authentication succeeds	Engineering workstations, HMIs on supported operating systems, maintenance ports
Port disabled	Port administratively down until a change request opens it	Unused ports in cabinets and control rooms

Device class	Recommended authentication	Enforcement
PLCs, remote I/O, drives	MAB with entries tied to the asset record	Monitor with alerting; no re-authentication timers; no dynamic VLAN
Safety instrumented system controllers	MAB for visibility only, or none	Monitor only, plus locked cabinets and dedicated networks. See the Safety Instrumented Systems Security Guide
HMIs and engineering workstations	802.1X with machine certificates (EAP-TLS) where the OS and vendor support it	Closed or restricted after a pilot; validated with the control system vendor
Transient and vendor laptops	802.1X with a certificate issued for the visit, or a dedicated maintenance port	Closed, time-limited, placed in a maintenance zone that reaches only the target devices
IIoT gateways and newer field devices	802.1X with a device certificate where supported; IEEE 802.1AR defines a manufacturer-installed IDevID and an operator-enrolled LDevID	Closed or restricted, depending on the device's tolerance
Cameras, printers, building devices in the plant	MAB with a filter allowing only their servers	Restricted

Industrial switch constraints

Feature support: confirm per model and firmware whether the switch supports 802.1X, MAB, RADIUS accounting, downloadable or named filters and RFC 5176 Change of Authorization (CoA). Unmanaged switches inside cabinets cannot participate at all and hide every device behind them.
Ring and uplink ports: never enable port authentication on ring, trunk or uplink ports. A bounced ring port can trigger a redundancy reconvergence that interrupts cyclic control traffic.
Daisy chains and multi-device ports: devices with built-in two-port switches put several MACs behind one access port. Multi-host modes authorise everything behind the first device, so record which ports legitimately carry several MACs and alert on changes instead.
Re-authentication and CoA: turn off periodic re-authentication on controller ports, and do not use CoA port bounce or disconnect on them. RFC 5176 Disconnect-Request and CoA-Request messages go to UDP 3799 on the switch; restrict that to the policy servers and use it only on enforcement port groups.
RADIUS reachability: policy servers usually sit in a site operations zone. Every authentication crosses a conduit, so allow only RADIUS from switch management addresses, place servers in the plant where WAN links are unreliable, and define the behaviour when no server answers: keep existing control devices authorised, which some platforms call critical or server-dead authorisation. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Local fallback where RADIUS is not possible: switch-local port security with a fixed MAC per port and a violation action of logging rather than shutting down gives some protection on older switches. NIST SP 800-82r3 also recommends disabling unused ports and services after testing that operations are not affected.
Management plane: NAC changes switch configuration at scale, so the switch management interfaces and the NAC platform's own credentials need hardening. See the Industrial Switch and Serial Gateway Hardening Guide.

Rolling out NAC in an OT environment

Agree scope and authority: name the asset owner for each area, agree that no port changes state without a change request, and define who can override NAC during an incident or shutdown.
Inventory switches: list models, firmware and feature support; identify unmanaged switches and ring ports; plan replacements where needed.
Passive profiling: collect traffic for at least a full production cycle, including batch changes and weekly maintenance, so quiet devices appear. Reconcile against engineering records and assign an owner to every MAC.
Monitor mode on a pilot cell: enable MAB and 802.1X in monitor mode on a non-critical line or a test cell. Check that control traffic, alarms and redundancy behave exactly as before. Keep the configuration templated so rollback is one change.
Extend monitor mode site-wide: roll out area by area during planned outages. Use RADIUS accounting to complete the device list and investigate every unknown MAC.
Turn on alerting: send new-MAC, MAC-move and profile-change events to the OT SOC or control room with the asset context. See the OT Security Operations Centre Guide.
Enforce where safe: start with unused ports, maintenance ports and transient device access, then HMIs and engineering workstations after vendor validation. Leave controller and safety ports in monitor mode unless the owner signs off a tested design.
Keep the list current: require a NAC update in every change request that adds or replaces a device, including emergency changes, and expire entries not seen for a defined period with the owner's agreement.

Where identity fits

Every MAB entry and device certificate is a machine identity with an owner, a lifecycle and a revocation path. Treat the MAC list like an account register: who approved the entry, which asset it belongs to and when it was last seen. Integrator laptops should receive per-visit credentials rather than a shared maintenance identity. See the Device and IoT Identity Guide and the OT Third-Party and Integrator Access Guide.

Choosing an approach

Small sites with older switches: disable unused ports, use switch-local port security with log-only violation actions on accessible ports, provide one controlled maintenance port, and rely on passive monitoring for detection.
Sites with managed industrial switches: run MAB in monitor mode with RADIUS accounting feeding the asset inventory, enforce on maintenance ports and workstations, alert on controller ports.
Large or multi-site operators: integrate the NAC policy server with the OT monitoring platform and asset inventory so profiles come from passive data, place policy servers per site for resilience, and use device certificates for new equipment that supports them. For product selection, see the Network Access Control Buyer's Guide.

Detection and measurement

MITRE's detection guidance for T0864 looks for a device's first connection from an IP or MAC address not seen before, shortly after a new device association, and recommends alerting when that is corroborated by access to protected OT assets or configuration changes, while suppressing approved vendor support and commissioning windows.

Percentage of access ports with a known, owned device recorded against them.
Number of unknown MAC events per month and median time to identify each.
Unused ports administratively disabled, as a share of all unused ports.
Transient device connections made through approved maintenance ports or 802.1X, versus elsewhere.
NAC-caused process interruptions (target zero), tracked through the change and incident process.
Age of the oldest unverified entry in the MAB list.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	IA-3 Device Identification and Authentication	MAB and certificate authentication of devices
NIST SP 800-53 Rev 5	CM-8, SI-4, SC-7, AC-4	Component inventory, monitoring for unauthorised devices, boundary and flow enforcement
NIST CSF 2.0	ID.AM-01, PR.AA-01, PR.IR-01, DE.CM-01	Hardware inventory, device identities, protection from unauthorised logical access, network monitoring
ATT&CK for ICS	T0864 Transient Cyber Asset, T0848 Rogue Master, T0886 Remote Services	Techniques that rely on connecting or impersonating devices on control networks
ATT&CK for ICS mitigations	M0807 Network Allowlists, M0930 Network Segmentation	Connection allowlists by address, port and protocol; segmentation of transient assets
ATT&CK Enterprise	T1200 Hardware Additions	Devices plugged into accessible ports
IEC 62443	System and component requirements for device identification and authentication	See the IEC 62443-3-3 and 4-2 Security Levels Guide

Common failure patterns

Enterprise template copied to the plant: closed mode, periodic re-authentication and dynamic VLANs applied to controller ports, causing dropped connections during production.
Active profiling on live networks: the NAC platform's scanning features left on, probing controllers that then fault or reboot.
Fail-closed on RADIUS loss: a WAN outage to the central policy server blocks every device that re-authenticates.
Authentication on ring ports: port authentication enabled on redundancy links, causing reconvergence when ports change state.
Stale MAB lists: entries never expire, so a decommissioned device's MAC can be reused by anyone who learns it.
Unmanaged switches in cabinets: NAC reports one known device on the uplink while several unknown devices sit behind a small switch.

Practitioner checklist

Agree an OT NAC change policy with asset owners, including override during incidents and shutdowns.
Inventory switch models and firmware for 802.1X, MAB, accounting and CoA support; flag unmanaged switches.
Build the device list passively over a full production cycle and assign an owner to every MAC.
Run monitor mode on a pilot cell and confirm control traffic and redundancy are unaffected.
Exclude ring, trunk and uplink ports; turn off re-authentication and CoA on controller ports.
Define RADIUS-unreachable behaviour that keeps control devices authorised.
Disable unused ports after testing and provide controlled maintenance ports for transient devices.
Use 802.1X with certificates for engineering workstations, HMIs and vendor laptops where supported.
Alert on new, moved and changed devices with asset context, and measure time to identify them.
Update the NAC device list in every change that adds or replaces equipment.

Standards and references

Related NHI Mgmt Group resources: Network Access Control (NAC) Guide · OT Security Guide · PLC Security Guide · OT Remote Access Guide

NAC for OT Networks Guide: MAB, Passive Profiling and Safe Enforcement for Industrial Devices