White label captive portal software: what MSPs and resellers should check before signing

White label captive portal software lets an MSP or reseller sell guest WiFi login pages under its own brand. Before signing, confirm six things: true multi-tenancy with delegated admin, branding across domain, email and reports, support for every access point vendor you install, a billing model that protects margin, GDPR consent records your client owns, and documented APIs.

Which white label captive portal model should you choose?

A captive portal is the web page a device sees before the network grants internet access. The IETF sets out the architecture in RFC 8952. RFC 8908 defines an API that tells devices a portal is present.

White label captive portal software lets you sell that login page under your own brand. The console and reports behind it carry your brand too.

Three commercial models dominate the reseller market. They differ on three points:

• who holds the client contract
• how far your brand reaches
• how cleanly each client's data is separated

Choose the model first, then score vendors inside it.

Model	Your brand appears on	Client data isolation	Who holds the client contract	Typical billing	Suits
Full white label, multi-tenant	Login page, custom domain, admin console, emails, SMS and reports	Separate tenant per client, with scoped admin roles and API keys	You	Wholesale per site or per access point, you set retail	MSPs with a service desk and a portfolio of venue clients
Co-branded reseller	Login page and emails only; console and reports show the vendor	Sub-accounts or folders inside one shared account	You or the vendor	Vendor list price minus a reseller discount	Resellers adding guest WiFi to a hardware sale
Referral or direct contract	Vendor brand throughout; you appear as installer	Client's own vendor account	The vendor	Vendor list price; you earn a referral fee or services income	Partners running one-off projects with no support desk

Most MSPs with a support desk and several venue clients land on the first model. The rest of this guide assumes that model and shows you how to test a vendor's claim to it.

Where white label captive portal platforms genuinely differ

Every vendor demo shows a branded login page. The real differences sit underneath, in six areas. Together they decide your margin, your compliance exposure and your support load.

True multi-tenancy and delegated admin

True multi-tenancy means one client per tenant. Data, settings, admin accounts and API keys are isolated at platform level. A folder inside a shared account is not a tenant. If a misconfigured role exposes one client's guest list to another, you carry the breach.

Test delegated admin in a trial tenant, not on a slide. You need at least four roles:

• your own super admin
• a client admin
• a venue manager restricted to one site
• a read-only marketing role

A hotel general manager should see their own hotel and nothing else.

Ask for single sign-on through SAML 2.0, the OASIS standard for federated login. It should work with Microsoft Entra ID, Okta and Google Workspace.

SCIM 2.0 (System for Cross-domain Identity Management, RFC 7643 and RFC 7644) automates creating and removing admin accounts. Without it, a leaver at your client keeps console access until someone remembers. Check that audit logs are kept per tenant and can be exported, so you can show a client who changed what.

Branding depth: domain, sender email, portal and reports

Branding depth is where most "white label" claims fall short. Score each surface a guest or client might see:

• Login page domain. The captive portal should load from your domain or your client's. The vendor should renew its TLS certificate automatically.
• Admin console. Your logo, colours and URL belong on the sign-in screen. A vendor-branded console tells your client exactly whom to call at renewal.
• Sender email. Verification codes and marketing emails must send from your domain. That needs SPF (RFC 7208), DKIM (RFC 6376) and DMARC (RFC 7489) aligned to your domain, or messages land in spam.
• SMS sender ID. Verification texts should show your name or the venue's, never the vendor's.
• Reports. Scheduled exports and dashboards should carry your branding, with no vendor watermark. If you resell WiFi Analytics, the monthly report is the product your client actually sees.
• Help links and status pages. Console links should point to your knowledge base, or nowhere.

Per-tenant templates matter too. A pub group and a council want different login flows, consent wording and languages.

Hardware coverage across your installed base

Your clients already own access points, and they rarely come from one vendor. Ask for the supported list by name and by management platform: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. "All major vendors" is a red flag, not an answer.

