Enterprise WiFi Inventory: AP Placement, Channels, and 802.1X VLANs

Walk into most offices and the wireless network is the only part of the infrastructure nobody can point to. The racks are labeled, the switch ports are patched, and the core sits behind a cage, but the access points hide above ceiling tiles, and the only system that knows where they are is the vendor controller. That arrangement works until it does not: the controller upgrade fails, the company is split in a divestiture and you have to hand over a list of APs, or the security team asks which VLANs broadcast to guests and nobody is sure. An enterprise WiFi inventory closes that gap. It is the set of records that describes every access point you operate: where it physically sits, which channel and transmit power it runs, which SSIDs it advertises, and which networks those SSIDs land clients in.

The discipline is the same one you apply to switches and racks, applied to a layer most documentation overlooks. The three areas where records earn their keep are placement, channel planning, and VLAN assignment. Placement answers where the radio is and why it is there. Channel plans answer how the radios coexist. VLAN assignment answers where a client ends up after it authenticates, which is where 802.1X and its dynamic VLAN behavior live. This guide walks through what to record in each area, how the pieces connect, and how to keep the records honest once the ceiling tiles close over the hardware.

What an Enterprise WiFi Inventory Should Capture

Start with the device record, because every AP is a piece of hardware with the same documentation needs as any switch or server: hostname following your naming convention, vendor and model, serial number, firmware version, the site and building where it lives, and the management address through which it is reached. Wireless hardware adds a layer on top: each radio band has its own BSSID or MAC address, and client troubleshooting reports reference those addresses, not hostnames, so recording them lets you map a complaint about a specific MAC back to a physical box. You also want the power story, whether the AP runs on PoE and from which switch port, because a client density problem at 3 a.m. that turns out to be a PoE budget negotiation on one access switch is a conversation you can only have if the records connect the AP to its port.

The wireless-specific fields are where most inventories stop too early. Record the mount type and orientation (ceiling T-bar, wall bracket, enclosure), the mounting height, the antenna configuration if it is external, the planned channel and transmit power for each band, and the SSIDs the AP is expected to broadcast. The word planned matters: an inventory that only captures what the controller reports today is a snapshot, while an inventory that records intent gives you something to diff against. When the controller shows an AP on channel 36 at 14 dBm and your record says channel 36 at 11 dBm, you have found either an undocumented change or a drift worth investigating, and both are worth knowing about.

AP Placement: Location, Mount, and Coverage Context

Placement records are the part of the inventory that outlives every controller. Vendors come and go, clouds get migrated, but the fact that AP nyc-3f-lobby-02 hangs at 3.1 meters in the northeast corner of the third floor lobby, near the sprinkler line, is knowledge that only exists in your records. Capture the building and floor, a room or zone name, the mount type, the height, and a photo where the ceiling access is nontrivial. Where your teams maintain a predictive or surveyed coverage map, link the AP record to it so the next engineer can see not just where the radio is but why: this AP exists to cover the lobby seating, and its neighbor exists to cover the elevator bank.

Two placement details pay off disproportionately in practice. The first is the cable path: an AP connects to a specific switch port through a specific ceiling run, and when an AP stops responding, the troubleshooting question is whether the radio, the cable, or the port failed, which you can only answer quickly if the inventory links all three. The second is adjacency: recording which APs are intended neighbors turns a channel planning conversation from archaeology into arithmetic, because co-channel interference is a function of which cells touch, and the floor plan relationships are exactly what your records should encode.

Channel Plans: Reuse Without Co-Channel Interference

A channel plan is a deliberate assignment of frequencies to APs, and the record of it belongs next to the placement records. The constraints differ by band. In 2.4 GHz you have exactly three usable 20 MHz channels, 1, 6, and 11, and everything else overlaps, so the plan is a repeating 1, 6, 11 pattern across the floor with 40 MHz bonding disabled, because the band is too narrow for wider channels to ever be worth the interference. In 5 GHz you have far more channels, which buys you reuse flexibility and wider 40, 80, or 160 MHz channels where client density is low, at the cost of more planning: DFS channels share spectrum with radar and require the AP to vacate when radar is detected, which is worth recording because a mysterious channel hop during a storm radar sweep is very hard to explain three weeks later without a note.

The rule that keeps a plan healthy is separation between same-channel cells. When two APs on the same channel hear each other strongly, they share the air, and every frame one transmits is dead time for the other. Keep same-channel APs far enough apart that each hears its neighbors at least 15 to 20 dB below its own served signal, and let adjacent cells sit on different channels wherever the band allows. The plan also interacts with transmit power: high power extends cells and forces fewer APs onto more channels, while moderate power lets density work in your favor. In offices with high AP density, the 5 GHz plan usually looks like a four channel rotation with channel width kept at 40 or 80 MHz, and the 6 GHz band, where available, absorbs the high throughput spaces like meeting rooms and design studios.

SSIDs and VLAN Mapping

