Guest WiFi RFP requirements: what to specify across onboarding, security and analytics

A guest WiFi RFP should set measurable requirements in five areas. Onboarding: captive portal, consent capture and ADA and Section 508 accessibility. Security: IEEE 802.1X, RADIUS, Passpoint and WPA3. Hardware: named support for Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist and Ubiquiti UniFi. Compliance: CCPA/CPRA, PCI DSS v4.0 and protective DNS. Analytics: exportable first-party data. Score bidders on evidence.

What does a guest WiFi RFP actually need to specify?

A guest WiFi RFP turns a loose brief, such as "free WiFi for guests", into requirements a bidder can pass or fail. It defines how people join, how traffic is secured and which hardware the platform must run on. It also fixes how personal data is handled and what reporting you get back.

Weak RFPs tend to fail in the same way. They list features instead of standards, so every bidder answers "yes" and the responses look identical. The fix is to attach a named standard, the evidence you expect and a pilot test to every line.

For a multi-venue estate, the RFP also sets your operating model for the length of the contract. A captive portal is the web page a device sees before it gets internet access. You can run one captive portal and one consent record across every site. The alternative is a different setup for each hardware vendor. Unwinding a fragmented estate later costs far more than specifying a single one now.

This guide gives you requirement wording, a scoring matrix and pilot tests. Treat it as a guest WiFi RFP template you can adapt for Hotels, Retail, Healthcare, Trains, stadiums and public-sector venues.

What do you need before you write the guest WiFi RFP?

Gather five inputs before the first draft. Each one heads off a common source of change requests after award.

• A hardware inventory per venue. Record the access point (AP) vendor, model, management platform and firmware at every site. Note whether each site uses a cloud dashboard or an on-premises controller. Our guide What is a WLC (Wireless LAN Controller) and Do You Still Need One? explains the difference.
• A venue list by type. Group sites by vertical and size, because a stadium concourse and a hotel lobby need different onboarding. Name the people each venue serves: guests, shoppers, passengers, fans, patients or visitors.
• A data map. Decide who acts as data controller, which systems will receive WiFi data and how long you will keep it. Your privacy officer should sign this off before the RFP goes out.
• Your payment boundaries. List every site that takes card payments. Note whether payment devices share switches or circuits with guest traffic. This defines your PCI-DSS scope.
• Success measures. Agree on the numbers you will report, such as logins, opt-in rate, returning visitors, and support tickets. Bidders can then show how their reporting produces each one.

Involve IT, security, data protection, marketing, and venue operations from the start. Guest WiFi touches all five teams. A requirement written by one team often blocks another.

How do you write guest WiFi RFP requirements, section by section?

Write each requirement with "must" or "should", following the convention in RFC 2119. A "must" is a pass-or-fail gate. A "should" is scored. Ask bidders to answer every line with evidence: a document, a certificate, a reference site, or a live demonstration.

Onboarding and captive portal requirements

Onboarding is where guests judge your network, and where your consent records are created. This captive portal RFP checklist covers the essentials.

• Login methods. The platform must support email, social login, SMS, and access codes, configurable per venue.
• Conscious-choice opt-ins. Marketing consent must be a separate, unchecked choice, never bundled with acceptance of terms. The CCPA/CPRA requires consent to be demonstrable and as easy to withdraw as to give.
• Accessibility. The captive portal must meet the ADA and Section 508 standards.
• Reliable portal detection. The platform should support the Captive Portal API (RFC 8908) and the DHCP captive portal option (RFC 8910). Both help modern devices find the login page without redirect loops.
• Returning visitor recognition. iOS 14 and Android 10 onwards use randomized MAC addresses by default. Ask bidders how they recognize a returning guest without relying on the device's hardware address.
• Central control. Corporate headquarters must manage branding, terms, and consent wording centrally, with local overrides for each venue.

