A campus survey discovers mesh backhaul SSIDs alongside user-facing city Wi-Fi names. How should those backhaul SSIDs be handled?
Select an answer to reveal the explanation.
Short Explanation
Backhaul and mesh SSIDs are the city's plumbing, not the lobby guest Wi-Fi. Leave them alone unless the paperwork names them in scope. Defaulting to 'test everything that beacons' is how infrastructure accidents happen.
Full Explanation
Campus surveys often discover mesh or backhaul SSIDs alongside user-facing city Wi-Fi names. Those backhaul SSIDs should be excluded from client-SSID testing unless they are explicitly authorized, because disrupting or experimenting on backhaul can impact production coverage far beyond a single guest network. Civic RoE usually scopes user-facing SSIDs first; mesh links need separate, careful permission. Always attacking backhaul first because it is never production-critical fails by concept: backhaul is often highly production-critical. Treating mesh SSIDs as identical to guest SSIDs and testing them by default fails by concept: different functional roles imply different risk and often different authorization. Renaming backhaul SSIDs in the report so they appear as ordinary user networks fails by concept: falsifying inventory misleads owners and auditors. Exam caveat: even passive enumeration of backhaul names can be sensitive—record them accurately but do not test actively without an explicit annex in the municipal RoE. Operational check: tag mesh/backhaul SSIDs separately in the survey workbook, confirm with the WLAN owner whether any are in scope, leave them observed-only when not authorized, and keep active testing on approved user-facing city SSIDs.