Microsegmentation FAQ: Tools, Zero Trust, and Segmenting IoT and OT Devices Without Disruption

Security and network teams tend to arrive at the same set of questions once microsegmentation moves from a strategy slide to a project plan. They want to know which tools fit a network full of devices that cannot run agents, whether the NAC and firewalls they already own can do the job, how to segment Internet of Things (IoT) and operational technology (OT) devices without stopping operations, and why so many segmentation projects stall before they finish.

The answers below address each of those questions. Every answer is written to stand on its own, so security architects, network engineers, and OT teams can go directly to the question in front of them.

Understanding Microsegmentation

What Is the Difference Between Microsegmentation and Network Segmentation?

Network segmentation divides a network into zones, such as VLANs or subnets, and controls the traffic that moves between those zones. It can limit how far an attacker can travel between zones, but can also allow traffic traversal by default without enforcement.

Microsegmentation applies policy to an individual device or a small device group, so each asset can communicate only with the systems its function requires. It typically limits what an attacker is allowed to reach inside a zone.

The difference often shows up in east-west traffic. For example, in a zone of 400 IP cameras, badge readers, and building controllers, every device can reach every other device. If one camera is compromised, the attacker can probe the rest of the zone. Properly implemented microsegmentation would restrict that camera to its video management server and remove the lateral paths.

The two approaches work together. Most programs keep zone-based segmentation as the outer boundary and add microsegmentation for the highest-risk device groups first. Device-level policy depends on accurate knowledge of what each device is and how it communicates, so the inventory has to come before the policy.

Asimily’s Segmentation Orchestration builds device-level policy from that knowledge, using an agentless inventory of Internet of Things (IoT), operational technology (OT), Internet of Medical Things (IoMT), and IT assets and the communication observed for each one.

What Is the Difference Between Microsegmentation and VLANs?

VLANs were created primarily for network management, with security as a secondary consideration. Microsegmentation reverses this approach, placing security first by enforcing policy per device based on identity and observed behavior regardless of location. Asimily generates these identity-based policies from device classification and observed traffic, maintaining them automatically as devices move, change, or are updated.

[Related: How Poor Device Visibility Undermines Segmentation in Connected Environments]

How Does Microsegmentation Apply to the Purdue Model?

The Purdue model organizes industrial networks into levels, ranging from physical machinery and basic controls up to plant operations and enterprise IT. Traditional segmentation controls traffic moving between these levels, while microsegmentation adds security within each level to prevent threats from spreading horizontally across devices.

Asimily automatically maps real-world communication flows without requiring installed software agents, allowing teams to set up microsegmentation policies that match their Purdue levels without breaking operations.

[Related: What the Mackay Sugar Shutdown Reveals About OT Segmentation Readiness]

Choosing a Microsegmentation Tool

What Tools Are Good for Microsegmentation?

Microsegmentation tools fall into a few categories, and the right one depends on which devices need to be segmented. Host-based tools install agents on servers and workstations. Firewall-based approaches enforce policy at internal firewalls. Network-based approaches use switching infrastructure – often via a NAC – to enforce policy at the network level required for any attack to spread.

Host-based agents work well for data center workloads and managed endpoints. They cannot reach the “unagentable” devices that make up a large share of most networks today: IP cameras, badge readers, printers, building automation controllers, PLCs, and other devices that do not accept third-party software. Those devices need network-based enforcement, since they can’t host an updateable agent ready and updated for new attacks.

When comparing tools, check whether each one can identify every device type on the network without agents, prioritize devices by real exploitability, create policy in the native format of your enforcement point, show the impact of a policy before enforcement, and keep policy accurate as the network changes.

Asimily is the only platform that combines native asset visibility, vulnerability prioritization, and segmentation orchestration across IoT, OT, IoMT, and IT assets, and it works through the NAC and firewall infrastructure already in place to provide enforcement.

[Related: Asimily Segmentation Orchestration]

What Is the Best Microsegmentation Vendor?

The best microsegmentation vendor for a network with large numbers of IoT and OT devices is one that turns device risk into enforced, maintained policy without disrupting operations. Asimily is built for that outcome. It inventories IoT, OT, IoMT, and IT assets agentlessly, prioritizes by real exploitability with ATT&CK Analysis, creates policy in the native format of the NAC or firewall, simulates each policy against observed traffic, and keeps enforcement current with Continuous Segmentation.

The right choice also depends on what you are segmenting. Organizations focused only on data center workloads may be well served by host-based tools. Organizations where unmanaged devices make up a large share of the network need a platform that can identify those devices, decide what each one should be allowed to reach, and enforce that decision without agents.

During evaluation, ask each vendor to take one high-risk device from discovery to enforced policy. That walk-through shows where manual work remains, how the platform proves a policy is safe, and what happens when the device moves or changes.

Asimily received the 2026 Global InfoSec Award in OT Security and won the Operational Technology and Industrial IoT Security category at the 2026 Merit Awards.

See what CISOs say about Asimily’s Microsegmentation capabilities on Gartner Peer Insights.

