Migrate Spaces Connector 2.x to Connector 3 Click here >>
Migrate Spaces Connector 2.x to Connector 3 Click here >>
The Captive Portals app enables you to deliver secure, seamless, and branded Wi-Fi onboarding experiences.
Create customizable login experiences and offer flexible authentication methods that drive loyalty & generate incremental revenue.
Seamless Wifi Onboarding
Offer a smooth and secure guest Wi-Fi experience. Custom design your splash page to reflect your orgs’ branding priorities.
Value Delivered – Simplify wifi onboarding. Deliver professional, branded look to your wifi users.
Useful To: IT Teams, Visitor Experience Teams, Visitors/Employees
Differentiate Guest Experiences
Leverage location, time, & more using if-this-then-that logic to provide a personalized onboarding experience.
Value Delivered – Create moments that matter for visitors. Set parameters on wifi usage. Develop a time & location based marketing strategy for your org.
Useful To: IT Teams, Visitors Experience Teams, Marketing Teams
Customer Acquisition & Loyalty.
Capture customer emails and export to enterprise CRM. Drive loyalty program enrollment, increase app adoption, promote personalized offers.
Value Delivered – Increase Customer Lifetime Value. Reduce Churn.
Useful To: Marketing Teams, Loyalty Teams
Monetize Guest Wifi
Monetize access to wifi by using integration with payment providers. Turn your guest Wi-Fi login into prime digital real estate promoting partner brands.
Value Delivered – Turn network investments into revenue.
Useful To: IT Teams, Marketing Teams
Please complete the following pre-requisite for access to Captive Portals
Cisco Spaces Captive Portal is a Wi-Fi onboarding application that presents a branded web experience when guests connect to a configured SSID. It can be used for consent-based access, access-code workflows, data capture, terms and conditions, location-based rules, and guest engagement across supported Cisco and Meraki wireless environments.
Cisco ISE Guest is designed for policy-centric network access control, guest identity lifecycle management, and enterprise authentication workflows. Cisco Spaces Captive Portal is designed for cloud-managed guest onboarding, branded portal experiences, data capture, visitor engagement, and location-aware rules. The two products can complement each other, but they are not one-for-one replacements for every guest access workflow.
Use Cisco Spaces Captive Portal when the primary goal is a cloud-managed guest experience, fast portal creation, branded onboarding, visitor data capture, location-based rules, or integration with Cisco Spaces outcomes. Keep or use ISE when the requirement depends on ISE-specific identity stores, device registration, endpoint profiling, or complex policy enforcement.
Cisco Spaces Captive Portal is available in Cisco Spaces packages that include the Wi-Fi onboarding outcome, including ACT, Advantage, Unlimited, and Premier tiers.
A Meraki Enterprise Agreement with Advantage entitlement provides access to the Cisco Spaces Advantage tier, including Cisco Spaces Captive Portal. If the Cisco Spaces dashboard shows a lower entitlement than expected, verify the Meraki organization, smart account, subscription, and account association with Cisco licensing or support.
Advanced capabilities such as data capture, integrations, extended onboarding flows, OpenRoaming, or analytics may require a higher Cisco Spaces package. Use the package matrix and the Captive Portal App Guide to confirm which functions are included in the customer entitlement.
A deployment requires an active Cisco Spaces account, a supported Cisco wireless network, an onboarded location hierarchy, SSIDs imported or configured in Cisco Spaces, and correctly placed access points on maps where location-based rules are used. Controller-based Catalyst deployments use a Cisco Spaces Connector. Meraki deployments use the Meraki integration.
Yes. Cisco Spaces Captive Portal supports cloud-based Meraki wireless environments and controller-based Cisco wireless environments, including Catalyst 9800 designs where the required connector, SSID, web authentication, RADIUS, certificate, and redirection settings are configured. Catalyst 9800 wireless profiles in Flex mode are supported when the redirection, ACL, and authentication design is validated for the customer topology.
New guest onboarding can be affected if clients cannot reach the hosted portal, RADIUS service, or required cloud resources. The user impact depends on the wireless platform, disconnection behavior, walled garden, existing session state, and fail-open or fail-closed design. Customers should define the desired outage behavior during design and test it before production rollout.
For Meraki networks, create or edit the guest SSID in the Meraki dashboard, import or configure the SSID in Cisco Spaces, then apply the required splash page, RADIUS, and walled-garden values from Cisco Spaces into the Meraki SSID configuration. The SSID and Cisco Spaces portal rule must align with the intended organization, network, location, and access policy.
Cisco Spaces is the primary location for Captive Portal data capture, visitor records, access-code workflows, and related reporting. The Meraki dashboard remains the source for Meraki network and client operations. Guest identity visibility in Meraki depends on the SSID configuration, authentication method, accounting, and what client details Meraki receives.
Yes. Bypass can be handled through trusted devices, allow lists, MAC-based controls, or network policy design where supported. Use bypass carefully because it can affect reporting, data capture, and consent workflows. For large device lists, validate the supported import or management process in the Captive Portal App Guide.
A Catalyst 9800 deployment requires the Cisco Spaces Connector, a matching SSID, web authentication redirection to the Cisco Spaces splash URL, appropriate pre-authentication access control, and trusted certificate configuration for the controller virtual interface or hostname. The global parameter map type remains WebAuth. When a virtual IPv4 address is required for the controller design, use the value specified in the Cisco Spaces and Catalyst 9800 configuration guidance.
Without RADIUS, a simple consent or click-through flow can redirect users to the portal and allow network access after the portal interaction.
With Cisco Spaces RADIUS, additional policy-based capabilities are available, such as seamless provisioning for returning users, deny-internet behavior, bandwidth limits, and VLAN overrides where supported by the underlying network platform.
Note: Cisco Catalyst 9800 controllers currently do not support bandwidth limits or VLAN overrides with Cisco Spaces Captive Portal. These capabilities are available only on supported platforms.
Controller-based web authentication designs should use a trusted certificate tied to the virtual interface or virtual hostname so clients do not receive certificate warnings during redirection. Certificate requirements should be validated against the Catalyst 9800 configuration guide and the customer’s wireless design.
In an anchor-foreign controller design, the SSID must exist on both controllers. Guest web authentication, web policies, access control lists, and Layer 3 authentication settings are applied on the anchor controller because the anchor manages client traffic for the guest flow.
Yes. Catalyst Center templates can be used to apply the required captive portal configuration to multiple Catalyst 9800 controllers after the commands, variables, certificates, SSIDs, policy tags, and site-specific values have been validated.
Yes. Cisco Spaces Captive Portal supports Catalyst 9800 wireless profiles operating in Flex mode. Validate client redirection, web authentication, access control lists, and RADIUS behavior for the specific Flex design before production rollout.
Cisco Spaces Captive Portal can support consent-style access, access-code workflows, data-capture forms, social or configured identity options, and RADIUS-backed portal behavior where supported. Available options depend on license, network platform, SSID configuration, and the selected portal modules.
Yes. A Cisco Spaces captive portal can be designed to collect both email address and mobile phone number and allow guests to receive an access code through the supported contact method. Use the multiple-authentication guidance to configure the required modules and test the full onboarding flow before publishing the portal.
Yes. Access-code validity can be configured with a start date and end date. Session duration is configured in the portal rule and does not require RADIUS by itself. Review the configured default and validate the expected repeat-visitor behavior across common device types.
Cisco Spaces Captive Portal does not provide a manual approve-or-deny workflow for individual guests before they connect. Controlled access can be implemented through access-code workflows, trusted devices, portal rules, and network policy design. If manual visitor approval is required, use a guest-management or identity platform that supports that workflow.
Cisco Spaces Captive Portal does not create network user accounts in Cisco Spaces, Meraki, or the wireless controller for the basic portal flow. The portal collects guest information or applies authentication methods such as one-time passcodes, social sign-in, trusted devices, or other configured onboarding options. The wireless platform enforces the network access behavior configured for the SSID.
Cisco Spaces provides portal templates, editable modules, branding options, data-capture fields, user agreement options, privacy-policy modules, age-gating options, location variables, landing-page configuration, and portal rules. Customers should review the live preview and test the flow on target devices before publishing.
Yes. Cisco Spaces can use portal rules so guests in different zones or locations receive different portal experiences, messages, promotions, or landing pages. Engagements can be delivered through supported channels such as email, SMS, or API pushes when the required contact data, consent, and integration settings are configured.
Cisco Spaces does not provide a direct one-click import of Cisco ISE Portal Builder projects. Portal content, branding, forms, and authentication logic should be recreated or mapped into Cisco Spaces using the supported portal editor, templates, modules, and CSS upload capabilities.
Cisco Spaces portal modules can present branded content, messages, terms, and engagement-oriented experiences. For advertising or monetization programs, validate the available portal modules, privacy requirements, consent requirements, and any integration needs with the Cisco account team or approved partner ecosystem.
Captive portals are designed for Wi-Fi onboarding and guest engagement during the network access flow. Digital signage is a separate experience and may require different Cisco Spaces applications, partner applications, or third-party signage platforms depending on the use case.
Use the Cisco Spaces Captive Portal App Guide and runbook for standard configuration guidance. Eligible paid Advantage customers can request design consultation by opening a case from the Cisco Spaces user interface and using Captive Portal as the case keyword. For complex production assistance, work with the Cisco account team, Cisco Spaces support, or an approved implementation partner.
Yes. Cisco Spaces Captive Portal can collect visitor information through configured data-capture forms and can report on portal activity and visitor engagement. Customers are responsible for configuring consent, privacy notices, retention practices, and data handling in line with organizational and regulatory requirements.
Cisco Spaces provides aggregated onboarding and customer-acquisition reporting in the dashboard. Personally identifiable information collected through the portal, such as email address or phone number, is not displayed directly in the dashboard. Use Cisco Spaces Data Out capabilities, such as Data Export, Firehose API, or Trigger APIs, when the deployment requires access to collected PII.
Cisco Spaces can support outbound integrations and API-triggered workflows for portal events where configured. Smart variables and captured fields can be used in supported workflows, provided the data is collected in the portal and the integration design follows privacy and security requirements.
Portal reappearance depends on the portal rule, authentication method, session duration, access-code validity, remembered client behavior, and wireless platform settings. Customers should configure the desired repeat-visitor behavior and test it with common client devices before production rollout.
OpenRoaming and Captive Portal are both Wi-Fi onboarding capabilities managed through Cisco Spaces, but they serve different user experiences. Captive Portal presents a web-based onboarding flow. OpenRoaming uses identity federation and Passpoint-based onboarding to connect users more seamlessly when their devices and identity providers are supported.
No. OpenRoaming is designed for seamless onboarding, and adding a captive portal into the same authentication flow is not recommended or supported. Use separate onboarding designs, SSIDs, or user journeys when both OpenRoaming and captive portal experiences are required.
Automatic Wi-Fi onboarding can be delivered through Cisco Spaces SDK-based onboarding, OpenRoaming, Passpoint, carrier offload, or supported identity-provider integration. The user device must have a compatible profile or identity relationship, and the wireless network must be configured to support the selected onboarding method.
Yes, but coexistence should be designed intentionally. Some environments use separate SSIDs for different onboarding models. Others use trusted-device or bypass workflows. If ISE remains the system of record for device registration or username and password guest access, keep that function in ISE and integrate Cisco Spaces only where the supported portal workflow applies.
Cisco Spaces Captive Portal is not designed to provide Cisco ISE-style username and password guest account login. If username and password guest accounts, sponsor approval, or complex guest identity lifecycle management are required, keep Cisco ISE or another identity platform in the design and use Cisco Spaces for supported cloud-managed portal workflows.
Treat operational issues as support cases rather than FAQ content. Capture the tenant, organization, network, SSID, location, rule, timestamp, and screenshots, then open a Cisco Spaces or Meraki support case through the appropriate support path.
Use these Cisco resources for implementation details, entitlement validation, OpenRoaming guidance, Meraki configuration, and support.
