Zero trust segmentation needs shared device and risk context

At a glance

What this is: This is an Asimily analysis of zero trust IoT segmentation that shows why shared visibility into devices, dependencies, and traffic patterns is necessary to reduce risk without breaking operations.

Why it matters: It matters because IAM, NHI, and infrastructure teams all depend on accurate access boundaries, and segmentation decisions made without context can either expand attack paths or interrupt critical services.

Context

Zero trust segmentation is a governance problem before it is a tooling problem. The control objective is to limit communication to what is necessary, but that only works when security and network teams share the same view of device behavior, dependencies, and risk.

IoT, OT, and IoMT environments make this especially hard because legitimate communications are often narrow, vendor-specific, and operationally sensitive. Without accurate context, segmentation either becomes too permissive to matter or too restrictive to support uptime, which is why zero trust in connected-device environments needs both security and operational discipline.

Key questions

Q: What breaks when zero trust segmentation is applied without device context?

A: Security teams often block legitimate communications because they cannot see the dependencies behind a device’s normal operation. That creates downtime, workarounds, and pressure to reintroduce exceptions. The practical failure is not segmentation itself, but segmentation applied without a business-focused inventory of device behavior, critical services, and the communications required to keep operations running.

Q: Why do unmanaged device dependencies make zero trust harder to enforce?

A: Because segmentation decisions depend on knowing which paths are necessary and which are merely convenient. If teams cannot distinguish required service flows from incidental connectivity, they either over-permit and leave attack paths open or over-restrict and break legitimate work. The risk rises in IoT, OT, and IoMT environments where dependencies are often hidden.

Q: How do security teams know if segmentation is actually reducing risk?

A: Teams know segmentation is working when unnecessary workload communications disappear, exception volume falls, and policy changes are validated continuously rather than assumed. A good signal is that one compromised workload cannot reach adjacent systems without hitting an explicit control. If internal traffic remains widely open, the organisation still has a propagation problem, not a containment strategy.

Q: What is the difference between network segmentation and full Zero Trust enforcement?

A: Network segmentation limits where traffic can flow, while full Zero Trust also verifies identity, context, and authorization before each access decision. Segmentation reduces exposure, but it does not by itself confirm whether a user, device, or workload should be trusted. Full enforcement requires policy-driven controls that adapt to identity, privilege, and current conditions.

Technical breakdown

How network segmentation constrains lateral movement

Network segmentation works by limiting which assets can talk to each other, which reduces an attacker’s ability to move laterally after initial access. In flat networks, a compromised device or account can discover adjacent systems, credentials, and services until it reaches a higher-value target. Segmentation changes the shape of the attack path by forcing communication to follow approved routes rather than ambient trust. For connected devices, that means the device can reach only the specific server, application, or service it genuinely needs, rather than the broader internal environment.

Practical implication: map critical device-to-service paths first, then deny everything else by default.

Why shared device context matters more than firewall rules alone

Firewall rules and VLANs are enforcement mechanisms, not decision logic. They only work when the organisation already knows which devices exist, what they do, and which communications are required for legitimate operations. Security teams may see a risky connection, while network teams may see a business dependency, and both can be correct. The missing layer is context-rich inventory, including device classification, communication patterns, and dependency mapping, so policy reflects real operational behavior rather than assumptions.

Practical implication: build segmentation decisions on observed device behavior and dependency data, not network labels alone.

Why static policies break in dynamic IoT and OT environments

Static segmentation policies age quickly because devices move, software changes, new vulnerabilities appear, and business workflows evolve. A policy that was accurate at deployment can become either over-blocking or under-protective as the environment changes. That is why continuous validation matters: the organisation needs ongoing feedback on device behavior, risk, and communication changes so policies can be adjusted before they create downtime or leave unnecessary access in place. Continuous segmentation is really continuous governance of connectivity.

Practical implication: reassess segmentation whenever device behavior, risk posture, or dependencies change.

Threat narrative

Attacker objective: The attacker’s objective is to move beyond the initial foothold and reach higher-value systems by exploiting overly broad internal connectivity.

