Introduction to Cisco ISE: What It Is and Why It Matters for 802.1X

What Cisco ISE Is

Cisco ISE (Identity Services Engine) is a network access control (NAC) platform. Its primary function is to act as the central policy decision point for who and what gets access to the network, under what conditions, and with what restrictions. In 802.1X deployments, ISE serves as the RADIUS authentication server — but that description understates what ISE actually does.

A plain RADIUS server checks credentials against a directory and returns pass or fail. ISE does that and then evaluates dozens of additional conditions: What type of device is this? Is it managed or unmanaged? Is its operating system current? Is the antivirus active? Has it been seen before? What network device is it connecting through? What time is it? Based on all of these, ISE returns not just pass or fail, but a specific access policy — VLAN assignment, downloadable ACL, security group tag, session timeout, redirect URL for posture assessment.

This article covers what ISE is, how it's deployed, and which components matter for 802.1X. Specific configuration tasks — adding network devices, configuring policy sets, setting up PEAP and EAP-TLS — are covered in the configuration articles starting with Article 9: Configuring Cisco ISE as a RADIUS Server for 802.1X.

ISE Deployment Architecture

ISE is deployed as one or more virtual machines or physical appliances. In most enterprise environments, it runs as VMs on UCS or another hypervisor platform. ISE 3.2 supports deployment on VMware ESXi, KVM, and as cloud instances on AWS and Azure.

A full ISE deployment uses three node personas:

Policy Administration Node (PAN)

The PAN is the management plane — it's where all configuration lives. ISE GUI runs on the PAN. Policy sets, identity sources, network device definitions, endpoint database, guest portals — all configured here. The PAN pushes configuration to the other nodes.

In a high-availability deployment, you have a primary PAN and a secondary PAN. The secondary PAN provides failover for the admin GUI; it does not process authentication requests directly. Promotion to primary is manual or automatic depending on configuration.

In this lab, a single ISE VM serves all personas (standalone deployment). This is appropriate for lab and small-scale production deployments.

Monitoring and Troubleshooting Node (MnT)

The MnT node collects all RADIUS accounting data, authentication logs, and operational data from the PSNs. It runs the database and API backend for Operations > RADIUS > Live Logs and Live Sessions — the views you spend the most time in when troubleshooting.

In a distributed deployment, authentication PSNs forward log data to the MnT. In a standalone deployment, the single node handles MnT functions locally.

Policy Service Node (PSN)

PSNs process RADIUS requests — they are the nodes your switches actually send RADIUS traffic to. In a large campus deployment, you may have dozens of PSNs spread across sites, with each access switch's RADIUS server configuration pointing to a nearby PSN.

PSNs handle:

• RADIUS authentication and authorization
• Profiling probes (DHCP, HTTP, SNMP, Netflow)
• Guest portal hosting
• Posture redirect and assessment
• CoA initiation

In the lab, ISE IP 10.0.0.10 is the single PSN (and PAN and MnT). In production, 10.0.0.10 would be a PSN that the Catalyst 9300 uses as its RADIUS server. The PAN may have a different IP — it doesn't process RADIUS requests.

The ISE Policy Model

ISE 3.2 uses a hierarchical policy model for 802.1X decisions:

Policy Sets

Policy Sets are the top-level containers for authentication and authorization policy. Each Policy Set has:

• A condition that determines which RADIUS requests this set handles
• An allowed protocols service
• A set of authentication rules
• A set of authorization rules

Navigation: Policy > Policy Sets

In most deployments, Policy Sets are scoped by network device type or network device group. For example:

• Policy Set "Campus-Wired" — matches requests from Catalyst switches (by device type attribute)
• Policy Set "Wireless" — matches requests from WLC or Catalyst Center
• Policy Set "VPN" — matches requests from ASA or FTD

Each Policy Set evaluates independently. Requests enter the first matching Policy Set and are evaluated only within that set.

Authentication Policy (Inside a Policy Set)

The Authentication Policy determines:

1. Which identity store to query (Active Directory, LDAP, ISE Internal, Certificate)
2. Which EAP methods to allow (via Allowed Protocols)

A typical Authentication Policy inside "Campus-Wired":

The "Dot1x" rule matches PEAP authentication and queries Active Directory. The "MAB" rule matches host lookup (UseCase = Host Lookup is how ISE identifies MAB requests, since MAB sends Service-Type = Call-Check) and queries the internal endpoint database.

Authorization Policy (Inside a Policy Set)

After authentication establishes identity, the Authorization Policy determines what access to grant. This is where VLAN, dACL, and SGT assignments happen.

Authorization rules evaluate in order. The first matching rule wins. Each rule has:

• Conditions: Who the user is, what group they're in, what device type ISE profiled, posture compliance status, etc.
• Result (Authorization Profile): Contains VLAN, dACL, SGT, session timeout, redirect URL

Sample Authorization Policy inside "Campus-Wired":

Authorization Profiles

Authorization Profiles define the policy attributes returned in the RADIUS Access-Accept. Navigation: Policy > Policy Elements > Results > Authorization > Authorization Profiles