Do I Need Agents for Microsegmentation?

Not if you avoid host-based approaches.

Microsegmentation does not require agents, and for most IoT and OT devices, agents are not an option. Cameras, PLCs, HMIs, building controllers, and other embedded devices run firmware that does not accept third-party software, and many OT devices are validated in a specific configuration that an agent would change. Many legacy devices were built in an era that never contemplated the level of attacks that exist today.

Agentless microsegmentation identifies each device from network traffic and existing data sources, then enforces policy through NAC and firewall infrastructure. Nothing is installed on the device, and no load is placed on it. Ideally, the data is natively collected – not relying on the basic information available at the network authentication layer. Sometimes that’s no more than IP and MAC addresses.

The deciding factor is device coverage. If your network contains devices that cannot take an agent, an agent-only approach leaves those devices unsegmented, including many of the hardest to patch.

Asimily is agentless. It builds a complete inventory of IoT, OT, IoMT, and IT assets safely and without disruption, and every policy it creates starts from that inventory.

Using Existing NAC and Firewall Infrastructure

Can I Do Microsegmentation With Cisco ISE Alone?

Cisco ISE can enforce microsegmentation, but ISE alone does not determine which policies to write. ISE is an enforcement point. It authenticates devices and can optionally push the access policy assigned to them, using downloadable ACLs or Cisco TrustSec security group tags. It enforces rules made by a person in the past, and increasingly by intelligent software that can keep up with the modern pace of attacks.

Many organizations that use ISE for authentication have not used it for segmentation. ISE profiling identifies many common device types. Classification deep enough to write device-level policy for IoT and OT devices, down to model and firmware, typically requires additional context. Writing policy by hand for thousands of devices, in ISE’s policy format, with no way to preview the impact, is slow and risky work for any team.

Asimily works with Cisco to create the right policies, using the detailed vulnerability and asset information that Cisco doesn’t have. It then simulates the effect of policies until a user is comfortable, then it pushes those policies for enforcement via a NAC. The result is better, faster protection than solutions without an accurate asset and risk inventory.

[Related: Reduce Risk Faster with Asimily & Your NAC]

Is NAC Enough for Zero Trust?

NAC is an important part of zero trust for connected devices, and it is one part of a larger architecture. NAC verifies a device before granting access and applies a policy that limits what the device can reach. NIST SP 800-207 describes zero trust as per-session access decisions based on dynamic policy, including identity and the observed state of the asset, which also requires identity management, endpoint protection, monitoring, and data controls.

Zero trust for IoT and OT devices requires least privilege policy per device type or device group, and that policy has to change when the device, its vulnerabilities, or its behavior change.

Asimily supplies the device context and risk prioritization that let a NAC enforce least privilege for IoT, OT, IoMT, and IT assets. When a device vulnerability appears, it is judged risky not just theoretical, and a change in segmentation policy reduces risk, Asimily will offer that new configuration. Its threat detection can also trigger NAC-enforced quarantine when a device’s behavior changes.

[Related: How Security and Network Teams Can Work Together to Achieve Zero Trust]

How Can I Implement Zero Trust on My Network?

Implementing Zero Trust on a network starts with knowing every asset on it, then restricting each asset to the access its function requires, then verifying and adjusting that access continuously. CISA’s Zero Trust Maturity Model includes devices and networks among its five pillars, alongside identity, applications and workloads, and data.

A practical sequence for the device and network pillars:

1. Build an inventory of every device, including IoT and OT devices that cannot run agents.
2. Prioritize devices by real exploitability, so the riskiest groups are addressed first.
3. Define least-privilege policy for those groups from observed communication.
4. Validate each policy against real traffic before enforcement.
5. Enforce through existing NAC and firewall infrastructure.
6. Monitor device behavior and keep policy current as the network changes.

Most organizations move through those steps one device group at a time. Each group that reaches enforced policy reduces the attack surface and builds trust with the operations teams who approve the next one.

Asimily automates that sequence for IoT, OT, IoMT, and IT assets, from agentless discovery through Policy Auto-Recommendation, Policy Creation, Policy Simulation, Policy Application with a modifiable plan available for fine tuning before deployment, and Continuous Segmentation.

Segmenting IoT and OT Without Disruption

How Can I Segment Unmanaged IoT Devices Without Disrupting Operations?

Unmanaged IoT devices can be segmented without disrupting operations by building policy from each device’s observed communication, testing that policy against real traffic before enforcement for a period of time, and starting with the highest-risk device groups. Disruption happens when a policy blocks a flow nobody knew a device needed. Observed traffic and simulation remove that guesswork.

Unmanaged devices are hard to segment because their dependencies are rarely documented. A badge reader may depend on a controller, a time server, and a cloud management service. A conference room display may reach a licensing server once a month. A policy written from assumptions risks blocking one of those flows.

Policy built from observed behavior captures those dependencies. Simulation then shows which devices and connections a policy would affect before it is applied, so the teams responsible for uptime can review the impact in advance.