1. Entry begins when an attacker gains access through a single compromised device or account in a flat network.
2. Escalation happens as broad internal connectivity lets the attacker discover reachable systems, credentials, and services.
3. Impact occurs when the attacker uses that unnecessary connectivity to reach sensitive or critical assets and widen the incident blast radius.

Breaches seen in the wild

• Verkada camera breach 2021: Admin credentials on Verkada's exposed Jenkins support server let hackers into a support interface and customer cameras at 97 customers.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero trust segmentation fails when connectivity is governed as a network problem instead of an identity and risk problem. The article’s core insight is that the same access boundary must satisfy security, uptime, and device-function constraints. For identity teams, that means machine and device access cannot be treated as static trust zones. Practitioners should align segmentation with who or what is allowed to communicate, for how long, and under what operational context.

Device dependency visibility is the missing control plane for operational zero trust. Security teams cannot safely reduce attack paths without knowing which communications support legitimate workflows, and network teams cannot preserve uptime without understanding risk. That makes shared device inventory, dependency mapping, and behavioral classification a governance requirement, not an optimisation. Practitioners should treat this as a prerequisite for defensible segmentation.

Continuous Segmentation is really continuous policy validation against changing exposure. Static rules decay as devices move, vulnerabilities emerge, and business requirements shift. The named concept here is connectivity governance drift: the gap between current operational reality and the segmentation policy still in force. Practitioners should assume every policy is temporary unless it is continuously reassessed and simulated before enforcement.

IoT, OT, and IoMT environments expose the limits of perimeter-era trust models. These device classes often need narrow, predictable communications, but they are rarely governed with the same lifecycle discipline as human access. That creates a boundary management problem where connectivity and privilege are effectively the same issue. Practitioners should fold connected-device segmentation into broader identity and access governance instead of treating it as a separate network exercise.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Connectivity governance drift: segmentation policies age as devices move, software changes, and dependencies shift, so the real programme risk is no longer initial design but ongoing validation. Teams that do not continuously reassess traffic boundaries will either widen exposure or break operations as the environment evolves.

Zero trust for connected devices works best when it is treated as an access governance discipline, not a firewall tuning exercise. That means device inventory, communication analysis, and policy simulation belong in the same operating rhythm as risk review and exception management.

Using shared visibility to reconcile security risk with operational continuity is the central control theme here, and it maps cleanly to NIST SP 800-207 Zero Trust Architecture for practitioners who need a standards anchor.

For practitioners

• Establish a shared device dependency inventory Build a common view of connected devices, their normal communications, and the business services those connections support before changing segmentation policy.
• Classify devices by operational function and risk Use device identification, function, and criticality to decide which paths are legitimate rather than relying on IP ranges or VLAN placement.
• Simulate segmentation before enforcement Validate proposed rules against observed traffic and dependencies so you can catch blocked workflows before they become outages.
• Reassess policies continuously as environments change Trigger review when devices move, software changes, vulnerabilities are published, or communication patterns shift in ways that alter exposure.
• Prioritise the highest-risk communications first Focus on unnecessary or risky device-to-device paths that enlarge lateral movement options, especially where critical systems sit behind them.

Key takeaways

• Zero trust segmentation only works when security and network teams share the same view of device behavior, dependencies, and risk.
• In connected-device environments, the main failure mode is not a missing firewall rule but a policy built without operational context.
• Continuous validation matters because devices, vulnerabilities, and workflows change faster than static segmentation rules can keep up.

Key terms

• Network Segmentation: Network segmentation divides traffic and resources into controlled zones so access can be restricted between groups, systems, or applications. In remote access design, segmentation limits what a connected user or workload can reach after authentication, which reduces lateral movement and shrinks blast radius.
• Continuous Segmentation: Continuous segmentation is the ongoing validation and adjustment of segmentation policy as devices, dependencies, and risk change. It treats connectivity as a living control, so policy drift does not quietly reopen lateral movement paths or disrupt critical workflows.
• Application Dependency Mapping: Application dependency mapping is the process of observing and documenting how applications, workloads, and services communicate with one another. It gives security teams a factual basis for segmentation policy, helping them distinguish required business traffic from unnecessary or risky connections.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and workload identity in a practitioner-focused format. It helps security and identity teams connect access controls to the real operational patterns their programmes have to govern.