Purple Guest WiFi builds conscious-choice opt-ins into the captive portal and manages it centrally across an estate.

Authentication, RADIUS and Passpoint requirements

RADIUS is the protocol an AP uses to ask a central server whether to admit a device. It is defined in RFC 2865. RADIUS accounting, defined in RFC 2866, records session start, stop, and data use. For a multi-venue estate, specify the following.

• Cloud RADIUS with redundancy. Authentication must keep working if one data center fails. Ask for the architecture and 12 months of measured availability.
• Encrypted RADIUS transport. Where RADIUS crosses the public internet, require RadSec (RADIUS over TLS, RFC 6614) or an encrypted tunnel.
• Dynamic authorization. The platform should send CoA messages (RFC 5176) to end or change a session without forcing a reconnect.
• Segmentation. Guest traffic must sit on its own VLAN, a logical network segment isolated from staff and payment systems. Client isolation must stop guest devices reaching each other.
• Encryption on open networks. Require WPA3, including Enhanced Open (Opportunistic Wireless Encryption, RFC 8110). It encrypts each connection without a shared password.
• Individual keys where needed. iPSK (identity pre-shared key) gives each person or device its own WiFi password on a shared network. It suits long-term guests, exhibitors and event crews. Purple delivers this through SecurePass.

Passpoint, also called Hotspot 2.0, builds on IEEE 802.11u. It lets a device find and join a network automatically, with no captive portal. Authentication runs over IEEE 802.1X, the standard for port-based network access control, so credentials stay encrypted. OpenRoaming, run by the Wireless Broadband Alliance, is a federation built on Passpoint. It lets people join participating networks with an identity they already hold.

Specify Passpoint and OpenRoaming as "should" requirements in phase one, with a costed roadmap. Purple supports OpenRoaming, so returning guests can connect automatically at your venues.

If the RFP also covers Staff WiFi, require integration with Microsoft Entra ID, Okta and Google Workspace. That keeps joiners, movers and leavers in step with network access, with no manual password changes.

Hardware-neutral AP compatibility

"Compatible with leading enterprise hardware" cannot be scored. Name every platform you run, or may adopt during the contract. Then require the same five capabilities on each one.

1. External captive portal support.
2. RADIUS authentication and accounting.
3. A walled garden: the pre-login allow list of domains that the portal and social login need.
4. CoA support, or a documented alternative for ending sessions.
5. A published integration guide and at least one live reference on that platform.

Vendor	Management platform to name in the RFP	Minimum evidence to request
Cisco Meraki	Meraki Dashboard	Integration guide, live reference, pilot on your firmware
HPE Aruba	HPE Aruba Networking Central or Mobility Controller	Integration guide, live reference, pilot on your firmware
Ruckus	RUCKUS SmartZone or RUCKUS One	Integration guide, live reference, pilot on your firmware
Juniper Mist	Juniper Mist cloud	Integration guide, live reference, pilot on your firmware
Ubiquiti UniFi	UniFi Network application	Integration guide, live reference, pilot on your firmware
Cambium	cnMaestro	Integration guide, live reference, pilot on your firmware
Extreme	ExtremeCloud IQ	Integration guide, live reference, pilot on your firmware
Fortinet	FortiGate integrated wireless controller	Integration guide, live reference, pilot on your firmware

Ask each bidder to state the firmware ranges they support, then test against your own. Purple is hardware-agnostic and runs as a cloud overlay on all eight platforms. There is no rip and replace. Why your next WiFi upgrade doesn't need new hardware covers the commercial case. For Ruckus estates, see Ruckus SmartZone and RUCKUS One guest WiFi vs external captive portal platforms.

CCPA/CPRA clauses to require

Guest WiFi collects personal data at scale, so the contract must carry these clauses.

