How should security teams choose a microsegmentation approach for mixed IT, IoT, and OT environments?

Why This Matters for Security Teams

Microsegmentation is often presented as a network design choice, but mixed IT, IoT, and OT environments make it an identity and operations problem as well. Legacy controllers, unmanaged sensors, and proprietary OT protocols rarely support the same enforcement model as modern servers, so a single approach usually fails somewhere in the stack. The practical question is not whether to segment, but where enforcement can actually occur without disrupting production.

Security teams also need to avoid assuming that IP-based policy is enough. Device identity, service identity, and communications intent matter more than address ranges in environments where assets move, shift roles, or cannot host agents. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and NHIMG research such as the Ultimate Guide to NHIs both point to the same reality: visibility and lifecycle control matter as much as segmentation boundaries. In practice, many security teams discover the limits of their chosen model only after an outage, a vendor remote-access exception, or an incident that exposed how much of the environment was still depending on flat trust.

How It Works in Practice

The most reliable selection method starts with three questions: what must be protected, where policy can be enforced, and how much operational overhead the team can sustain. In mixed environments, agentless and identity-based microsegmentation usually fit best because they can cover devices that cannot run endpoint software, including many IoT and OT assets. That does not mean agents have no place. On managed servers, agent-based controls can provide process-level context, application discovery, and richer telemetry for tighter policy decisions.

For environments with mature identity infrastructure, the best practice is evolving toward policy that follows workload identity rather than fixed subnets. That means mapping device classes and communication paths, then enforcing rules based on identity, service role, or application intent instead of brittle IP lists. The same principle shows up in NIST guidance and in NHIMG research such as the Schneider Electric credentials breach, which illustrates how access paths and credential exposure can become inseparable from segmentation design.

• Use agentless controls for unmanaged or constrained assets where software installation is not realistic.
• Use identity-based policy for east-west traffic where workload or device identity can be reliably asserted.
• Use agent-based controls selectively on managed systems that need process awareness or local containment.
• Place enforcement as close as possible to the traffic source, but not at the cost of breaking OT timing or vendor support requirements.
• Test fail-closed behavior carefully in production-adjacent environments before broad rollout.

These controls tend to break down when OT protocols are proprietary and change-sensitive, because even small policy errors can interrupt control traffic or vendor maintenance workflows.

Common Variations and Edge Cases

Tighter microsegmentation often increases operational overhead, requiring organisations to balance isolation benefits against downtime risk, asset discovery gaps, and exception handling. That tradeoff is especially acute in OT, where availability and safety often outrank standard enterprise change cadence.

There is no universal standard for this yet, so current guidance suggests using a tiered model. Highly critical OT assets may need very coarse segmentation with strict allowlists, while IT subnets can tolerate finer-grained policy and more frequent changes. IoT fleets often sit in the middle: they may support limited identity signals, but not full endpoint agents. In those cases, the practical answer is usually a mix of network controls, device identity, and secure onboarding, not a single product category.

Mixed environments also produce exceptions that can overwhelm a rigid design. Shared jump hosts, vendor remote access, safety systems, and legacy broadcast protocols often require explicit carve-outs. The right approach is to document those exceptions as time-bound, reviewable policy decisions, not permanent trust zones. NHIMG’s broader research on non-human identities shows why this matters: the same identity sprawl that affects APIs and service accounts also appears in industrial tooling, remote management channels, and machine-to-machine paths. In short, the segmentation model should fit the environment’s real enforcement points, not an idealized network diagram.

Related resources from NHI Mgmt Group

• How should security teams choose a microsegmentation approach for mixed estates?
• How should security teams run tabletop exercises for lateral movement prevention in IoT and OT environments?
• How should security teams choose an SBOM generation tool for mixed build environments?
• How should security teams choose an API testing framework for mixed REST, GraphQL, SOAP, and gRPC environments?