A sample "Corp-Full-Access" Authorization Profile in ISE 3.2:

• Access Type: ACCESS_ACCEPT
• VLAN: VLAN ID 10 (or by name)
• dACL: None (or select a downloadable ACL)
• Security Group: Corp-Endpoints (SGT)
• Reauthentication: Timer 3600s, Maintain Connectivity

VLAN assignment uses the three RADIUS Tunnel attributes described in Article 5: Understanding RADIUS in 802.1X Authentication. ISE handles the attribute generation when you set the VLAN in the Authorization Profile — you don't manually configure RADIUS attributes.

ISE Identity Sources

Active Directory Integration

ISE joins Active Directory as a machine using a service account. Once joined, ISE can:

• Authenticate PEAP-MSCHAPv2 credentials against AD (ISE proxies the MSCHAPv2 exchange to AD's domain controller)
• Retrieve group memberships for authenticated users and machines
• Validate machine authentication (is this a domain-joined computer?)

Navigation: Administration > Identity Management > External Identity Sources > Active Directory

ISE 3.2 supports multiple AD domains and forests. In a multi-domain environment, ISE can use AD identity groups from multiple domains in authorization policy conditions.

Critical ISE + AD operational point: ISE must be able to reach a domain controller for every authentication. If the DC is unreachable during PEAP-MSCHAPv2, ISE cannot validate credentials and returns Access-Reject. This is a common failure mode at branch offices where the DC is at the headquarters and the WAN goes down. Plan accordingly with local ISE PSNs or RADIUS failover to a cached credentials mechanism.

Certificate Authentication Profile (EAP-TLS)

For EAP-TLS, ISE validates the client certificate rather than querying a password. The Certificate Authentication Profile defines which certificate field maps to the identity string (used in authorization policy conditions).

Navigation: Administration > Identity Management > Identity Sources > Certificate Authentication Profile

Configure:

• Principal Username X.509 Attribute: Subject - Common Name (most common), or Subject Alternative Name - Other Name (for UPN)
• Perform Binary Certificate Comparison: Optional — compares presented cert against the one stored in AD for the user
• Enable OCSP or CRL checking for revocation verification

ISE Internal Endpoint Database

The internal endpoint database stores MAC addresses as endpoints. This is the identity source for MAB authentication. When a device authenticates via MAB, ISE looks up the MAC address in this database.

Endpoints are created automatically the first time a device is seen (profiling probe data creates the endpoint record) or manually. Endpoints can be assigned to Endpoint Identity Groups — logical groups like "Cisco-IP-Phone," "Printer," "Windows-Workstation" — used in authorization policy conditions.

Navigation: Context Visibility > Endpoints (ISE 3.2 moves endpoint visibility to this dedicated section)

ISE Profiling

Profiling is ISE's ability to identify device types without requiring the device to authenticate. It uses multiple probes simultaneously:

DHCP Probe — ISE receives DHCP packets (either as a DHCP server, via DHCP helper pointing to ISE, or via SPAN). DHCP option 55 (parameter request list) and option 60 (vendor class) are strong device type indicators. Windows, macOS, iOS, Android all have distinct DHCP fingerprints.

HTTP Probe — When devices make HTTP requests (to the captive portal check URL, for example), ISE reads the User-Agent header. This identifies mobile devices, OS versions, and browser types.

RADIUS Probe — ISE reads RADIUS attributes from authentication requests — specifically Calling-Station-Id (MAC OUI) and NAS-Port-Id. Cisco IP Phones have a Cisco OUI. Combined with other probes, this identifies the device.

SNMP Probe — ISE polls the switch via SNMP to read CDP/LLDP neighbor information. CDP identifies Cisco phones by model name. This is one of the most reliable ways to identify Cisco IP Phones that haven't authenticated yet.

Cisco Device Sensor — An IOS XE feature where the switch itself sends device data (CDP/LLDP/DHCP) to ISE via RADIUS accounting. More efficient than ISE polling via SNMP.

Profiling results populate the endpoint's Endpoint Profile attribute. This attribute is available in authorization policy conditions — so ISE can return different policy for "Cisco-IP-Phone" vs. "Windows-Workstation" even if both authenticated via MAB.

Device Sensor configuration on IOS XE 17.9.x:

device-sensor filter-list dhcp list DHCP-SENSORS
 option name host-name
 option name requested-address
 option name parameter-request-list
 option name class-identifier
 option name client-identifier

device-sensor filter-list cdp list CDP-SENSORS
 tlv name device-name
 tlv name address-type
 tlv name capabilities-type
 tlv name platform-type

device-sensor filter-list lldp list LLDP-SENSORS
 tlv name system-name
 tlv name system-description

device-sensor filter-spec dhcp include list DHCP-SENSORS
device-sensor filter-spec cdp include list CDP-SENSORS
device-sensor filter-spec lldp include list LLDP-SENSORS

device-sensor notify all-changes

With Device Sensor configured, the switch sends probed data to ISE in RADIUS accounting packets. ISE uses this data to profile endpoints without needing SNMP access to the switch.

ISE Guest Lifecycle Management

ISE provides a complete guest access workflow relevant to 802.1X deployments:

Sponsor Portal — Internal employees (sponsors) log in to create guest accounts with defined time limits and access policies. Sponsors can be limited to specific guest types (Contractor, Visitor) based on sponsor group membership.

Guest Portal — When a device lands in Guest VLAN 30, the switch (or WLC) redirects HTTP traffic to ISE's self-registration or sponsor-approved portal. The guest enters their credentials, ISE validates them, and CoA upgrades the port to appropriate access.

Self-Registration — ISE can allow guests to create their own accounts with approval workflow or immediately, depending on policy.

This is relevant to 802.1X because the Guest VLAN is part of the 802.1X fallback chain. An unauthorized device lands in VLAN 30 and hits the guest portal — ISE orchestrates the entire experience from first EAPOL to authenticated guest session.

ISE Posture Assessment

Posture allows ISE to verify endpoint compliance before granting full network access. The posture flow with 802.1X:

1. Endpoint authenticates via 802.1X — ISE has no posture data yet
2. ISE returns "unknown posture" policy — limited access (VLAN 10 with dACL blocking everything except DNS and posture URLs)
3. AnyConnect (or ISE native supplicant) checks posture: AV running? OS patched? Firewall enabled?
4. AnyConnect reports posture result to ISE
5. ISE sends CoA to the switch — re-authorize session with compliant or non-compliant policy
6. Switch applies new VLAN or dACL based on CoA result

Posture requires AnyConnect (or a lightweight ISE supplicant) on the endpoint. It integrates directly with 802.1X — the authentication provides identity, posture provides compliance status, and the combination drives the final access policy.

ISE Live Logs and Troubleshooting Interface

The primary troubleshooting interface in ISE is Operations > RADIUS > Live Logs.

Live Logs show every authentication attempt — successful or failed — with:

• Timestamp
• Identity (username or MAC)
• Endpoint MAC address
• Authentication status (Passed / Failed)
• Authentication method (PEAP, EAP-TLS, MAB)
• Authorization Profile applied
• Failure reason (for failures — ISE provides specific reason codes)
• Network device (switch) and NAS port

Clicking on any log entry opens a RADIUS detail view with every RADIUS attribute sent and received, the policy evaluation steps, and the matched policy set/rules. This view is indispensable for troubleshooting — it shows exactly which policy rule matched, what conditions were evaluated, and which authorization profile was returned.

For active sessions, Operations > RADIUS > Live Sessions shows current authenticated endpoints with the ability to:

• Filter by username, MAC, VLAN, switch
• CoA: re-authenticate or disconnect individual sessions
• See accounting data (session duration, bytes)

ISE also provides Alarms (Operations > Alarms) for systematic issues — RADIUS server down, TrustSec configuration errors, node replication failures — that go beyond individual authentication events.

What ISE 3.2 Adds Over Earlier Versions

ISE 3.2 (released 2022, actively maintained) includes:

• Improved Policy Sets UI — Cleaner condition builder, better rule ordering visualization
• Pxgrid 2.0 — Enhanced integration with third-party platforms (Firepower, Stealthwatch, SD-WAN)
• REST ID Store — Use a REST API endpoint as an identity source (useful for custom identity systems)
• Enhanced Passive Identity — More sources for passive identity (Syslog, SPAN-based)
• Cloud-native deployment options — ISE on AWS and Azure for hybrid environments
• Improved profiling accuracy — Updated profiling policies for modern device types

For 802.1X configuration in this series, ISE 3.2 UI paths are used throughout. If your deployment runs an earlier version (3.0, 3.1), the policy model is the same; minor UI differences exist.

ISE Licensing

ISE licensing is modular and affects which features are available:

Essentials (formerly Base) — Basic RADIUS authentication, basic authorization. Covers 802.1X authentication with static policy.

Advantage (formerly Plus) — Adds profiling, guest lifecycle, BYOD onboarding, passive identity.

Premier (formerly Apex) — Adds posture assessment, TrustSec, and advanced threat integrations.

For a full 802.1X deployment with profiling and guest access, you need at least Advantage licensing. For posture and TrustSec, Premier is required. In lab environments, ISE provides a 90-day evaluation license with all features.

Summary: Why ISE for 802.1X

A plain RADIUS server can authenticate credentials. ISE authenticates identity, profiles the device, checks compliance, applies granular policy, orchestrates guest access, and dynamically adjusts authorization throughout the session lifecycle. The operational visibility in Live Logs alone — compared to the minimal logging of FreeRADIUS or Microsoft NPS — justifies ISE in enterprise deployments where troubleshooting efficiency matters.

Every configuration article in this series uses ISE 3.2. The navigation paths, policy structures, and troubleshooting techniques are consistent throughout the series.

What's Next: Article 7: 802.1X Authentication Flow Step by Step: From EAPOL Start to RADIUS Accept — a complete walkthrough of the entire authentication exchange from the moment a device plugs in to the port transitioning to authorized, with timing, debug output, and ISE log correlation.