Skip to content
Support
Concepts

Branded captive portal for guest Wi-Fi

The Captive Portal is the branded web page a guest lands on when they join the network. The guest signs in there with one of the enabled login modules; on success the access policy applies the session terms and the guest is sent to a redirect URL. It is the public face of Sign In — used for guest Wi-Fi in offices, hotels, venues, retail, and education — and it is fully customizable to the customer’s brand.

At a glance

What it is
The branded sign-in page presented to guests on the network
Configured in
Administration Portal → Look & Feel
Branding
Background, logo, fonts, colours, buttons, and panel appearance
Brand-aware setup
Auto-propose a look-and-feel from the organization's homepage (AI)
Languages
13, auto-detected from the device with a configurable fallback

Branding and look & feel

Section titled “Branding and look & feel”

The portal is designed to match the customer’s brand. Everything below is configured in the Administration Portal under Look & Feel:

  • Background image — a full-page background (JPG or PNG; around 1920×1080 and under 1 MB).
  • Organization logo — a logo (JPG or PNG, transparent background recommended), which can be shown or hidden.
  • Fonts — separate header and body fonts, with custom fonts uploadable (WOFF) so the portal matches the corporate typeface, plus size adjustment.
  • Colours — set by HEX value or colour picker for the body text, input-field text, tab text, links and emphasised elements, the Terms and Privacy links, and the login panel’s background, with an adjustable background opacity and a panel shadow (offset and blur).
  • Buttons and forms — button shape (rounded or square), button colour and button-text colour, and the shape of input fields.
  • Portal appearance — the layout and shape of the login panel and related appearance settings.
  • File management — upload and manage the images, fonts, and text files the portal uses.

Brand-aware setup

Section titled “Brand-aware setup”

Sign In can build a starting look-and-feel automatically from the organization’s own website. In Look & Feel → Auto-fill from your brand site, an administrator pastes the organization’s homepage URL and the platform analyzes the page to propose colours, panel shape, logo, background, and fonts pulled straight from the site.

Nothing is applied on its own: the proposal is presented for review, and the administrator approves each piece before it is saved. It gets a portal most of the way to the customer’s identity in a single step, instead of setting every value by hand.

Login methods on the portal

Section titled “Login methods on the portal”

Several login modules can run at the same time and are presented as tabs on the portal, each with its own informational text. A default login method is set as the primary tab. When only one method is enabled, the portal switches to a centered, mobile-first layout for smaller screens. (Event Access, which redirects to a splash page, is exclusive and disables the other methods.)

Languages

Section titled “Languages”

The portal ships in 13 languages — English, Swedish, Norwegian, Danish, Finnish, German, French, Lithuanian, Estonian, Latvian, Spanish, Italian, and Dutch. It detects the language from the guest’s device or browser and applies it to both the portal and any follow-up email; if the guest’s language is not enabled, it falls back to a configured language (English is recommended). Administrators enable or disable individual languages and set the fallback, and custom text is maintained per active language.

Compliance

Section titled “Compliance”

The portal carries collapsible Terms and Conditions and Privacy Policy sections, configured in the Administration Portal, so the customer’s compliance text is presented before access is granted.

Responsive

Section titled “Responsive”

The portal is fully responsive and adjusts its layout for mobile, tablet, and desktop.

Captive-portal detection (DHCP Option 114)

Section titled “Captive-portal detection (DHCP Option 114)”

Modern devices can detect a captive portal automatically. Sign In supports DHCP Option 114, Captive-Portal Identification (RFC 8910): the DHCP response carries the portal’s URL, so the client is pointed straight at the login page instead of relying on DNS hijacking or HTTP interception. This applies when the service is delivered over a Service Gateway, where Option 114 is set in the gateway’s DHCP configuration. Because the URL is delivered explicitly it can be HTTPS, which avoids the certificate warnings that traffic redirection can otherwise cause.

It helps to separate three things a client may or may not do:

  1. Request DHCP Option 114 (RFC 8910) to learn the portal URL.
  2. Call the Captive Portal API (RFC 8908) to read session and venue information.
  3. Actually open the portal automatically based on that information.

Support for these differs by operating system, so Option 114 is best treated as an enhancement on top of the classic detection mechanisms, not a replacement for them.

Operating-system support

Section titled “Operating-system support”

Full or reliable support:

Operating systemOption 114 / RFC 8910
Apple iOS 14+Yes
Apple iPadOS 14+Yes
Apple macOS Big Sur (11) and laterYes
Android 11+Yes
ChromeOS (recent versions)Yes, via Android’s implementation

Apple introduced the support in iOS 14 and macOS Big Sur: when Option 114 is announced, the client fetches the RFC 8908 API and presents the captive-portal window in a standardized way. Android introduced it in Android 11 and reads the API information directly after the DHCP exchange.

Partial or inconsistent support:

Operating systemStatus
Windows 10 / 11Limited and inconsistent
Linux desktopDepends on the distribution

Windows continues to rely mainly on its own connectivity tests (NCSI, msftconnecttest.com). Microsoft has never documented full RFC 8910 support the way Apple and Google have, so on Windows the captive portal is still reached through classic detection in practice.

Linux depends heavily on the distribution, because RFC 8910 only landed in systemd-networkd v254 (2023):

DistributionStatus
Ubuntu 24.x and modern systemd-based distrosBetter support
Older Ubuntu / DebianOften none
Fedora / RHELDepends on the systemd version
Embedded LinuxHighly variable

What this means for Sign In

Section titled “What this means for Sign In”

With Option 114 in use you can count on automatic detection on iPhone and iPad (iOS 14+), MacBook (macOS Big Sur and later), and Android 11+. Windows 10/11 and most Linux clients still fall back to classic captive-portal detection.

For that reason Sign In keeps the traditional captive-portal detection as a fallback (Apple CNA, Android generate_204, Windows NCSI, and a plain HTTP redirect on the device’s first web request), so the portal is presented even on clients that do not act on Option 114. This is what RFC 8910 itself recommends, and how Apple and Google designed their implementations: Option 114 is a complement that improves the experience on iOS, macOS, and Android, rather than a replacement for the classic mechanisms.

Where the client supports it, the portal also surfaces session and venue information through the Captive Portal API (RFC 8908), for example how much of the session remains and a link to a local venue page.

Section titled “Related pages”

Next

Login Modules

The sign-in methods Sign In offers — Click-to-Connect, self-provisioning, Meeting Host, Conference ID, SAML SSO, and more — what each one does, how it works, and which licence (Go or Enterprise) it belongs to.

Admin Portal

The central web interface for Sign In: role-based access to monitoring, the login modules, captive-portal look and policy, network integrations, and organization administration.