• A data processing agreement that meets CCPA/CPRA guidelines, covering purpose, security, sub-processors and deletion.
• Consent records showing timestamp, wording version and channel for every opt-in, exportable on demand.
• Configurable retention with automatic deletion, in line with the storage limitation principle.
• Data subject tools to find, export and erase one person's data. You must answer consumer requests promptly under state privacy legislation.
• Breach notification from the processor without undue delay. You then have short deadlines to notify consumers and regulators under applicable state data breach notification laws.
• International transfers. The bidder must state where data is held and the transfer mechanism for any processing outside the US.
• Security evidence, ideally ISO 27001 certification.

Purple is ISO 27001 certified and GDPR, CCPA and Cyber Essentials compliant.

PCI DSS clauses to require

Guest WiFi should never sit inside your cardholder data environment (CDE). The CDE covers the systems that store, process or transmit card data. PCI DSS v4.0 lets you reduce scope through segmentation, but you must prove it works.

• The bidder must confirm in writing that guest traffic never traverses the CDE, and document the design.
• The design must support your segmentation penetration test, required at least every 12 months under requirement 11.4.5.
• No card data may be entered on the captive portal. Any paid access must use a PCI DSS compliant payment provider, with its Attestation of Compliance supplied.
• Your quarterly testing for unauthorized wireless access points under requirement 11.2.1 still covers guest areas.

Protective DNS clauses to require

Protective DNS stops devices resolving domains known to host malware, phishing or command-and-control servers. Specify the following.

• Threat feeds. The bidder must state its threat intelligence sources and how often they update.
• Category filtering per venue, for example blocking adult content in libraries and family areas.
• A branded block page that tells the visitor why a site was blocked.
• Encrypted DNS policy. State how the service handles DNS over HTTPS (RFC 8484) and DNS over TLS (RFC 7858), which can bypass filtering.
• Log retention aligned with your CCPA/CPRA schedule. DNS logs linked to a logged-in identity are personal data.
• Monthly reporting of blocked threats per venue.

Purple's security add-ons are SecurePass, Verify and Shield. Ask for a demonstration of each against the clauses above.

Analytics and integration requirements

Enterprise guest WiFi procurement often underweights analytics, yet this is where you see a return. Specify the following.

• Metrics per venue and estate: unique visitors, new versus returning visitors, dwell time, visit frequency and peak hours.
• Dashboards and scheduled reports, with role-based access so venue managers see only their own site.
• Integrations with your CRM and marketing platforms, via API or native connectors. Consent status must travel with every record.
• Data ownership. You own the first-party data. Full export in CSV or JSON must be available at any time, and at exit, at no extra charge.

Purple WiFi Analytics reports these metrics per venue and integrates with CRM and marketing platforms.

Service levels and certifications