The SSID table is the bridge between the wireless and wired halves of your documentation. For every SSID you operate, record its name, the security model (WPA3 Personal, WPA3 Enterprise with 802.1X, or open with a captive portal), the bands it rides, and, most importantly, the VLAN it delivers clients into along with the subnet that VLAN serves. This is the layer where a stale record bites hardest, because an SSID to VLAN mismatch is not an inconvenience, it is a security event: if the guest SSID ACME-Guest gets silently re-pointed from VLAN 800 to VLAN 200, every guest device lands inside the corporate network, and nothing in the wireless controller necessarily flags it. Keeping the SSID to VLAN map in the same records as your VLANs and subnets makes the mismatch a diff you can run, not an audit you failed.

Consistency across sites is the second discipline. In a multi-site organization, the same SSID names should map to the same VLAN purposes everywhere, even when the VLAN IDs differ by site, because help desk documentation, onboarding material, and the roaming experience all assume it. If headquarters puts employees on VLAN 100 and the Berlin office puts them on VLAN 110, the names and purposes stay aligned and the site specific IDs live in the per site records. When a new SSID or VLAN is added, updating the map should be part of the change ticket, the same way a port description update is part of re-patching a cable.

802.1X and Dynamic VLAN Assignment

On enterprise networks, SSIDs secured with WPA3 Enterprise authenticate clients through 802.1X, and that is where VLAN assignment gets interesting, because the network a client lands in may not be the one configured on the AP at all. The flow works like this: the client (the supplicant) associates to the SSID, the AP acts as the authenticator and forwards the credentials to a RADIUS server, and if the server accepts the authentication it can return tunnel attributes alongside the accept. The attribute that matters most is Tunnel-Private-Group-ID, which carries a VLAN ID or name, and the AP honors it by placing the client into that VLAN instead of the SSID’s statically configured one. One SSID becomes many networks: employees land in the corporate VLAN, contractors land in a restricted one, and a device certificate issued to a printer fleet lands in IoT.

This behavior is powerful and it is also a documentation trap. When the actual VLAN a client occupies depends on the result of a RADIUS policy, the static SSID to VLAN map only tells part of the story. Your inventory should record, for each SSID, the static fallback VLAN, the RADIUS server or proxy in play, and the dynamic VLAN rules on the server side: which identity groups map to which VLANs, and what happens on a failed authentication or a MAC authentication bypass for devices that cannot do 802.1X at all, like most printers, cameras, and badge readers. Without those records, the question “why is this device on VLAN 210” has no answer inside your network documentation, because the answer lives in a RADIUS policy nobody wrote down.

Keeping the Inventory Current

WiFi inventories decay faster than most, for two structural reasons. First, APs move: every office reorganization, expansion, and “can you just add coverage in the new kitchen” request physically relocates hardware, and ceiling mounted devices change without anyone opening a rack where the change would be visible. Second, controller systems rewrite state continuously: auto channel power optimization, firmware rollouts, and template pushes all change the channel, power, and SSID state of the fleet as a background activity. The only durable countermeasure is reconciliation on a schedule. Export the controller’s AP list with locations, channels, powers, and SSID assignments, diff it against your records, and walk the mismatches: some will be the controller being smarter than the plan, some will be drift worth reverting, and some will be an AP the records say exists in a room that has been a gym for two years.

Tie the walk to the change process and the audit cadence stays cheap. Every AP move, add, or change gets its record updated in the same ticket as the physical work, with the verification date stamped on the fields that were confirmed. Quarterly, run the export and diff, and treat an unexplained mismatch the same way you would treat an undocumented active switch port: as a finding that needs to resolve into either a record update or a revert. The audit should also verify the security-relevant pairings, that guest SSIDs still map to guest VLANs, that the fallback VLAN on every 802.1X SSID is not the corporate one, and that MAB rules for non-802.1X devices have not silently widened.

A WiFi Inventory People Can Trust

A complete enterprise WiFi inventory answers four questions about every access point: where is it (site, floor, mount, height), what is it (model, serial, radios, firmware), how does it run (channels, power, SSIDs), and where do clients land (static VLAN, 802.1X dynamic rules, fallbacks). Record the intent as well as the observed state, because the difference between the two is where every interesting finding hides. The channels you planned, the VLAN you meant the guest SSID to use, the AP you placed to fix the lobby dead zone: documented intent is what makes controller state interpretable instead of merely observable.

Because an AP is ultimately a device powered from a switch port and delivering clients into a VLAN, the records belong alongside the rest of your infrastructure documentation rather than in a wireless-only silo. Teams that keep their APs as device records in Obelinf, linked to the switch ports and VLANs they depend on, can resolve “which AP covers this room and what VLAN does it hand out” from one lookup, and the same network audit pass that reconciles switches and racks can reconcile the wireless layer with it. Start with the floor that has the most people, record every AP on it, and let the pattern spread from there.