Support means more than a redirect. For each vendor, confirm four capabilities:

• external captive portal redirect
• RADIUS (Remote Authentication Dial-In User Service, RFC 2865) authentication
• RADIUS accounting (RFC 2866) for session data
• walled garden configuration for social and payment logins

Ask for a published integration guide for each vendor. Then test on the firmware your clients actually run.

Hardware coverage also protects you through refresh cycles. A cloud overlay sits on top of the network, so a client can change access point vendor without changing the guest experience. That matters for any estate working through Planning a WiFi 6 to WiFi 7 access point refresh when Cisco Meraki WiFi 6 reaches end of sale.

Purple's Guest WiFi runs as a hardware-agnostic cloud overlay on all eight vendors above. The background is in Why your next WiFi upgrade doesn't need new hardware.

Some clients will want more than guest access. Ask whether the platform handles 802.1X, the IEEE standard for port-based network access control. Ask about iPSK (identity pre-shared key) too, which gives each device or person its own WiFi key. If you add staff access, keep Troubleshooting Windows 11 802.1X authentication issues: enterprise IT guide to hand.

Passpoint, also called Hotspot 2.0, lets returning guests reconnect automatically without a portal. OpenRoaming, the Wireless Broadband Alliance federation, does the same across participating networks. A platform without them caps what you can sell later.

GDPR consent records your client owns

Under GDPR, your client, the venue operator, is normally the controller of guest data (Article 4(7)). You act as processor, and the platform vendor as your sub-processor. Article 28 requires a written contract at each link in that chain. Article 28(2) bars a processor from engaging a sub-processor without the controller's prior written authorisation.

Article 7(1) requires the controller to demonstrate consent. That means a full record per guest:

• timestamp
• the exact wording shown
• the privacy notice version
• the channel
• the purposes accepted

A "marketing opted-in" flag is not enough. Recital 32 adds that pre-ticked boxes do not count as consent. For UK email and SMS marketing, consent must also satisfy the Privacy and Electronic Communications Regulations (PECR).

Check three contract points before you sign:

1. The vendor makes no claim to use guest data for its own purposes. If it does, it becomes a controller, and your client's privacy notice must say so.
2. Article 28(3)(g) requires return or deletion of personal data when the contract ends. Get the export format, timeframe and cost in writing.
3. The vendor publishes a sub-processor list and notifies you of changes, so you can pass notice to clients.

Purple builds conscious-choice opt-ins into the login flow, so each guest actively chooses marketing. Purple is ISO 27001 certified and GDPR compliant.

API and webhook access

APIs decide how much of your own service you can build. Ask for a documented REST API with keys scoped to a single tenant. Then one compromised key cannot reach every client. Bulk endpoints for tenants, venues and portal templates let you script onboarding instead of clicking through it.

Webhooks push events, such as a guest login or a new opt-in, to your client's CRM as they happen. Check three things:

• payloads are signed, so the receiver can verify the sender
• failed deliveries retry automatically
• rate limits and any extra charge for API access are confirmed in writing

Support escalation

On a white label platform, you are first-line support. The venue calls you, and the vendor must never contact your client directly. That makes the vendor's second-line route your most important service term.

Write these into the contract:

• defined severity levels
• response targets for each level
• a named partner contact
• a direct route to engineering for a site-down incident

Article 33(2) requires a processor to notify the controller of a breach without undue delay. Your vendor contract must give you notice fast enough to meet that duty to your client.

