Guest Access With ISE: Portals Without the Pain

By Taylor Thomas · 2026-08-31

Guest access earns its reputation the same way most identity projects do: not because any one piece is hard, but because the flow crosses three systems — endpoint, network device, and Cisco ISE — and a design that is fuzzy about any handoff fails in ways that look random. The fix is to learn the flow once, precisely. ISE guest deployments built on central web authentication — the standard design — run the same sequence, wired or wireless, wearing different portal configurations.

One Flow Underneath Everything

A guest device connects and, having no 802.1X supplicant configured for your network, lands in MAC Authentication Bypass. ISE does not know the MAC, and this is the design’s first quiet insight: under the guest policy you build, the unknown device is not rejected. It matches an authorization rule that grants a deliberately narrow result — permission to reach the portal, plus a redirect URL and the name of a redirect ACL sent to the switch or controller — the ACL itself must already be configured on the device, and a name mismatch between ISE and the device is a classic silent failure. When the guest opens a browser, the network device intercepts the web traffic the ACL describes and sends the browser to the ISE guest portal.

The guest authenticates at the portal — or simply accepts terms, depending on the portal type. Now the session’s rights must change, and the second insight arrives: the network device finished its RADIUS authorization minutes ago. ISE issues a Change of Authorization, the RADIUS mechanism that lets the server reach back into an established session. The device reauthenticates the endpoint, ISE now recognizes it as an authenticated guest, and a different authorization rule applies — the one that actually grants internet access. Two authorizations, with a portal visit between them: that is the entire architecture. This is central web authentication, CWA — the portal and the session decisions live on ISE, whichever identity store holds the credentials. The older alternative, local web authentication, puts the web exchange on the network device itself, which then submits the credentials over RADIUS; the CoA-driven mid-session re-steer that CWA is built around is not part of that design, which is why CWA is the standard approach in ISE deployments and the one to reason from.

Three Portals, One Decision

ISE dresses that flow in three portal patterns, and choosing among them is a single question: how much accountability do you need for who is on the guest network?

A Hotspot portal needs no individual guest account. The guest accepts an acceptable-use policy — optionally typing a shared access code — and the CoA fires. Right for coffee-shop-style access where presence, not identity, is the point. A Self-Registered portal has the guest create an account at the portal, with the account’s properties controlled by you and approval optionally routed through a sponsor. A Sponsored portal inverts the initiative: an authorized sponsor — typically an employee — creates the account first, through a separate sponsor portal, and the credentials reach the guest by print, email, or SMS. The account is tied to a named host from the start — the most attribution, and the most friction — a fit where every visitor already has one.

The administrative model behind credentialed guests has two levers worth naming precisely. Guest types govern the account: how long it lives and when it may connect — what it may reach is the authorization policy’s decision, keyed off the guest type. Sponsor groups govern the employees: who may create accounts, and of which guest types. Separating the two keeps the design honest — the receptionist can create day visitors without inheriting the right to mint week-long contractor accounts.

Where Designs Actually Fail

Three handoffs cause most field pain, and none of them is the portal. The redirect ACL must describe exactly the traffic to intercept — get it wrong and the guest sees a spinning browser, not a portal. DNS must resolve for the guest before authentication — without it, normal browsing typically never produces the web request that triggers the redirect, and the portal’s own hostname will not resolve either. And CoA must be permitted and configured on the network device; without it, guests authenticate at the portal and remain stuck with pre-auth access, a symptom that sends engineers hunting through portal settings when the portal was never the problem. Test each handoff independently — the deployment personas carrying the session, the device configuration, then the portal — and guest access stops being folklore.

On the certification side, this is not a corner topic: the SISE 300-715 blueprint gives Web Auth and Guest Services its own domain at 15% of the exam — configure web authentication (3.1), guest access services (3.2), and sponsor and guest portals (3.3). The flow above is the mental model those objectives assume.

Frequently Asked Questions

What is the difference between a Hotspot portal and a credentialed guest portal?

A Hotspot portal grants access without an individual guest account — the guest accepts an acceptable-use policy, optionally enters a shared access code, and is authorized. Credentialed portals require an account: with Self-Registration the guest creates it at the portal, optionally gated by sponsor approval; with a Sponsored portal an authorized sponsor — typically an employee — creates it beforehand through the sponsor portal. The choice is a provisioning and accountability decision: who creates accounts, and how much attribution the network owner needs for who is on the guest segment.

Why does guest access depend on CoA?

Because authorization happens twice. When a guest device first connects, ISE authorizes it with only enough access to reach the portal — the device authenticated by MAC address, not by any user credential. After the guest signs in — or accepts terms — at the portal, the session's rights need to change, but the switch or controller has already finished RADIUS authorization. Change of Authorization is the RADIUS mechanism that lets ISE reach back to the device and force the session to be reauthorized, now matching a rule that grants guest access.

Where is guest access on the SISE 300-715 blueprint?

It has its own domain: Web Auth and Guest Services, weighted at 15% of the exam. The objectives ask you to configure web authentication (3.1), guest access services (3.2), and sponsor and guest portals (3.3). Know the CWA flow end to end — MAB, redirect ACL and URL, portal authentication, CoA, re-authorization — and how guest types and sponsor groups divide the administrative work.