Sixty Stores of Guest Wi-Fi Inside a PCI Scope
A 60-store specialty retail chain runs cloud-managed APs at each store behind a local firewall, with a 50 Mbps direct internet circuit per store and a hub-and-spoke IPsec tunnel to HQ. Marketing wants guest Wi-Fi at every store with a captive portal and social-login, plus guest analytics. Each store also runs 14 handheld POS terminals over Wi-Fi, and card payments must meet PCI DSS. Today the guest SSID breaks out locally and is bridged to the store VLAN in three pilot stores. The auditor has flagged that cardholder data must never share an L2 domain with guest traffic, and that guest session logs must be retained for 12 months but store firewalls have 7 days of storage.
1. Choose between local internet breakout and tunnelling all guest traffic to HQ. Justify the decision against latency, cost, and PCI scope.
Read the worked answer
Break out guest traffic locally at each store, but make it a designed breakout rather than the current bridged default.
Reasoning:
- Latency and capacity. 60 stores' guest traffic concentrated through HQ turns every guest video stream into a WAN problem and adds a hairpin round trip. Guest users are the least predictable load on the network and should not be able to degrade POS responsiveness.
- PCI scope. Tunnelling guest traffic into HQ pulls guest traffic into the same environment as central systems, which widens scope rather than shrinking it. Local breakout with a fully isolated guest segment keeps guest data out of the cardholder data environment entirely.
- Cost. HQ aggregation requires a larger head-end and more bandwidth at the data centre; local breakout uses the 50 Mbps circuit already paid for, rate-limited per client.
What must accompany the breakout: a dedicated guest VLAN with no route to store LANs, L2 client isolation, firewall rules that permit only DHCP/DNS and internet egress, per-client and per-SSID bandwidth caps (for example 5 Mbps down / 1 Mbps up), and centralised log export to a cloud collector so the 12-month retention requirement is met without relying on the store firewall's 7-day buffer.
The 7-day storage limitation should be read as a directive to export logs, not as an argument for tunnelling.
2. Design the segmentation and authentication for the 14 POS handhelds per store so that the design satisfies the auditor and survives a device theft.
Read the worked answer
Treat the POS devices as a cardholder data environment segment with its own SSID, its own VLAN, and its own path to the payment processor.
- Authentication. Per-device credentials, not a store-wide PSK. Preferred is a unique PSK per terminal (MPSK) mapped to the POS role and VLAN, or 802.1X with EAP-TLS certificates provisioned at the MDM/EMM level. If the platform supports neither, the PSK is a documented exception with compensating controls.
- Theft scenario. With MPSK or certificates, one stolen terminal is revoked individually without touching the other 13 devices in the store or the other 59 stores. With a shared PSK, the key must be rotated everywhere - which in practice means it is not rotated.
- Segmentation. POS VLAN permits only the payment application endpoints and the processor; no access to guest, corporate, or store-management VLANs; no inbound from guest. Firewall rules are explicit allow-lists, not implied by VLAN membership.
- Traffic path. POS traffic should not ride the guest breakout. Whether it tunnels to a central payment gateway or egresses locally through a dedicated rule is a design choice, but it must be a distinct policy with its own logging.
- Monitoring. Alert on any POS MAC appearing on the wrong SSID, on unexpected ports, or on a terminal authenticating from an unknown store.
Also update the pilot stores: the current bridge of guest to the store VLAN is a direct PCI finding and should be remediated before any further rollout.
3. Marketing asks that the guest network be 'monitored like the corporate one' and wants a policy summary. What belongs in the guest policy and what monitoring is genuinely useful?
Read the worked answer
A guest policy that says only 'acceptable use' will not survive contact with an incident. It should state, at minimum:
- Permitted use and prohibitions, with an explicit statement that the network is unencrypted (open with captive portal) and that users must not assume privacy. This is the sentence that protects you in a dispute.
- Session limits: maximum session duration, idle timeout, per-client bandwidth, and concurrent device limits, with the enforcement mechanism named.
- Data handling and retention: what is logged (association, DHCP, portal authentication, and NAT translation records), for how long (12 months here), where it is stored, who may access it, and the legal-hold process.
- Social-login specifics: what identifiers are collected from the identity provider, that they are used for analytics, and how consent is obtained.
- Incident response: who is called when abuse is reported, and the fact that a specific client can be identified from NAT/maintained logs.
Monitoring that is actually useful: rogue/evil-twin detection per store (guests are the population most likely to fall for one), alerts for guest-to-POS or guest-to-LAN traffic attempts, portal failure alarms, and DHCP pool exhaustion. Alerting on every guest device is noise; alerting on segmentation violations is signal. Keep the policy and the technical controls cross-referenced so an auditor can trace each clause to an enforcement point.