Network Segmentation Best Practices for IoT, OT, IoMT, and IT Networks
Segmentation is one of the few security controls almost nobody argues against. It is also one of the least finished. In the Cisco 2025 Segmentation Report, 79 percent of organizations said segmentation was a priority, 33 percent said they had fully implemented it, and 87 percent said their process needed improvement. The decision to segment is rarely the obstacle. The distance between an approved segmentation strategy and enforced policy on a live network is where programs stop.
That distance has a specific shape. Teams do not know every device on the network. They cannot tell which of the devices they do know about actually carry exploitable risk. They can write a policy but cannot predict what it will break. And the policies they do deploy go stale within months as devices move, firmware changes, and new equipment arrives. The best practices below address those failure points in the order they occur.
Investment in network segmentation security before disaster strikes is essential—but you also need to make sure you invest in the right security. Organizations need a reliable system to manage their connected devices, like Asimily’s Segmentation Orchestration for IoT and OT devices, that transforms segmentation from a manual, fragile process into a continuous, intelligence-driven security control.
Types of Network Segmentation
Segmentation is a category, not a single technique. Most environments run several of the following at once, and the best practices that follow apply to all of them.
Physical Segmentation
Separate switching and cabling create fully isolated networks. It offers the strongest isolation and the worst economics, so it is generally reserved for a small number of high-consequence systems such as safety instrumented systems or isolated control networks.
VLAN Segmentation
Virtual LANs divide a physical network into separate broadcast domains at Layer 2. VLANs are the most common starting point because they require no new hardware, but VLAN membership alone does not restrict what a device can reach once traffic is routed. VLANs need to be paired with access controls at the Layer 3 boundary to function as a security control rather than a traffic management one.
Subnet and Access Control List Segmentation
Devices are placed on separate IP subnets, and routed traffic between them is filtered with access control lists. Downloadable ACLs, or DACLs, are the mechanism most network access control platforms use to apply per-device rules dynamically at the point of authentication, which is what makes this approach workable at scale on networks with thousands of devices that move.
Firewall Zone Segmentation
Internal firewalls sit between defined zones and inspect traffic crossing the boundary. This gives deeper inspection and better logging than ACLs, at higher cost and with more operational overhead. It is common in OT environments following the Purdue model, where a firewall enforces the boundary between enterprise and control networks.
Group-Based Segmentation
Devices are assigned to security groups based on identity, function, or risk, and policy is written between groups rather than between IP ranges. Because policy follows the device rather than its address, group-based segmentation survives the moves and address changes that break subnet-based rules. This is the model most modern network access control deployments are built around.
Microsegmentation
Rather than grouping devices into broad zones, microsegmentation restricts each device or workload to only the communication it actually needs. It is the most granular option and delivers the most risk reduction per policy, and it is also the approach most likely to break something if the policy is written without an accurate picture of real traffic.
[Related: What is Identity-Based Microsegmentation?]
In most enterprise networks, the enforcement point already exists. Network access control platforms such as Cisco ISE, Aruba ClearPass, and Arista are deployed in the majority of organizations of any size, and in most cases they are used for authentication rather than for segmentation. The practices below assume you are not buying new enforcement infrastructure. You are putting the infrastructure you already own to work.
Why Network Segmentation?
Segmenting a network restricts the attack surface to minimize risk. An unsegmented network has far more targets available for attackers, and it’s also easier to spread from one compromised target throughout the network. By using network segmentation security best practices, you naturally limit the blast radius of an attack.
[Related: What is Lateral Movement?]
Think of segmenting your network like running a hotel. A hotel doesn’t just leave all the rooms open to each other; rather, it has different access rules for each area. A divided network gives you increased control over who has access to which resources and lets you monitor activity closely. It’s a way to protect IoT, OT, and IoMT devices running on out-of-date operating systems, too. This, in turn, helps make it easier for healthcare organizations to comply with regulations and prevent or mitigate security breaches.
But while network segmentation is a valuable approach to overall network security, it has its limits. Segmenting a network properly requires considerable attention. You have to make individual profiles for different devices, and you may encounter errors or different policies within a range of devices. If you create a profile that is too restrictive, devices may partially or even completely stop functioning if they can’t make the network connections necessary, which can be very difficult to remedy. Network segmentation security also requires long-term maintenance, and the process is subject to human error. Manual approaches struggle to adapt as new devices are added, applications are updated, and communication patterns evolve. Research shows that many segmentation projects fail to operationalize because manual approaches struggle to adapt as new devices are added, applications are updated, and communication patterns evolve. Without continuous visibility into device behavior and communication dependencies, segmentation policies become outdated quickly and risk blocking critical workflows, such as infusion pumps communicating with electronic medical record systems.
Network Segmentation Security Best Practices
Before you begin setting up your controls to segment your healthcare network, you need to thoroughly understand your organization’s IT infrastructure. Without this foundational knowledge, you risk doing more harm than good. Asimily functions as an intelligence and orchestration layer, continuously building and maintaining a living model of your environment by passively analyzing network traffic, ingesting data from sources like NetFlow, vulnerability scanners, and network management systems, and correlating this information to create a comprehensive source of truth for every device.
Start With a Complete Asset Inventory
Segmentation decisions are only as good as the inventory behind them. A device that does not appear in inventory will not appear in policy, which means it keeps whatever network reachability it had before the program started. Partial inventories produce partial segmentation, and the gap is invisible until an incident finds it. A comprehensive asset inventory is the crucial first step, but is often harder to create than organizations realize.
To gain an accurate inventory, scanning has to be agentless to be complete. Agent-based discovery systematically misses the devices that matter most here: medical equipment under vendor support contracts, programmable logic controllers, building management systems, and legacy equipment that cannot accept new software. It also has to carry more than IP and MAC addresses. Manufacturer, model, function, firmware version, operating system, open ports, and running services are what allow a policy to be written for a device rather than for an address.
Map Communication Flows Before You Draw Boundaries
Every segmentation policy is a claim about which conversations a device needs. Making that claim from a network diagram rather than from observed traffic is how programs break clinical and production workflows. Before defining a single zone, capture what each device actually connects to, on which ports, and using which protocols, over a window long enough to include periodic and seasonal behavior. Nightly backup jobs, monthly vendor telemetry uploads, and quarterly calibration routines do not appear in a one-week capture and will surface as outages later.
Maintain a Consistent Network Audit Schedule and Process
Networks are dynamic structures, constantly undergoing changes. It’s tough to keep pace with the rapid modifications to devices, software, and users on the network. By auditing regularly, you can find and fix vulnerabilities before they become serious problems. Rather than relying solely on periodic audits, modern segmentation requires continuous monitoring that automatically detects when devices are added, behaviors change, or new vulnerabilities emerge.
Sharing the audit results with team members makes it easier to deploy improvements. You can also compare results to previous audits to spot any oversights.
Work with data from Asimily to see which devices are on your network and what risks they carry. This lets you determine which threats are relevant—and pursue smart security policies like segmenting related assets in a group. Asimily’s continuous intelligence enables segmentation policies to adapt automatically as your environment evolves, ensuring protection remains effective without constant manual intervention.
Healthcare organizations should audit at least once or twice a year to protect sensitive data, identify hardware issues, and improve network security and operational efficiency. With continuous monitoring, Asimily complements periodic audits by providing real-time visibility and automated policy adjustments between formal review cycles.
Prioritize by Exploitable Risk, Not Device Count
Organizations running tens or hundreds of thousands of connected assets cannot segment everything at once, and the sequence matters more than the pace. Segmentation programs that work through an inventory alphabetically or by device count consume significant effort while delivering little risk reduction, because the devices that drive risk are a small fraction of the total.
Generic CVSS scoring cannot identify that fraction. A critical-rated vulnerability in a service that is not running, on a device the attacker cannot reach, is not an urgent segmentation candidate. Asimily’s ATT&CK Analysis maps each vulnerability against adversary techniques to determine whether it is actually exploitable on a specific device in a specific environment and topology. The output is a prioritized queue where every item has a documented reason for its ranking, which is also what makes the program defensible in a budget conversation.
[Related: Why Segmentation Stalls Without Risk-Based Prioritization]
Design Every Policy to Least Privilege
The default posture inside a segment should be deny, with explicit permits for the flows a device genuinely needs. Allow-by-default policies with a handful of deny rules invert the security model and leave lateral movement paths open by omission. Least privilege is also what makes the eventual audit tractable, because a permit list is far easier to review than an implicit-allow environment with exceptions layered on top.
Simulate Every Policy Before You Enforce It
The fear of breaking a critical workflow is the single most common reason segmentation stalls in pilot. Teams write policies, hesitate to deploy them, and the program stops with policy on paper and nothing enforced. The answer is not more confidence. It is evidence.
Policy Simulation validates a proposed policy against real, observed traffic before anything is applied, showing exactly which devices and connections would be affected. Dependencies nobody documented surface during simulation instead of during a production outage. Teams iterate on the policy in simulation until the impact is acceptable, then push it. This is what converts a segmentation proposal into something an operations or clinical engineering stakeholder will sign off on, which is usually the actual gate.
Generate Policies in the Format Your Enforcement Infrastructure Expects
Each network access control and firewall platform uses its own policy schema, and they differ substantially. A team fluent in one platform is not fluent in the next, and hand-writing policy across a mixed environment is slow and error-prone. The order and format in which policies are applied also matters, and getting it wrong produces either an ineffective policy or an outage.
Policy Creation generates rules in the native format of the target infrastructure, expressed as DACLs and security groups depending on the platform, which removes the dependency on having an engineer trained on one specific product. Policy Auto-Recommendation goes a step earlier and proposes where to begin and what to prioritize, replacing the meetings teams currently spend interpreting data by hand.
Restrict Third-Party and Vendor Access
Vendor remote access is one of the most reliable entry points into an otherwise well-defended network, and it is frequently exempted from segmentation because someone needs it to work. Give each vendor its own segment, allow only the specific devices and protocols that vendor supports, terminate access through a jump host rather than a flat VPN, and monitor the session. Standing, always-on vendor access to a broad network range undoes much of the value of the rest of the program.
Maintain a Consistent Network Audit Schedule and Process
Networks are dynamic structures, constantly undergoing changes. It is tough to keep pace with the rapid modifications to devices, software, and users on the network. By auditing regularly, you can find and fix vulnerabilities before they become serious problems. Rather than relying solely on periodic audits, modern segmentation requires continuous monitoring that automatically detects when devices are added, behaviors change, or new vulnerabilities emerge.
Sharing the audit results with team members makes it easier to deploy improvements. You can also compare results to previous audits to spot any oversights.
Work with data from Asimily to see which devices are on your network and what risks they carry. This lets you determine which threats are relevant and pursue smart security policies like segmenting related assets in a group. Asimily’s continuous intelligence enables segmentation policies to adapt automatically as your environment evolves, ensuring protection remains effective without constant manual intervention.
Organizations should audit at least once or twice a year to protect sensitive data, identify hardware issues, and improve network security and operational efficiency. With continuous monitoring, Asimily complements periodic audits by providing real-time visibility and automated policy adjustments between formal review cycles.
[Related: Why comprehensive visibility is necessary for effective segmentation]
Treat Segmentation as a Continuous Capability, Not a Project
Networks are not static. Devices are patched, decommissioned, added, and moved. IP addresses change, operating system versions change, and firmware updates alter what a device communicates with. A policy that was accurate at deployment drifts out of alignment with the environment on a timescale of months, and the failure is silent. Nothing alerts when a policy stops matching reality.
Continuous Segmentation tracks whether policies still match the current state of the network and adapts enforcement so it does not fall behind. Devices whose risk profile has changed enough to warrant a different policy tier are identified as the change happens rather than at the next review cycle. The practical test of a segmentation program is not whether it was correct at go-live. It is whether it is still correct 18 months later without anyone having manually revisited it.
Audit Policies to Prevent Sprawl and Drift
Policies accumulate. Rules written for devices that have since been decommissioned stay in place, overlapping rules pile up, and redundant entries expand the policy set well past what anyone reviews. This is an operational risk rather than a theoretical one, because overloaded switches and enforcement points can fail under the weight of policy sets that grew without pruning.
Policy Audit continuously evaluates policies for errors, conflicts, and redundancy, merges and deduplicates where possible, and flags rules that changes elsewhere have made unnecessary. It also produces the auditable record of enforcement effectiveness that board reviews, regulatory inquiries, and compliance audits ask for.
Segment Selectively, Based on Risk
One of the main mistakes that people make regarding network segmentation is to see it as the first or only technique to use. However, networks can employ varying levels of segmentation.
Since it takes time to segment a network, there is a tradeoff in the costs (management difficulty) versus the rewards (increased security) of what you segment. Not every single device needs its own private space. Asimily identifies which devices truly need remediation: those most critical to operations and patient outcomes, or most at risk of exploitation.
You can then use other applicable techniques like patching or exploit mitigation based on Asimily recommendations to protect against the most threatening situations, reserving segmentation for the devices where it delivers the most risk reduction. When segmentation is needed, Asimily generates least-privilege policies aligned with legitimate communication baselines, then orchestrates enforcement through your existing network security tools, automating what was previously a manual, error-prone process. This guided segmentation approach ensures policies are both operationally safe and security-effective.
Document Policies and Govern the Program
Every policy should carry a written rationale: which devices it covers, which flows it permits, what risk it addresses, and who approved it. Undocumented policy is the reason teams inherit rule sets nobody will touch, because no one can establish what will break if a rule is removed.
Governance matters as much as documentation. Segmentation touches network operations, security, and whichever operational group owns the affected devices, and those groups hold an effective veto over anything that threatens uptime. Bring them in during design rather than at deployment, and give them the simulation output rather than asking for trust.
Common Network Segmentation Mistakes
- Segmenting from a diagram instead of from traffic. The network diagram describes the intended architecture. Devices behave according to the actual one.
- Treating VLAN assignment as segmentation. Placing devices on separate VLANs without access controls at the routed boundary organizes traffic. It does not restrict it.
- Over-segmenting early. Programs that begin with the most granular possible policy across the whole environment generate more operational friction than the organization will absorb, and they get rolled back. Begin with the highest-risk population and tighten from there.
- Leaving policy static after deployment. A segmentation program without a mechanism for keeping policy current degrades quietly and continuously.
- Excluding the operational stakeholders. Clinical engineering, plant operations, and facilities teams hold veto power over anything that risks uptime. A program designed without them gets stopped by them.
Compliance Frameworks That Drive Segmentation
Segmentation shows up across most frameworks that govern connected environments, sometimes by name and sometimes through requirements that segmentation is the practical way to meet.
HIPAA. The current Security Rule does not use the word segmentation, though its access control requirements are commonly met in part through it. The Notice of Proposed Rulemaking published in the Federal Register on January 6, 2025 would make network segmentation a required implementation specification rather than an addressable one, alongside a written asset inventory and network map. Although no final rule has been published, no compliance clock is running; organizations planning segmentation work should design to the proposed specification without treating it as a current legal obligation.
PCI DSS 4.0. Segmentation is not mandatory, but it is the standard method for reducing the scope of the cardholder data environment, and reduced scope is the main reason organizations pursue it. Segmentation controls have to be validated at least annually. [Related: PCI-DSS compliance]
NIST. SP 800-207 establishes zero trust architecture, in which segmentation and least-privilege access are structural rather than optional. CSF 2.0 addresses network integrity protection under the Protect function.
[Related: NIST CSF 2.0 compliance]
NIS2. Essential and important entities across energy, transport, health, water, and digital infrastructure are required to take risk management measures covering network security, with segmentation among the expected controls.
NERC CIP. CIP-005 requires electronic security perimeters around bulk electric system cyber systems, with controlled access points at every boundary. This is segmentation written directly into the standard.
[Related: NERC CIP compliance]
CMMC. Defense contractors handling controlled unclassified information use segmentation to isolate CUI environments and limit assessment scope.
How Segmentation Orchestration Operationalizes These Practices
Most organizations of any size already have a network access control platform. Very few have operationalized it for segmentation. The NAC authenticates devices, and the policy work that would turn authentication into enforcement never gets done, because it requires device context the NAC does not have and engineering time the team does not have.
Asimily’s Segmentation Orchestration is the intelligence and policy orchestration layer that sits on top of existing NAC infrastructure, including Cisco ISE, Aruba ClearPass, and Arista. The NAC remains the enforcement point. Asimily supplies the device context, risk prioritization, policy creation, simulation, and ongoing management that close the gap between deployed and operationalized. It addresses eight problems in sequence.
Visibility. You cannot segment what you cannot see. Asimily builds a complete, authoritative, continuously updated inventory across IoT, OT, IoMT, and IT, agentlessly and without disrupting the devices it discovers. Deep packet inspection, AI and ML classification, and multi-source correlation capture services, connections, and firmware versions, not just addresses.
Vulnerability prioritization. ATT&CK Analysis determines whether a vulnerability is actually exploitable on a specific device in a specific environment, so the segmentation queue reflects real risk rather than generic severity scoring.
Policy recommendation. Policy Auto-Recommendation provides automated guidance on where to begin and what to prioritize.
Policy creation. Policy Creation generates policies in the correct NAC-native format, removing the dependency on engineers trained on one specific platform.
Policy simulation. Policy Simulation validates a policy against real, observed network data before anything is applied, showing exactly which devices and connections would be affected.
Policy application. Asimily handles the push to the NAC across platforms, including the order and format requirements that make manual application error-prone.
Continuous Segmentation. Policies are tracked against the current state of the network and adapted as devices, addresses, and firmware change.
Policy audit. Policies are merged, deduplicated, and optimized on an ongoing basis, and the resulting record supports audits and board reporting.
See how it works: Segmentation Orchestration
Segmentation as an Operational Capability
Network segmentation is one of the most useful methods to ensure network security, but far from the only solution. Separating off some parts of the network can help you reduce attacks and limit the blast radius of attacks that do occur. But in order to be truly effective, you need to use segmentation in conjunction with other mitigation strategies.
Asimily treats segmentation as one tool among several and plans mitigation accordingly. Rather than blindly segmenting networks to such an extent that the practice becomes counterproductive, Asimily provides highly relevant information on device risks. Then you can safely and affordably segment what matters. By augmenting your existing network security tools with continuous intelligence, risk-based prioritization, and automated policy orchestration, Asimily transforms segmentation from a static, one-time project into a living security control that adapts as your environment changes.
Learn more about Segmentation Orchestration or contact us today.
Frequently Asked Questions About Network Segmentation
What is network segmentation?
Network segmentation divides a network into smaller isolated zones with controls governing traffic between them. Each zone operates as its own security boundary, so a device compromised in one zone cannot freely reach systems in another.
What is the difference between segmentation and microsegmentation?
Segmentation, sometimes called macrosegmentation, groups devices into broad zones such as a medical device network or a production control network. Microsegmentation restricts each individual device or workload to only the communication it needs. Microsegmentation delivers more risk reduction per policy and carries more operational risk if the policy is written without accurate traffic data.
How do you segment a network without breaking operations?
Build a complete inventory, observe actual communication flows over a long enough window to capture periodic behavior, simulate each proposed policy against that observed traffic, and review the simulation output with the operational stakeholders who own the affected devices before enforcing anything.
How many network segments should an organization have?
There is no target number. Segment count should follow from device risk, function, and communication requirements. Too few segments leave broad lateral movement paths open; too many create a policy set the team cannot maintain, which degrades into the same outcome by a different route.
Does network segmentation require replacing existing infrastructure?
In most cases, no. The majority of organizations already have network access control or firewall infrastructure capable of enforcing segmentation policy. The gap is usually the device context and policy work needed to use it for segmentation rather than authentication alone.
How do you segment devices that cannot run security agents?
Discovery, classification, and behavioral baselining have to come from the network rather than the endpoint. Once a device’s identity and normal communication pattern are established from observed traffic, policy can be written and enforced at the network access control or firewall layer without anything being installed on the device.
How often should segmentation policies be reviewed?
Formal review once or twice a year is a common baseline, but review cycles alone leave months of drift between them. Continuous monitoring for devices that have been added, moved, patched, or changed behavior is what keeps policy aligned with the network between reviews.
Is network segmentation required for compliance?
It depends on the framework. NERC CIP-005 requires electronic security perimeters outright. PCI DSS treats segmentation as optional but as the standard method for reducing cardholder data environment scope. The proposed HIPAA Security Rule update would make it a required implementation specification, though that rule is not final. NIS2 and CMMC both expect it as part of network risk management.
Secure Every IoT Device.
Automatically.
Cyber threats move fast — so should you. Asimily gives instant inventory and smart, prioritized risk mitigation insights for every IoT, OT, and IoMT device — so you can take action before threats strike.