Guest, BYOD and contractor access without regret

Guest Wi-Fi is where good security architectures go to be quietly undermined. The pattern is familiar: an isolated guest network gets a small exception for a printer, then a shared drive, then a supplier's laptop, and eighteen months later it is a flat network with a friendly name.

The non-negotiables

Guest traffic terminates on its own VLAN and reaches the internet only. No exceptions, no printers, no "just this one file share".
Layer 2 client isolation on, so guests cannot see each other.
Per-client rate limiting, sized so one visitor syncing a photo library does not starve the room.
Separate DHCP scope with a short lease, and separate DNS.
No multicast or broadcast forwarding.

Captive portals, honestly

Captive portals do three things: they display terms of use, they capture an email address, and they annoy people. They provide essentially no security.

If you need one for legal or marketing reasons, be aware of the friction points:

MAC randomisation means returning visitors are new visitors, repeatedly.
Modern client OSes use captive-portal detection endpoints that must not be blocked, or the portal never appears.
HSTS and certificate pinning break naive HTTPS interception. Redirect on HTTP only.
6 GHz cannot host an open BSS at all, so a portal-based guest network is a 2.4/5 GHz service unless you use OWE.

A better default: OWE

Enhanced Open (OWE) gives unauthenticated encryption with zero user interaction. Guests connect exactly as they would to an open network, but their traffic is encrypted over the air. Where a portal is not legally required, this is simply better.

Because older clients do not support OWE, deploy it in OWE transition mode, which advertises both an open and an OWE BSS and lets capable clients use the encrypted one automatically.

BYOD

The question that decides your architecture: do you want personal devices on the corporate network, or on a segregated network with access to specific services?

Segregated is nearly always right. Give BYOD devices their own SSID or VLAN with access to a defined list of services — email, intranet, a VDI broker — and nothing else. Use per-device PSK or a lightweight onboarding flow that issues a device certificate.

If you must put BYOD on the corporate SSID, require enrolment with a device certificate and a posture check, and accept the support burden that comes with it.

Contractors and long-stay visitors

The awkward middle ground. A contractor for six months is not a guest and is not staff. Handle this with:

A sponsored-access workflow where a named employee approves and owns the account, with a mandatory expiry date.
Per-device PSK or a short-lived certificate rather than a shared key.
The same segmentation as BYOD, plus explicit access to the specific systems they need.
An automatic expiry that actually fires. The most common failure here is an account that was meant to last a fortnight and is still live three years later.

Events and conference spaces

If you host events, size for them deliberately. A 300-person all-hands in a space designed for 40 needs a different channel plan, not more power. Practical measures:

Pre-event: reduce channel widths in the space, enable all available channels, verify DHCP pool size.
During: monitor channel utilisation and client count per radio in real time.
Consider a temporary SSID with aggressive rate limits for the event, keeping the corporate SSID's capacity for staff.
Test the AV and streaming path on the same network, at the same time, before the day.