Wireless · Buyer guide
The guest network has its own name and password, and visitors can open a website. That proves access, but not isolation. Before signing off, ask the supplier to demonstrate both what guests can use and what they cannot reach. The acceptance record should reflect your business policy, not just the appearance of a second wireless network.
Write the permission policy first
List the destinations visitors should reach: the internet, perhaps a specific meeting-room service, and any other expressly approved resource. Then list business systems and management interfaces that must remain unavailable. Name who approves an exception. A convenience request should not become an undocumented route to the office network.
Include identity and expiry requirements if the solution uses them. Decide what happens when access expires and which team handles failures. Retention and privacy requirements belong to the business owner; do not accept a default simply because it appears in a controller screen.
Separate isolation from routed policy
Cisco Meraki documents that bridge-mode client isolation restricts communication on the same VLAN, while traffic destined for other VLANs is forwarded and routed normally. Upstream routing and access rules therefore remain a separate check. Behaviour is platform, mode and firmware dependent. Cisco Meraki: wireless client isolation
Do not apply these Meraki details to the Cisco 9176 photograph as universal behaviour for every deployment. The image is an AP reference only. Require the actual AP, management platform and software release in the proposal, then validate the intended policy on that design.
Test allowed and denied paths
Agree test clients and destinations before the visit. Check intended connectivity and approved applications. Then have an authorised tester check specified denied paths, including business resources and management access. Retain the observed result, not merely a screenshot of a rule.
Where IPv6 is enabled or required, include it rather than assuming an IPv4 test proves both. Define guest-to-guest restrictions and any casting or printing exception. Tests should use agreed resources without attempting to access other users’ information.
Keep exceptions reviewable
Record each exception’s destination, purpose, owner and review date. Retest affected paths after material changes. A completed installation still needs an organisation owner for future permission changes; include that responsibility in handover.
Share the business policy alongside the floor plan when discussing guest wireless with RIAM. Request a permission matrix supported by results from the deployed configuration. A separate network name is a design component, not the whole acceptance criterion.
Guest-access acceptance matrix
Use this worksheet in the supplier discussion. Replace example entries with your project information; it is not a completed survey or approved design.
| Path | Required policy | Evidence |
|---|---|---|
| Guest → internet | Allow specified access | Connectivity/application result |
| Guest → business systems | Deny unless explicitly approved | Authorised negative-access test |
| Guest → guest device | Isolation policy stated | Result on agreed clients |
| Guest → meeting resource | Narrow approved exception | Allowed path + adjacent denied path |
Questions buyers ask
Is a separate SSID enough?
No. Check the complete path against the intended policy.
Does client isolation block every business network?
Do not assume so. Verify platform behaviour and routed access controls.
Can guests use a meeting-room display?
Only through a deliberately approved and tested exception.
Should IPv6 be tested?
Include it where enabled or required by the design.
Can we sign off from screenshots?
Use them alongside observed allowed and denied paths.
Discuss your requirements with RIAM’s wireless team, or send a project brief. Scope, availability and commercial terms are confirmed in the project proposal.
Manufacturer references
Research checked 24 October 2026. Use the exact selected model, release and applicable project documents.