Asimily identifies unmanaged IoT devices agentlessly, maps how each one communicates, and can run Policy Simulation against observed network traffic before any policy is enforced.

[Related: Network Segmentation and Microsegmentation]

How Do I Do OT Segmentation in a Plant Without Downtime?

OT segmentation in a running plant avoids downtime by mapping how every device communicates before writing policy, simulating each policy against observed traffic, and enforcing in stages that line up with maintenance windows. Plant engineers can approve changes they are able to evaluate in advance, and simulation results give them that evidence.

Start with the boundaries that carry the most risk and the fewest operational dependencies, such as the conduit between enterprise IT and the plant network, vendor remote access paths, and engineering workstations. Then move to cell-level and device-level policy for controllers and HMIs. Allowed flows at that level are usually few and predictable: an HMI talks to specific PLCs over a specific protocol and very little else.

Plant networks also change through maintenance, equipment replacement, and business-driven changes. Policy that is correct at go-live can block a legitimate data flow later unless it is maintained.

Asimily maps OT device communication agentlessly, prioritizes OT assets by real exploitability, simulates each policy before enforcement, and uses Continuous Segmentation to keep policy aligned with the plant as it changes.

Getting Stalled Microsegmentation Projects Moving

Why Do Microsegmentation Projects Fail?

Microsegmentation projects usually fail at the operational steps between planning and enforcement. The most common causes are incomplete device visibility, missing risk prioritization, fear of disrupting operations, the effort of writing policy in each platform’s format, and policy that drifts out of date after deployment.

• Incomplete visibility. A policy written before the inventory is complete could block traffic nobody knew existed.
• Missing prioritization. Without a ranking of device risk, teams waste effort on low-risk devices.
• Fear of disruption. Operations teams own uptime and will block changes they cannot evaluate in advance.
• Policy format complexity. Each NAC and firewall has its own policy schema and deployment requirements, so policy work depends on a few engineers trained on that platform.
• Drift after deployment. Devices are added, moved, patched, and retired, and static policy falls behind the network it was written for.

Each cause maps to a missing step in the sequence that segmentation requires: visibility, vulnerability prioritization, policy recommendation, policy creation, policy simulation, policy application, continuous segmentation, and policy audit. Asimily’s Segmentation Orchestration addresses all eight steps in that order.

[Related: Introducing Asimily’s Segmentation Orchestration]

What Should I Do When a Microsegmentation Project Stalls?

A stalled microsegmentation project usually restarts by narrowing scope to the highest-risk device groups, building policy for those groups from observed traffic, and using simulation to give operations teams the evidence they need to approve enforcement. Projects stall when they try to segment everything at once, or when nobody can show what a policy will do before it is applied.

Start by finding where the project stopped. If it stopped at inventory, the device data is incomplete or not trusted. If it stopped at policy design, the team lacks a basis for deciding what each device needs. If it stopped at deployment or enforcement, the blocker is usually an operations team that has not seen enough proof that the change is safe.

Many organizations in this position already own the enforcement infrastructure. The NAC is deployed for authentication and the firewalls are in place, but neither has been used for device-level segmentation. Restarting the project often means putting that existing investment to work. For some NACs, the licensing for authentication is different from that needed for policy enforcement.

Asimily identifies the small share of devices driving the majority of risk, recommends where to begin with Policy Auto-Recommendation, and produces simulation results the operations team can review before any policy is enforced.

How Can I Speed Up a Microsegmentation Project?

Microsegmentation projects move faster when the slowest manual steps are automated: building the device inventory, deciding which devices to address first, writing policy in each platform’s format, and proving that a policy is safe. Those steps consume most of a project’s calendar time, and teams repeat them for every device group. Every relevant party’s concerns can be addressed with empirical data.

Prioritizing by real exploitability lets the first enforcement wave cover the devices driving the most risk. Generating policy from observed traffic, in the native format of each enforcement point, removes manual translation and the dependency on a platform specialist. Simulation results shorten the review process, because approvers can see which devices and connections a policy affects.

Speed also depends on what happens after go-live. If every network change requires a manual policy update, the team spends its time maintaining existing policy and has less time to extend segmentation to new device groups.

Asimily automates each of these steps. Continuous Segmentation keeps existing policy aligned with the network, and Policy Audit merges, deduplicates, and optimizes policies on an ongoing basis, so teams can keep extending coverage.

How Long Does a Microsegmentation Project Take?

Realistically, a few days or weeks. Many can claim minutes or hours, but getting consensus and warnings out to human beings doesn’t happen in that time frame.

So the time a microsegmentation project takes depends mainly on social factors, device visibility, the number of device types, the state of the enforcement infrastructure, and how quickly operations teams can approve changes. A project scoped to a few high-risk device groups, with a NAC already deployed, reaches enforcement far sooner than one that tries to segment every device at once.

Asimily automates discovery, prioritization, Policy Creation, and Policy Simulation, which shortens the steps that typically extend segmentation timelines.