• Availability. Require a monthly uptime SLA with service credits. Purple's platform runs at 99.999% uptime.
• Support. Specify hours, response times by severity and a named escalation contact.
• Certifications. Require ISO 27001. Federal government contracts that handle personal data require SOC 2 Type II.
• Scale references. Ask for references at your size. Purple runs 80,000+ live venues in over 90 countries and handled 440 million logins in 2024 (Purple's own data).

Requirements scoring matrix

Area	Requirement	Priority	Evidence to request
Onboarding	Separate, unchecked marketing opt-in	Must	Portal screenshots and a sample consent export
Onboarding	ADA and Section 508 captive portal	Must	Independent accessibility audit report
Authentication	Cloud RADIUS with failover	Must	Architecture diagram and 12 months of availability data
Authentication	RadSec or encrypted RADIUS tunnel	Must	Design document
Authentication	Passpoint and OpenRoaming	Should	Live reference site
Encryption	WPA3 and Enhanced Open	Should	Pilot test on your APs
Hardware	Named support for each platform you run	Must	Integration guide and pilot result
CCPA/CPRA	Service provider agreement and retention controls	Must	Signed agreement and retention settings demo
PCI DSS	Guest traffic outside the CDE	Must	Segmentation design and test support statement
Protective DNS	Threat and category filtering with block page	Must for public sector, should elsewhere	Live block test and sample monthly report
Analytics	Full data export at exit	Must	Contract clause and sample export file
Service	Uptime SLA with service credits	Must	SLA schedule

How do you check a bidder can deliver?

Evaluate in two stages: paper, then pilot. Any failed "must" removes a bidder at the paper stage. Weight the remaining "should" lines to match your priorities. A typical split is security and compliance 30%, onboarding 20%, hardware 15%, analytics 15%, service 10% and commercials 10%.

Run a 30-day pilot at two or more venues on different hardware platforms. Test each of these and record pass or fail.

• The captive portal appears first time on iOS, Android, Windows and macOS.
• A returning guest is recognized on a second visit.
• A consent export shows timestamp and wording version.
• An erasure request removes the person from the platform and from your connected CRM.
• Authentication continues during a simulated RADIUS failover.
• A CoA message ends a session without a reconnect.
• A known test domain is blocked, with your branded page.
• A connection attempt from the guest VLAN to the payment network fails.

Test throughput and coverage separately from the platform. WiFi for internet: How it works and what to check covers the basics.

What does this look like in practice?

The three scenarios below are illustrative composites built from common procurement patterns. They are not customer case studies.

A 45-hotel group on two hardware platforms

Situation. The group ran Cisco Meraki at 30 hotels and HPE Aruba at 15 acquired sites. Each estate had its own captive portal. At the 15 acquired sites, marketing consent was bundled with acceptance of terms.

What was done. The RFP named both platforms as "must" requirements. It required one portal, one consent record and separate opt-ins. The pilot covered one hotel on each platform.

Outcome. Two of five bidders failed the hardware gate because they supported only one platform. The winning overlay kept all 15 Aruba sites on their existing APs. Bundled consent was removed at all 15 sites before go-live.

A 120-store retail chain in PCI DSS scope

Situation. Payment terminals shared switches with guest APs in older stores. Guest WiFi was therefore inside the chain's PCI DSS assessment.

What was done. The RFP required a documented segmentation design and written support for the 11.4.5 penetration test. It also banned card entry on the captive portal.

Outcome. The annual segmentation test passed at all 120 stores. Guest WiFi left PCI DSS scope, which narrowed the systems the assessor had to review.

A municipality with 25 libraries and community recreation centers

Situation. The municipality needed safe public WiFi for families, SOC 2 Type II compliance and an accessible login page.

What was done. Protective DNS was a "must", with category filtering for children's areas and an encrypted DNS policy. DNS logs were kept for 90 days, matching the city council's retention schedule.

Outcome. Three of seven bidders failed the ADA and Section 508 gate. In the pilot, one shortlisted bidder's filtering was bypassed through DNS over HTTPS, which removed it from contention.

What goes wrong in guest WiFi procurement, and how do you fix it?

Every bidder answers "yes"

Cause: requirements describe features, not standards. Fix: name the RFC, IEEE standard or CCPA/CPRA article for each line, and demand evidence.

The captive portal fails to appear

Cause: an incomplete walled garden, or weak captive portal detection. Fix: require RFC 8908 and RFC 8910 support, and test four operating systems in the pilot.

Visitor numbers look inflated

Cause: randomized MAC addresses make one device look like several. Fix: require recognition based on login identity, and ask bidders to explain how they count returning visitors.

Consent does not stand up

Cause: opt-ins bundled with terms, or no record of the wording shown. Fix: require separate, unchecked opt-ins and versioned consent records.

You cannot leave

Cause: no data export clause. Fix: require full export in CSV or JSON at exit, at no charge.

The contract forces new hardware

Cause: a vendor tied to one AP brand. Fix: a hardware-neutral clause naming every platform you run.

What does it cost, and what do you get back?

Budget for six cost lines: software licenses, any hardware, installation, internet circuits, support and your own team's time. The architecture you choose drives most of the difference.

Approach	Hardware cost	Multi-vendor estate	Consent and data	Change at each venue
Cloud overlay on existing APs (Purple)	None: runs on existing APs	One portal across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet	Central consent records and first-party data you own	SSID and RADIUS configuration on existing APs
AP vendor's built-in captive portal	None on the current platform	A separate portal for each hardware platform	Consent and visitor data held separately on each platform	Configuration repeated on each platform
Rip-and-replace managed network	New APs and licenses at every venue	One hardware vendor enforced across the estate	Set by the provider's contract terms	New AP installation at every site

Ask bidders to price on one basis: a fixed annual price per venue for the full term. Require onboarding, support, updates and exit costs to be itemized. Purple quotes against three plans, Connect, Capture and Engage, with SecurePass, Verify and Shield as security add-ons.

The return comes from four places. You gain first-party data backed by lawful consent. You see peak hours and dwell time to plan staffing. You avoid hardware spend through the overlay. You get one platform to support instead of several. Purple has delivered this since 2012, across 80,000+ live venues.

Frequently asked questions

Can a guest WiFi platform run on the access points we already own?

Yes. Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Your APs keep handling radio and traffic. Purple provides the captive portal, cloud RADIUS, consent records and analytics. In your RFP, name every platform you run and require a pilot on your own firmware before award.

How should we ask vendors to price guest WiFi in an RFP?

Ask for a fixed annual price per venue for the full contract term, with add-ons itemized separately. Require bidders to include onboarding, support, software updates and data export at exit, and to state any hardware costs. Purple quotes against three plans, Connect, Capture and Engage, with SecurePass, Verify and Shield as security add-ons. This lets you compare bids line by line.

Is our guest WiFi network in scope for PCI DSS?

It should not be, provided it is segmented from your cardholder data environment. PCI DSS v4.0 lets you reduce scope through segmentation, but you must prove it works. Requirement 11.4.5 calls for penetration testing of segmentation controls at least every 12 months. Specify that guest traffic never crosses payment systems, and that no card data is entered on the captive portal.

Who is the data controller for guest WiFi data under CCPA/CPRA?

You are usually the business, and the WiFi vendor is your service provider. The contract therefore needs a data processing agreement covering purpose, security, sub-processors, deletion and breach notification. Your RFP should also require exportable consent records and configurable retention. Add tools to answer access and deletion requests within the deadline set by the CCPA/CPRA.

Do we need Passpoint or OpenRoaming from day one?

No, but you should require a costed roadmap for both. A captive portal remains the right first-visit experience for capturing consent and first-party data. Passpoint and OpenRoaming then let returning guests connect automatically, using encrypted 802.1X authentication with no login page. Purple supports OpenRoaming, so you can add automatic connection later within the same contract.

Should protective DNS be part of the guest WiFi contract?

Yes, especially for public-sector and family venues. Protective DNS blocks devices from reaching domains linked to malware, phishing and command-and-control servers. It can also apply category filtering per venue. Make it a "must" for city halls, libraries and healthcare sites. Require a branded block page, an encrypted DNS policy, monthly reporting and log retention aligned with your CCPA/CPRA schedule.

How much disruption does switching guest WiFi platforms cause?

Switching is a configuration change at each venue, not a hardware project, when the new platform runs as an overlay. Purple layers on top of existing infrastructure, so your APs, cabling and circuits stay in place. Run a 30-day pilot at two venues on different hardware, then roll out in waves. Export consent records from the outgoing platform first, so no lawful opt-ins are lost.

Why not use the captive portal built into our AP vendor's platform?

Because a built-in portal ties onboarding, consent and data to one hardware brand. Multi-venue properties rarely stay on a single platform, after acquisitions and refresh cycles. An independent platform keeps one portal, one consent record and one analytics view across every site, whatever the hardware. That protects your data and your negotiating position at every future hardware refresh.