Ask for evidence of scale as well. Purple handled 440 million logins in 2024 across 80,000+ live venues in over 90 countries (Purple's own data).

When a fully multi-tenant white label platform is the right call

Choose full white label when you own the client relationship end to end. That usually means three things are true:

• you run a service desk
• you bill clients monthly
• you hold several venue clients across sectors

Guest WiFi then becomes a recurring line on your own invoice.

It also suits mixed hardware estates. One hardware-agnostic platform replaces several vendor-specific consoles. Your engineers learn one system, and every client's report looks the same.

Worked scenario: a regional hotel group with two hardware vendors

Situation. An MSP managed guest WiFi for a 14-hotel regional group. Nine hotels ran Cisco Meraki. Five hotels, acquired the previous year, ran Ruckus with 210 access points between them. The MSP's shortlisted captive portal supported Meraki only.

What was done. The MSP moved its shortlist to hardware-agnostic platforms and ran a two-hotel pilot covering both vendors. It created one tenant for the group, with each hotel as a venue. General managers received venue-only roles. The group marketing lead received read-only reporting across all 14 hotels.

Outcome (illustrative figures). All 210 Ruckus access points stayed in service instead of being replaced. The group ran one login design, one consent wording and one monthly report across every property.

For more on the sector, see Hotels and WiFi in restaurants: a UK guide to coverage and security.

When a co-branded or direct contract is the right call

Full white label is not always worth the overhead. You might sell guest WiFi as a one-off add-on to a hardware project. In that case a co-branded account or a referral is simpler, and you avoid first-line support for a product you do not want to run.

A direct contract suits large single clients with in-house IT, such as a national Retail chain. Their procurement team may prefer to contract the vendor directly. Clients in regulated sectors, such as Healthcare, often run their own supplier assurance too.

You still earn on installation, network management and site surveys. WiFi Site Surveys: A Practical Planning Guide covers that groundwork.

How white label captive portal software is priced

Three billing units dominate: per site, per access point and per guest. Most vendors sell wholesale, and you set the retail price. Your margin depends less on the discount than on matching your billing unit to the vendor's.

Billing model	You pay for	Cost predictability	Main risk to you	Best fit
Per site	Each venue, regardless of size	High: changes only when a venue joins or leaves	Small sites cost the same as large ones	Chains of similar venues: pubs, quick-service restaurants, high street retail
Per access point	Each managed access point	High: changes only with hardware projects	Densification or a WiFi 7 refresh adds licences	Stadiums, conference centres and other venues with attendance peaks
Per guest	Each authenticated guest per month	Low: moves with attendance	Event peaks create bill shock unless capped	Pilots, seasonal venues and low-traffic sites

The safest structure bills your client in the same unit the vendor bills you. If you pay per access point but charge per site, every densification project eats your margin.

Before you sign, check four further costs:

• minimum terms
• annual uplift clauses
• charges for API access or extra tenants
• SMS verification, which often sits outside the licence

Worked scenario: a conference centre with event-driven peaks

Situation. A reseller quoted guest WiFi for a conference centre with 120 access points. Monthly attendance ranged from about 3,000 visitors in quiet months to 45,000 during a major trade show.

What was done. The first vendor priced per guest. The reseller modelled 12 months of attendance and found the invoice swung by a factor of 15. It moved to a vendor billing per access point and charged the venue a flat monthly fee.

Outcome (illustrative figures). The licence line held at 120 access points every month, so monthly cost variance fell to zero. The venue budgeted a fixed annual figure. The reseller's margin stopped depending on the events calendar.

How to decide for your estate: RFP questions and red flags

Send every shortlisted vendor the same questions and ask for written answers. Then verify the important ones in a trial tenant.

RFP questions to send

1. Is each client a separate tenant with isolated data, settings, admin accounts and API keys?
2. Which admin roles exist, and can a role be restricted to one venue?
3. Do you support SAML 2.0 single sign-on with Microsoft Entra ID, Okta and Google Workspace, plus SCIM provisioning?
4. Can the captive portal, console, sender email, SMS sender ID and reports all carry our brand?
5. Who issues and renews TLS certificates for custom domains?
6. Which access point vendors do you support, and do you publish an integration guide for each?
7. Do you support RADIUS authentication and accounting, 802.1X, iPSK, Passpoint and OpenRoaming?
8. What are the billing unit, minimum term and annual uplift?
9. What do you charge for SMS, API access or extra tenants?
10. Do you use guest data for any purpose of your own?
11. What does a consent record contain, and in which formats can our client export it?
12. How and when do you return or delete data at contract end?
13. Where is your sub-processor list, and how do you notify changes?
14. What are your severity levels and response targets, and how fast will you notify us of a breach?
15. What is the scope of your ISO 27001 certificate?

Red flags that should stop a signature

Area	What good looks like	Red flag
Multi-tenancy	Separate tenant per client with isolated data and API keys	Clients sit in folders inside one shared account
Branding	Your domain on portal, console, emails, SMS and reports	Vendor name in emails, console URL or report footers
Hardware	Named vendors, each with a published integration guide	"All major vendors" with no named list
Billing	Billing unit matches how you charge clients, with capped uplift	Uncapped per-guest pricing, or API access on the top tier only
Guest data	Client is controller; vendor processes on instruction only	Vendor reserves the right to use guest data itself
Exit	Consent records exported in CSV or JSON within an agreed period	Export only on request, for a fee, or in a proprietary format
Support	Severity levels, response targets and a named escalation contact	Ticket form only, with no defined response times

Worked scenario: a council changing reseller

Situation. A reseller ran guest WiFi for a county council across 22 libraries and leisure centres. At retender, the council chose a different supplier. Its events team held consent from about 38,000 visitors to receive updates.

What was done. The reseller's vendor contract included an Article 28(3)(g) exit clause. The clause required a JSON export of every consent record within 30 days, with timestamp, wording version and channel.

Outcome (illustrative figures). The council imported all 38,000 consent records into its new platform. It kept emailing visitors without a re-permission campaign. The reseller exited with written confirmation that its copy of the data was deleted.

Frequently asked questions

What is a white label captive portal?

A white label captive portal is guest WiFi login software that an MSP or reseller sells under its own brand. The vendor runs the platform, while your logo, domain, sender email and reports face the client. The strongest platforms add true multi-tenancy. Each client then sits in its own isolated tenant, with delegated admin roles for venue managers and marketing teams.

Can an MSP brand a captive portal as its own?

Yes, provided the platform offers full branding depth. The login page should load from your domain with a valid TLS certificate. Emails should send from your domain with SPF, DKIM and DMARC aligned. The admin console and reports should carry no vendor reference. If branding stops at the login page, your client still sees the vendor's name every month.

How is white label captive portal software priced?

Most vendors price per site, per access point or per guest, sold wholesale so you set the retail price. Per site suits chains of similar venues. Per access point suits venues with large attendance peaks. Per guest suits pilots and low-traffic sites but swings with demand. To protect margin, bill your client in the same unit the vendor bills you.

Which access points must a white label portal support?

It must support every vendor in your clients' estates, named individually: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. For each one, confirm external captive portal redirect, RADIUS authentication and accounting, and walled garden support, backed by a published integration guide. Purple's Guest WiFi runs on all eight as a hardware-agnostic cloud overlay.

Who owns guest data on a reseller platform?

Your client, the venue operator, should own guest data as controller under GDPR. You act as processor and the platform vendor as sub-processor, each bound by an Article 28 contract. Reject vendor terms that allow the vendor to use guest data for its own purposes. Consent records should export on demand and return to your client when the contract ends.

Do clients need new hardware to move to a new captive portal platform?

No, not if the platform is hardware-agnostic. A cloud overlay connects to the access points your client already runs, using external captive portal redirect and RADIUS. You reconfigure the network to point at the new platform rather than replacing equipment. Test on the firmware versions your clients actually run before you schedule the cutover.

Can you migrate existing clients from another captive portal platform?

Yes, if your current vendor exports each client's consent records and guest data in a usable format. Request a CSV or JSON export with timestamp, consent wording and channel, citing GDPR Article 28(3)(g). Rebuild portal templates in the new tenant and run both platforms in a pilot venue. Then switch the remaining sites in batches to limit risk.