Somewhere on a manufacturing floor there's a machine with exactly one network interface, and it's copper. No radio, no driver for one, no intention of ever getting one. It was built to talk Ethernet and that's the whole conversation. It also happens to be sitting forty meters or more from the nearest switch, on the other side of a slab of reinforced concrete, on a line that gets reconfigured twice a year. Pulling a home run to that spot means core drilling, cable tray, an electrician's afternoon, maybe a manlift and a change request that outlives the project that needed it.
Or you don't pull the cable at all.
Client-bridge mode is an AP that, instead of serving clients, becomes one. It joins another network as a station and re-serves that connection over its own secondary Ethernet port. Think of it as a relay handoff. The machine that only speaks Ethernet hands its baton to the AP standing next to it, and the AP does the actual running, across the wireless track, to whatever's holding the tape at the other end.
An idea how a generic factory floor may look like for whoever has never seen one.
The cable you never pull
Wired-only IoT and machine controllers are everywhere on a factory floor, and they don't care how inconvenient their location is. A client-bridge AP next to the machine means no new conduit, no cutting into someone's process to reroute cable, and if the line gets rearranged next quarter, you unplug one box and move it instead of re-pulling forty meters of Cat6. The machine plugs into the AP's Ethernet port and never learns it isn't wired to the switch anymore.
One practical note before anyone bolts an office AP above a milling machine: dress the runner for the conditions. A production floor means dust, vibration, coolant mist, temperature swings, and the occasional forklift with ambitions. Either put the AP in a protective enclosure (vented, non-metallic unless you enjoy strangling your own radio), or skip the improvisation and use a ruggedized AP with a proper IP rating built for exactly this. The bridge is only as reliable as the box it lives in, and a client-bridge that dies of dust ingestion takes the machine's only network path down with it.
And don't forget the part everyone forgets: power. The AP normally takes PoE from the switch and the entire point of this exercise is that there's no cable to a switch. So the bridge needs to be fed locally, with a PoE injector or a DC adapter off whatever power is already at the machine (there's always power at the machine, that's what makes it a machine). Budget for it in the design, because an AP with a perfect wireless uplink and no electrons is just an expensive enclosure ornament.
Above is a short drawing showing what we want to achieve
Securing the handoff
The baton exchange happens over the air, so the obvious next question from any serious floor is: what protects it? Full disclosure: my test set is Extreme (IQ Engine / XIQ and XCC), so the specifics below are from that stack. But every vendor has this feature under some name (Cisco calls it a workgroup bridge, for one), and the pattern of what to check translates directly. This is also one of those places where the datasheet and the deployment tell different stories.
On paper the dropdown offers the full lineup: Pre-Shared Key, Open, WPA3-SAE, OWE. The docs still insist client-mode radios only do PSK or Open. Both are right, for different boxes. The AP460C (Wi-Fi 6) stops where the docs say, but the AP3000 (Wi-Fi 6E) honors the whole menu. I tested on the AP3000, and WPA3-SAE on the client-mode radio works on current firmware.
Skip Open and OWE, though, even if they're on the menu. Neither authenticates the network, so the bridge can't verify it's joining your infrastructure: anyone broadcasting the same SSID gets an unattended AP that associates and hands over the whole wired segment behind it. OWE encrypts that traffic, which sounds like an upgrade until you realise it may be encrypting straight to the wrong party. A person on a laptop might notice the evil twin. A bridge bolted to a machine will reconnect to it forever. For a link carrying a machine's only network path, the runner needs to know whose hand the baton lands in. PSK at minimum, SAE if the firmware's current.
Notice also what neither the dropdown nor the docs offer here: anything Enterprise.
802.1X on the bridge uplink is an XCC story. The on-premises controller supports Enterprise authentication for the client-mode radio, so the AP itself can present a certificate or credentials like any other supplicant. If the security team insists the bridge authenticates as a first-class 802.1X citizen (and on a manufacturing network, they should at least ask), that requirement quietly decides your architecture for you: XCC, not cloud.
Worth noting what the bridge does not give you: the wired machines behind it never authenticate as individual wireless clients. The AP runs the leg on their behalf, one supplicant for the whole team. Per-device identity, if you need it, comes from the wired side (VLAN tagging into the bridge port), not from the wireless handshake.
On the RF side, put the uplink on 5 GHz at 20 MHz, and do it on purpose. The 20 MHz width isn't a compromise, it's the choice that fits an actual channel design: narrow channels mean more of them, cleaner reuse across the floor, and a bridge that slots into the plan instead of trampling it. A machine controller pushing telemetry and the occasional firmware image doesn't need 80 MHz of spectrum any more than a relay runner needs four lanes. And stay off 2.4 GHz entirely if you can. On a production floor that band isn't just crowded with Wi-Fi, it's crowded with everything else: Bluetooth, Zigbee, proprietary sensor radios, badly shielded motors, the microwave in the canteen. In IoT environments especially, 2.4 GHz is less a band and more a mosh pit. Your machine's only network path doesn't belong in it.
Then there's the addressing question. The client-mode profile offers a NAT/DHCP toggle, and my advice is to treat NAT as the standard: the AP hands the wired device an address from its own small scope and hides it behind the radio's identity, which is honest about the fact that the wireless side only ever has one real client anyway. The caveat is directional. NAT is invisible as long as the machine initiates the traffic, but if the machine is the server (a SCADA master connecting inbound to a Modbus device), the connection stops at the NAT boundary. The escape hatch: port forwarding rules, up to 48 in my setup. Not elegant, but one static rule per service is workable. Know which direction your machine's first packet flows.
Which brings up a confession about the name. "Client-bridge" suggests a bridge, and with NAT on it isn't one. It's a router with a DHCP server and a wireless WAN port. That's less a limitation of the feature than of the radio: an infrastructure station speaks three-address 802.11 frames, with room for exactly one identity, so the wired devices are always masquerading behind the radio's MAC anyway. NAT is just the honest version of that.
When you actually need a bridge, XCC's Transparent Bridge mode (GE2 set to Bridge) delivers one. The device keeps its own MAC and VLAN tags across the link and sits on the LAN as itself: no NAT boundary, no 48-rule budget, the SCADA master connects straight to the device. The price is an on-prem XCC controller on site. Names aside, the baton still gets across the track. With NAT you hired a courier. XCC hands you back a relay runner carrying the original baton.
Above you can see the settings that has been made to get the transparent working on XCC.
Proof, not promises
Claims about dropdowns are cheap, so here is the client-bridge doing WPA3-SAE against a proper infrastructure SSID, on air, with receipts
The configuration is unremarkable on purpose: client-mode radio, target SSID, WPA3-SAE, done. The interesting part is what the air says. Monitor-mode capture on the target channel, filtered to the bridge radio and the serving BSSID:
That auth algorithm field is the whole ballgame. Legacy open-system authentication says algorithm 0; these frames say SAE, and the commit/confirm pair is the Dragonfly handshake actually happening, not a checkbox claiming it will. Then the association:
The RSN information element in the Association Request names its AKM suite as SAE, and the management frame protection bits are set, because WPA3 doesn't ask politely about PMF, it requires it. Association Response comes back successful, and the four-way handshake seals it.
Keys derived, link up, machine none the wiser. The documentation says this radio can't do what it just did on camera. Believe the packets.
A ping test from my laptop (Simulating the IOT device) only connected to eth1 AP that is powered by PoE injector (eth0) proving it:
And now the fun part: your AP as a wireless 4G Ethernet router
Here is the thing about client-bridge mode: the target network doesn't have to be infrastructure. It can be the phone in your pocket.
An AP client-bridged to a phone's Personal Hotspot is, functionally, a wireless 4G/5G Ethernet router. Pop-up site with zero infrastructure, a temporary control point, a demo with a "we need connectivity here in twenty minutes" deadline: plug the wired gear into the AP's Ethernet port, put a phone next to it, and the whole stack is online through whatever's in your pocket, which I wish I'd had on more than one occasion when I am at a customer location with my demo kit.
Then have your phone connect to your PC (in my case MAC) and then you can see what your phone is using, in this case it is channel 44 on 80 Mhz band…nice.
Make a capture and see it working, data rate at 1134 Mb/s
My tests has been pretty solid once everything is up and running but even in 2026 it can be a bit tricky. I had to reset my Iphone (17pro) at some point to get the access point working again so use it at your own risk :-).
One iPhone caveat worth knowing (documented by Apple, but not read by anyone (Ahum): the Maximize Compatibility toggle. Switched on, the hotspot drops to 2.4 GHz, WPA2, 20 MHz. Switched off, you get 5 GHz at up to 80 MHz, WPA3, and the VHT Operation and HE Capabilities elements in the frames to prove it. For a bridge carrying real traffic, leave it off. Your baton deserves a runner in carbon spikes, especially when using it as 4/5G router.
How do you manage these client-bridge AP’s during these scenario’s while they are in the field you ask? Well they're not remotely manageable once they no longer have an Ethernet uplink to the network. While being a client-bridge you will see them connected as clients to your network but if you need to make any changes, you will have to reconnect it to the network again so it can be managed and then put it back into its place (after you tested it ofcourse).
