How to Document a Wireless Network: SSIDs and Groups

Wireless is the layer where documentation most often stops. The racks have labels, the patch panels are trimmed, and the VLANs are named, but the SSIDs clients actually join exist only inside whichever controller is running this year. That arrangement holds until the controller is replaced, a site is handed over during a divestiture, or someone asks which network the guest SSID really delivers, at which point the answer is buried in a configuration screen nobody exported.

A wireless inventory fixes that by treating each SSID as a record you own, separate from the hardware that broadcasts it. This guide walks through what to record for every wireless network, how to organize those records into groups, how to keep names consistent across sites, and how to keep the whole thing from quietly drifting out of date.

What a Wireless Inventory Is For

A wireless inventory exists to answer a handful of questions without a login to a vendor portal. Where does a client that joins a given SSID end up, meaning which VLAN and subnet does it receive. Which SSIDs do we broadcast, and which are supposed to exist. What is the security model on each one. And which access points are responsible for each name, so a coverage complaint has somewhere to go. If your records answer those four, you have an inventory; if they only list hardware, you have a device list.

The distinction matters because the two live at different layers. An access point is hardware with a serial number and a cable, while an SSID is a logical network that may be broadcast by twenty access points across three buildings. Documenting them in the same table forces duplication, because the SSID appears once per AP, and duplication is where drift starts.

What to Record for Every SSID

Start with the identity: a name for your own reference and the SSID that appears in the client’s wireless list. The SSID should be unique within its group so you cannot accidentally document two different networks under the same broadcast name. Then add the operational fields that decide behavior. The security model tells you how clients authenticate, which matters because it determines whether a client lands in a static VLAN or receives one from RADIUS. The bands record whether the network rides 2.4 GHz, 5 GHz, 6 GHz, or several of them.

The field that earns its keep most often is the VLAN and subnet the SSID delivers clients into. That single mapping connects the wireless record to the wired network, and it is the value you reach for during incident response. Round the record out with a note on ownership and a status, so a retired SSID can be marked as such instead of deleted, and the history stays intact.

Recording SSIDs Separately from Access Points

Keep the SSID record and the access point record apart, and link them through the VLAN and site they share. The access point still belongs in your device inventory with its hostname, model, serial number, and switch port, because a coverage problem is a hardware problem until proven otherwise. The SSID record describes the network itself, including the security model and the VLAN mapping that no single access point owns.

This split pays off during moves. When an access point is relocated to fix a dead zone, only the device record changes; the SSID record and its mapping are untouched. When a new SSID is added, only the wireless record changes, and every access point that broadcasts it is already covered by the shared name. The two lists describe different things, and keeping them separate is what lets each stay accurate.

Organizing SSIDs into Groups

A flat list of SSIDs is fine for a homelab and unmanageable for an organization with several sites. Groups solve that the same way folders do for subnets. A group carries a name, a stable slug, an optional description, and an optional parent, so you can nest them by purpose or by site. Most teams settle on groups for corporate, guest, and IoT networks, sometimes nested under a site group when the VLAN IDs differ by location.

The parent relationship is what keeps a growing list readable. You can hold one parent per site, with the same three purpose groups beneath each, and read the structure as a map of how wireless is used. That structure also answers a security question quickly, because everything in the guest group should map to guest VLANs and nothing else.

Keeping SSID Names Consistent Across Sites

The rule that keeps a multi site wireless inventory usable is simple: name SSIDs by purpose, not by location, and reuse the names everywhere. If headquarters puts employees on ACME-Corp and the Berlin office uses Berlin-Staff, the help desk instructions, the onboarding guide, and the roaming expectations all break at the site boundary. Purpose based names keep them working even when the VLAN IDs behind them differ.

Keep the local detail in the per site records rather than in the SSID name. The SSID says what the network is for; the record says which VLAN it uses at that site. When a network is added or retired, the change is a group and name decision that applies consistently, plus a per site mapping update, which is a far smaller task than reconciling five differently named networks that turn out to be the same thing.

Mapping SSIDs to VLANs and Subnets

The SSID to VLAN mapping is the bridge between the wireless and wired halves of your documentation, and it is where a stale record causes the most damage. An SSID is not merely a name clients select; it is the decision point that places a client into a specific network. Getting that wrong is not an inconvenience, it is a segmentation failure, because a guest device that lands in a corporate VLAN has the same access as a workstation.

Record the mapping explicitly for every SSID, and treat it as part of the change process the same way a port description update is part of re patching a cable. Where clients authenticate through 802.1X, record the static fallback VLAN as well, because the VLAN a client actually receives can be assigned by the RADIUS server rather than the AP configuration. Because that mapping spans the wireless and wired halves of the network, it helps to keep the wireless records next to your VLAN and subnet records rather than in a separate wireless only file.

Keeping Wireless Records Current

Wireless inventories decay faster than most, for two structural reasons. Access points move during office churn, and controller systems rewrite state continuously through auto channel and power changes, firmware rollouts, and template pushes. The forced labor saving move is reconciliation on a schedule: export the controller’s SSID list with its VLAN assignments, diff it against your records, and walk the mismatches one by one.

Treat an unexplained mismatch the way you would treat an undocumented active switch port, as a finding that has to resolve into either a record update or a revert. The reconciliation should pay particular attention to the security relevant pairings, that guest SSIDs still map to guest VLANs, that the fallback VLAN on every enterprise SSID is not the corporate one, and that no SSID is broadcasting that your records do not list at all.

A Wireless Inventory People Can Trust

A wireless inventory that people actually trust answers four things about every network: what it is, how clients authenticate, where they land, and which access points broadcast it. Record the intent as well as the observed state, because the gap between the two is where every interesting finding hides. The VLAN you meant the guest SSID to use and the SSID you retired last quarter are both only knowable if they were written down.

The practical next step is to start on the floor with the most people. Record every SSID you can name, group them by purpose, note the VLAN each one should map to, then reconcile against the controller and fill the gaps. Teams that keep wireless records beside their wired ones, for example by tracking SSIDs and wireless LAN groups in Obelinf alongside the VLANs, subnets, and devices in the same inventory, can keep the wireless layer searchable and audited instead of locked in a controller.