By NHI Mgmt Group Editorial TeamBased on Asimily: “Reduce Risk Faster with Asimily & Your NAC” (August 20, 2026)

TL;DR: Many organisations already own NAC platforms but still use them mainly for authentication because those tools do not know what connected devices are, what they should talk to, or how to enforce segmentation safely at scale, according to Asimily. The governance gap is not network visibility alone but device context, policy simulation, and continuous enforcement.


At a glance

What this is: This is Asimily’s analysis of why NAC deployments often stop at authentication and fail to deliver fully enforced segmentation for IoT, OT, IoMT, and IT environments.

Why it matters: It matters because segmentation programmes stall when teams cannot safely translate device intelligence into enforceable policy, leaving high-risk devices with too much network reach.


Context

Network Access Control can authenticate devices and assign coarse network access, but segmentation depends on richer context than most NAC deployments can see. When teams only know that a device is allowed on the network, they still cannot determine what it is, what it should communicate with, or what traffic would be unsafe to block.

That gap becomes more severe in IoT, OT, and IoMT environments, where devices are diverse, sensitive to traffic interruption, and often tied to business-critical workflows. The article argues that segmentation fails not because the NAC is absent, but because device intelligence, policy simulation, and continuous maintenance are missing from the control model.


Key questions

Q: What breaks when NAC is used only for authentication and not segmentation?

A: Segmentation breaks when the control can admit devices but cannot classify what they are, what they depend on, or what they must not reach. The result is either overly broad access that preserves risk or overly aggressive blocking that disrupts operations. In practice, the missing ingredient is device context, not another network rule set.

Q: Why does device context reduce the risk of unsafe segmentation changes?

A: Device context lets teams base policies on what a device actually is and how it behaves, rather than on traffic guesses or static VLAN assumptions. That matters because many IoT and OT devices have hidden dependencies that are easy to break. Context turns segmentation into a controlled decision instead of a blind restriction.

Q: How can security teams tell whether segmentation policy is failing in production?

A: Warning signs include failed rule compilation, unexpected CPU punt traffic, inconsistent permit or deny behaviour, and degraded control-plane protocols such as routing or spanning tree. The more hidden the issue, the more important it is to compare installed policy with live traffic and hardware utilisation.

Q: Should organisations prioritise blast-radius reduction or broader network visibility first?

A: Blast-radius reduction should come first when the environment contains high-value IoT, OT, or IoMT devices that cannot tolerate outage. Visibility is necessary, but visibility without enforcement does not reduce exposure. The practical sequence is to discover devices, validate policy impact, and then constrain reach in the smallest safe steps.


Technical breakdown

Why NAC alone cannot build segmentation policy

A NAC is designed to decide whether a device may connect and at what broad access level. Segmentation requires a finer model: device type, behavioural profile, firmware, dependencies, and risk. Without that context, policy writers are forced to infer intent from traffic or tribal knowledge, which is unreliable in mixed IoT, OT, and IoMT estates. The technical problem is not enforcement capability, but the absence of an accurate object model for the endpoint. Once a control only knows identity at the network edge, it cannot safely generate least-communication rules for production environments.

Practical implication: Use device context as the input to segmentation policy, not raw network membership alone.

How segmentation orchestration reduces outage risk

Segmentation orchestration separates policy design from policy enforcement. The article describes a chain in which device intelligence feeds vulnerability prioritisation, policy recommendation, policy simulation, and then enforcement through existing NAC and firewall infrastructure. Simulation matters because it exposes blocked flows before production impact occurs. That changes segmentation from a static configuration exercise into a controlled validation workflow. The key technical insight is that safe segmentation depends on proving the policy against observed traffic, not assuming that a rule set derived from templates will fit the live environment.

Practical implication: Simulate segmentation policies against real traffic before pushing them into production.

Why continuous segmentation must track device drift

Device estates are not static. Devices join, move, update firmware, change behaviour, and sometimes become newly exploitable as vulnerabilities emerge. If segmentation policy is tied to a one-time inventory or manual rule set, it decays quickly. Continuous segmentation keeps policy aligned to current device behaviour and changing risk by updating enforcement as the environment changes. That is especially important for operational technology, where stale exceptions often outlive the original business justification. The control problem is lifecycle management, not a single hardening event.

Practical implication: Treat segmentation policy as a living control that must be refreshed as devices and risk change.


Threat narrative

Attacker objective: The attacker objective is to preserve or expand lateral movement opportunities by exploiting weakly segmented device access.

  1. Entry occurs when a device is admitted to the network through NAC authentication without enough context to limit later movement.
  2. Escalation follows when the device can reach systems it does not need, because segmentation policy was never translated from visibility into enforcement.
  3. Impact is expanded blast radius, where a compromised IoT, OT, or IoMT device can reach sensitive services or critical workflows that should have been isolated.
  • Cisco DevHub breach 2024: A misconfigured script left non-public files on Cisco's DevHub; IntelBroker took them and claimed reuse of hard-coded SSH credentials.
  • Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.

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

