For most industrial environments, yes, if the goal is to control communications between unmanaged devices without redesigning the network. Identity-based microsegmentation is better suited to device populations that cannot authenticate like IT endpoints and to environments where east-west traffic is the real risk. Traditional NAC may still help at the edges, but it is not enough on its own.
Why identity-based microsegmentation fits OT better than classic NAC
In OT, the practical question is not whether access should be controlled, but where the control can be enforced without disturbing fragile operations. Identity-based microsegmentation is usually the better fit when assets cannot run modern endpoint agents or participate in normal 802.1X-style admission, because policy can follow the communication flow rather than the switch port. That makes it easier to constrain east-west traffic between controllers, historians, engineering workstations, and vendor paths.
Traditional NAC is strongest at admission control on the edge, where a device connects to the network for the first time. In many plant environments that is only part of the problem, because the risky traffic often happens after a device is already online. A segmentation model that understands identity-centric policy and identity-based segmentation is therefore more aligned to OT traffic patterns than a perimeter-only posture.
The other reason it fits better is operational tolerance. OT teams often need deterministic communications, long-lived assets, and limited maintenance windows. A control that depends on frequent reauthentication, agent deployment, or endpoint rework can be difficult to sustain across PLCs, HMIs, and unmanaged devices. Microsegmentation lets teams reduce blast radius without turning every device into an IT-style managed endpoint.
What changes when the device cannot authenticate like an IT endpoint
OT devices are often managed through indirect trust, such as fixed application flows, designated jump hosts, or tightly scoped control channels. That means the security decision is less about proving a user session and more about proving that a device, system role, or communication path is the one allowed to talk. OT identity and access patterns matter here because shared accounts, vendor access, and zone design usually shape the real control boundary.
Identity-based microsegmentation works when the policy engine can map traffic to the source, destination, application, and trust context that actually matter in OT. That may include fixed engineering subnets, maintenance windows, or approved conduit pairs. NAC, by contrast, can tell you whether something is on the network, but not always whether its conversations are appropriately constrained once it is there.
In practice, this shifts the design goal from “admit trusted devices” to “limit what trusted or semi-trusted devices can reach.” That is a better match for systems where physical processes, vendor support, and legacy protocols force coexistence between secure and insecure components.
Where NAC still matters, and where the boundary should sit
NAC is still useful at the edges for corporate-managed laptops, remote access entry points, and any OT-adjacent zone where device compliance is actually enforceable. It can help with device posture, onboarding, and stopping obviously unmanaged systems from landing in sensitive segments. But in a mixed OT estate, NAC should be treated as an admission and visibility layer, not the main control for east-west containment.
For plant networks, the more durable pattern is often layered controls: edge admission where feasible, then identity-based segmentation inside the environment to contain laterally moving traffic. That aligns with the broader zero trust approach described in Zero Trust Identity Guide and with OT guidance from NIST SP 800-82 Rev 3, which emphasizes segmentation and OT-aware control placement.
That layered model also reduces dependence on one control doing too much. If NAC fails open, is bypassed during maintenance, or cannot classify legacy assets accurately, the internal segmentation layer still limits movement. If segmentation policy is too broad, NAC can still help keep unmanaged or obviously unsafe devices from entering sensitive zones in the first place.
Risk and Threat Considerations
OT environments are attractive targets because lateral movement can reach engineering stations, historians, remote support paths, and eventually control functions. The main risk with traditional NAC is not that it is useless, but that it creates a false sense of containment when the real exposure is east-west traffic after admission.
Failure mechanism: If the control only checks who gets onto the network, attackers or unauthorized devices that already have a foothold can move laterally among OT assets, especially where shared accounts, vendor pathways, or legacy protocols weaken enforcement.
Impact: The result can be broader process disruption, deeper compromise of trusted zones, and a larger blast radius than operators expected from an edge-only access model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | OT segmentation and east-west traffic restriction require enforced flow control. |
| IA-9 — Service Identification and Authentication | Identity-based segmentation depends on authenticating non-human communication endpoints. | |
| Recommendation — Enforce AC-4 to constrain OT traffic between approved device and zone pairs. Apply IA-9 to authenticate service and device communications before allowing access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Identity-centric segmentation and least-privilege access are central to the comparison. |
| Recommendation — Adopt zero trust policy enforcement to control OT traffic by identity and context. | ||
Practitioner Guidance
What to prioritise: Treat device admission and internal traffic control as separate design problems. Use NAC where you can reliably enforce device trust at the edge, but assume it will not solve internal OT containment on its own.
What to verify: Confirm that the segmentation policy is written around real OT communication paths, not generic subnets. If the policy cannot express the approved flows between controllers, HMI systems, engineering tools, and vendor jump paths, the design is too coarse.
Decision rule: If the device population includes unmanaged or hard-to-manage OT assets, favour identity-based microsegmentation for east-west control and keep NAC as a complementary admission control, not the primary security boundary.
Practitioner takeaway: In OT, the best control is the one that can actually survive the environment, so prefer the mechanism that constrains real traffic paths without requiring every device to behave like a modern IT endpoint.
Related resources from NHI Mgmt Group
- When should organisations use identity-based authentication instead of API keys for Azure OpenAI access?
- When should organisations use phone-centric identity instead of more traditional onboarding checks?
- Should organisations use workload identity instead of request-based JIT for AI agents?
- When should organisations use workload identity instead of user-based CLI auth?