Skip to main content

Jason Slade

IIoT Director | SCADA | MQTT | Controls Engineering

The TV That Would Not Stay on the IoT VLAN: A Lesson in Network Enforcement

In the architecture of a well-designed network, segmentation is the fundamental principle of security. On September 7, 2026, I successfully completed a major restructuring of my home network, moving all high-risk consumer IoT devices—including my Samsung Frame TV (Model: QN43LS03FADXZA)—into a dedicated IoT VLAN.

The goal was simple: isolation. By assigning the TV to the IoT SSID/VLAN, I ensured its traffic was restricted to 192.168.20.0/24, preventing it from seeing my primary workstation, my NAS, or any other sensitive device on my Default VLAN. For several weeks, the implementation held. The TV operated as a model citizen of the IoT zone.

Then, the regression began.

The Drift: From Isolation to Intrusion

The first signs of failure appeared around October 15. My monitoring system—a lightweight regression check comparing DHCP lease logs against expected IP ranges—flagged an anomaly. The TV was intermittently appearing on the Default VLAN (192.168.0.0/24) with the IP address 192.168.0.243.

Initially, I treated these as outliers—a transient DHCP error or a momentary Wi-Fi handoff glitch. However, by October 21, the behavior stabilized into a continuous presence on the wrong network. The Samsung Frame TV had effectively “wandered” from its assigned isolation zone and was now sitting directly on my management network.

Investigation: Confirming the Rogue Client

To understand why a device would voluntarily abandon its designated network, I executed a two-pronged investigation to rule out software errors and confirm physical layer re-association.

  1. UniFi Controller Verification: I examined the UniFi active-client list. The telemetry was unambiguous: the TV was not just receiving a rogue DHCP lease; it was actively re-associating with the Default VLAN SSID. It was choosing the strongest available access point signal, which, due to physical proximity and signal strength, happened to be the Default SSID.
  2. Samsung REST API Interrogation: To confirm the device’s internal state, I queried the Samsung REST API. Using the model identifier QN43LS03FADXZA, I was able to pull the current network interface status. The API confirmed the device was functioning normally but had selected the Default VLAN SSID as its primary connection.

The root cause was a classic case of “uncooperative” firmware. As a power-management feature (or perhaps a poorly implemented roaming algorithm), the TV would periodically drop the IoT SSID connection—likely during periods of low activity or weak signal thresholding. Once the connection dropped, the TV’s roaming logic took over. It prioritized signal strength over SSID/VLAN integrity, re-associating with the strongest available broadcast: the Default VLAN.

Flowchart: monitoring flags an IP change, UniFi and Samsung API confirm rogue VLAN assignment, and the remediation loop re-enforces isolation via MAC filtering.
Detection and remediation loop for the Samsung TV VLAN hopping issue.

The Critical Distinction: Enforcement vs. Cooperation

This incident highlights a fundamental flaw in many “smart home” security models: the reliance on device cooperation.

Most consumer-grade network isolation relies on SSID steering. The logic is: “I have an IoT SSID, and I assume the device will stay on it.” This is a fallacy. In this model, the network provides a suggestion, but the device holds the ultimate decision-making power regarding which SSID to join. If the device is programmed (or poorly programmed) to prioritize signal strength above all else, your segmentation is only as strong as the TV’s next roaming decision.

Segmentation must be enforced at the network layer, not via SSID selection.

Professional Application: OT/IIoT and IEC 62443

This isn’t just a nuisance for a home lab enthusiast; this is a core principle of Industrial Control System (ICS) security.

In my professional work with OT/IIoT (Operational Technology/Industrial IoT) networks, we operate under the frameworks of IEC 62443. We deal with “Zones and Conduits.” A Zone is a grouping of assets with similar security requirements, and a Conduit is the controlled communication path between them.

In an industrial environment, we never assume a PLC (Programmable Logic Controller) or an HMI (Human-Machine Interface) will “cooperate” with the network design. We assume that a device will attempt to communicate outside its zone if the path is available. Therefore, we do not rely on the device’s configuration to maintain isolation. We enforce the “conduit” through:

  • Layer 3 ACLs (Access Control Lists): Even if a device moves to a different subnet, the router/firewall denies all traffic to sensitive zones by default.
  • 802.1X Port-Based Authentication: A device cannot simply “join” a network. It must authenticate via a RADIUS server, which then dynamically assigns it to the correct VLAN regardless of which physical port or SSID it hits.
  • Micro-segmentation: Using host-based firewalls or identity-based networking to ensure that even within a single VLAN, lateral movement is restricted.

If you design your security around the hope that a device will stay in its lane, you haven’t designed a secure system; you’ve designed a fragile one.

Next Steps and Remediation

For the home network, the remediation is straightforward but requires a shift in mindset. I am moving away from “SSID-based isolation” toward “Network-layer enforcement.” This involves:

  1. Strict ACLs on the Default VLAN: Creating a rule that explicitly denies all traffic from the Samsung TV’s MAC address to the management subnet. Even if the TV wanders, it will be shouting into a void.
  2. Static DHCP/MAC Binding: Ensuring that even if it jumps, it cannot acquire an IP outside the designated range.

The principle remains: Assume the device is unreliable. Design the network to be indifferent to the device’s choices.


Author: Jason
Date: October 26, 2026

← All posts

→ Subscribe by RSS