Device context, not network membership, is the real prerequisite for segmentation. NAC products can tell you that a device is present, but they cannot on their own tell you whether that device is an infusion pump, a PLC, or a building controller with unusual dependency risk. That matters because policy written without object-level context becomes either too permissive or too brittle. Practitioners should treat segmentation as a device-governed control problem, not a VLAN design problem.

Blast-radius control is the real outcome segmentation teams are buying. The strategic value is not simply reducing access, but shrinking the set of systems a compromised device can legitimately reach. In identity terms, this is a control-plane issue: you are governing what a machine identity or device can touch after admission, not merely whether it can connect. Practitioners should anchor segmentation programmes to contained failure domains, especially in mixed IoT and OT estates.

Policy simulation is the missing governance layer between intent and enforcement. Many segmentation projects fail because teams cannot prove a rule set will preserve operations before rollout. A simulation step turns segmentation from an assertion into evidence, which is essential for board, audit, and resilience conversations. Practitioners should require proof of impact before enforcement, not after an outage.

Continuous segmentation exposes the problem of control drift. Devices change, vulnerabilities change, and business dependencies change, so a policy that worked last quarter can become unsafe or irrelevant today. That makes segmentation a lifecycle discipline rather than a one-time network project. Practitioners should govern segmentation as an ongoing state of assurance, not a deployment milestone.

Overreliance on static inventories creates segmentation debt. A spreadsheet, memory, or a one-time discovery pass cannot support durable enforcement in heterogeneous environments. The named concept here is segmentation debt: the growing mismatch between what the policy assumes and what the environment actually contains. Practitioners should measure and reduce that drift before it accumulates into avoidable exposure.

What this signals

Segmentation debt: the longer a team relies on static device knowledge, the more policy intent drifts away from live network reality. That gap matters because heterogeneous device estates change continuously, and the control has to move from one-time design to ongoing assurance.

For practitioners, the useful question is not whether NAC can authenticate devices, but whether the policy layer can prove that isolation decisions will hold without breaking clinical, industrial, or facilities workflows. That is a governance problem as much as a technical one.

Identity teams should notice the bridge here: device admission is only the first decision, while durable segmentation is the part that governs post-admission reach. That is why machine context, not just network trust, is becoming central to modern access control.


For practitioners

  • Build segmentation from device intelligence Use passive monitoring and safe active scanning to identify device type, firmware, and communication patterns before defining enforcement boundaries.
  • Simulate policies before enforcement Validate proposed segmentation rules against observed traffic so production workflows are checked for breakage before rules are pushed.
  • Prioritise devices by exploitable risk Tie tighter segmentation to devices whose vulnerabilities are both present and realistically exploitable in your topology and firmware state.
  • Refresh policy as devices change Reassess segmentation whenever devices join, move, update firmware, or change behaviour so rules do not decay into stale exceptions.
  • Enforce through existing control planes Apply segmentation using the NAC and firewall infrastructure already in place rather than creating a parallel policy stack.

Key takeaways

  • NAC authentication alone does not deliver segmentation, because the control still lacks the device context needed to define safe communication boundaries.
  • The operational value lies in translating discovered device behaviour into enforced policy that can be simulated before production rollout.
  • Segmentation must be treated as a living control, because devices, firmware, and dependencies change faster than static policy can keep up.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-5 — Account ManagementThe article is about governing device access and ongoing enforcement across networked assets.
Recommendation — Apply account and access governance to device admission paths so segmentation follows actual authorized use.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe post centres on translating access decisions into enforceable segmentation policy.
Recommendation — Map device reachability to PR.AA-05 and review entitlements before enforcing network paths.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe article's risk model is about containing compromise so movement cannot spread across the network.
Recommendation — Tie segmentation priorities to credential-access and lateral-movement paths that expand blast radius.
NIST Zero Trust (SP 800-207)Continuous Verification and SegmentationContinuous segmentation and validation align directly with zero trust network principles.
Recommendation — Use zero trust segmentation principles to verify access continuously rather than relying on one-time admission.
ISO/IEC 27001:2022A.8.20 — Network securityThe article is fundamentally about controlling network paths and reducing exposure across device estates.
Recommendation — Implement network security controls that isolate high-risk devices and restrict unnecessary communication paths.

Key terms

  • Network access control: Network access control is the policy layer that decides which devices are allowed to connect to a network. It is related to device access control, but it governs entry to the network path rather than the use of specific local hardware or peripherals once connected.
  • Segmentation Orchestration: Segmentation orchestration is the controlled translation of device intelligence into enforced network policy. It combines discovery, policy generation, simulation, and enforcement so teams can reduce exposure without guessing which business flows will break.
  • Device Context: Device context is the set of signals that describe the endpoint or client used to make a request. It can include device state, browser, version, and whether the device appears managed or compromised. Security teams use it to decide whether access should continue, be limited, or be denied even when credentials are valid.
  • 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

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect machine identity governance with broader access control and resilience programmes.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org