Cisco ISE Interview Q&A — The Complete Engineer's Playbook (71 senior-grade questions)

PAN, MnT, PSN, pxGrid. Authentication and authorization runtime work happens on the PSN (Policy Service Node). The switch's radius server config points at PSN IPs — not the PAN. PAN authors and replicates policy, MnT stores logs, pxGrid publishes session context to ecosystem partners. A common stumble: candidates name the PAN as "the brain" and assume RADIUS lands there. It doesn't. Even in a single-box deployment, the runtime side that touches the RADIUS request is the PSN persona of that node.

Standalone — one node, all four personas on it. Lab/PoC only. Distributed — dedicated nodes per persona (e.g. 2 PANs + 2 MnTs + 6 PSNs). Production. Multi-Persona — a node wears more than one persona at a time, common in 2-node SMB deployments (each node = PAN+MnT+PSN). Limits to remember for the panel: max 2 PANs, max 2 MnTs, max 50 PSNs, max 4 pxGrid nodes (ISE 3.x). The architectural call you'll be asked to defend: "How many nodes for 25k endpoints across 3 sites?" — typical answer is 2 PAN+MnT combined + 6 PSNs (2 per site), with PSNs load-balanced via NAD server groups.

No. PAN failover is a manual promotion. If the Primary PAN dies, the Secondary PAN keeps serving read-only policy to PSNs (so existing auth keeps working), but you cannot author new policy until you promote the Secondary to Primary from its GUI. The reason Cisco kept this manual: a split-brain situation where both PANs think they're Primary would corrupt the replicated database. The seven-minute fix: log into Secondary PAN GUI → Administration → System → Deployment → select node → Promote to Primary. Old Primary, once recovered, comes back as Secondary. This is the most-missed answer at L2 interviews; many candidates say "it's HA". It's not in the auto-failover sense.

Unlike PAN, MnT failover IS automatic. PSNs send syslog to BOTH MnTs simultaneously, with the Primary marked active. If Primary MnT is unreachable, PSNs keep logging to the Secondary, and the GUI shows logs from whichever is alive. When the Primary returns, log replication catches up. The gotcha: RADIUS Live Logs in the PAN GUI come from the Active MnT — if both MnTs are down, Live Logs go blank even when PSNs are healthily authenticating. Production tip: monitor MnT disk usage; once opt partition crosses 80%, you'll start losing logs.

Because every RADIUS request is CPU-and-memory-heavy: parse the EAP exchange, hit AD/LDAP, run the policy set, evaluate posture, decide on an SGT, send the Access-Accept, then receive accounting. A small PSN (SNS-3615) tops out around 5k-7k concurrent sessions; a large one (SNS-3695) ~50k. Real-world load you'll be quoted: ~25 RADIUS auths/sec per PSN sustained. So a 100k-endpoint enterprise wants 6–8 PSNs spread across sites, with the switches' RADIUS server group failing one PSN over to another within ~3 seconds (dead-criteria time 3 tries 3 on Cat 9k).

The five you must remember: UDP 1812 (RADIUS auth), UDP 1813 (RADIUS accounting), UDP 1700 or 3799 (RADIUS CoA — Cisco IOS uses 1700, RFC-3576 uses 3799), TCP 443 (Admin GUI + ERS API + sponsor/guest portal), TCP 8443 (BYOD portal default). Add TCP 5222/7400/8910 for pxGrid, TCP 514/6514 for syslog from NADs to MnT, TCP 1521 for inter-node DB replication. The frequently-missed one in interviews: CoA is initiated BY ISE TO the switch on UDP 1700 — not the other way around. So your firewall must allow ISE PSN → switch:1700 outbound; if you block it, profiling and posture re-auth quietly break.

A Node Group is a logical cluster of PSNs at the same site, sharing session state via heartbeats over UDP 7800. Purpose: seamless session continuity during a PSN failover. If PSN-A handles a session and dies mid-posture, PSN-B in the same node group has the session record and can issue a CoA without bouncing the endpoint off the network. Without a node group, the switch hits PSN-B with a fresh request, ISE has no context for the in-flight session, and the endpoint gets re-auth'd. Senior tip: node groups must be in the same Layer-2 broadcast domain or have multicast/UDP 7800 explicitly permitted across the routed path. This is a senior question — most candidates miss it.

A Policy Set is a top-level container that bundles authentication rules + authorization rules + a condition that decides "does this request even belong to this policy set". ISE evaluates Policy Sets top-down, first-match-wins. Inside the matched set, authentication runs first (who are you?), then authorization (what can you do?). Real example: a Policy Set for Wired-802.1X (matches RADIUS:Service-Type EQUALS Framed AND DEVICE:Device Type EQUALS Switch), one for Wireless, one for VPN. The default rule at the bottom is your fallback — interviewers love asking "what catches everything you didn't think of?" Answer: the Default policy set, in DenyAccess by default.

Yes — that's the Standalone persona. All four roles run on one node. It's the only deployment where you don't need a license for redundancy because there's no redundancy. Use it for PoC, lab and very small deployments (<3k endpoints). The moment you add a second node, you must decide: dedicate the second node entirely, or make both nodes multi-persona (each running PAN+MnT+PSN, with one Primary and one Secondary). Multi-persona scales worse than dedicated because RADIUS load and PAN replication fight for CPU on the same box.

50 PSNs in ISE 3.x. The limit comes from the PAN's database replication architecture: the Primary PAN must push policy/CA/cert updates to every PSN, and the replication tree gets unstable beyond ~50 spokes. Real enterprises hitting that ceiling (e.g. a 500k-endpoint bank) deploy multiple ISE cubes — each cube is an independent deployment with its own PAN pair — and federate via pxGrid 2.0 / Cisco DNA Center for cross-cube visibility. A second L3 angle: the limit is tested at 50, not hard-coded; Cisco TAC will not support clusters beyond 50, even if the GUI lets you add the 51st node.

Two dedicated PAN+MnT-combined nodes in HQ, plus 6 dedicated PSNs — two per site, grouped into per-site Node Groups. Site switches RADIUS to the local PSN pair first (server-group priority 1), failover to remote PSNs second. Why this shape: 25k endpoints at ~5k per PSN gives you a 3× safety factor; per-site PSNs keep auth latency under 100ms even when the WAN to HQ is congested; the Node Group keeps session state local so a PSN reboot doesn't bounce 5k laptops. Don't shortcut to a 2-node multi-persona — at this scale, PAN replication contends with RADIUS service on the same node and posture starts timing out.

Already covered in Q7, but interviewers re-ask it framed this way: HA = redundancy between Primary/Secondary of a persona (e.g. PAN-Pri/PAN-Sec for policy). Node Group = shared session cache between same-role PSNs so an in-flight RADIUS/posture session survives a single PSN failure. They serve different layers — HA covers the persona; Node Group covers the session. A common screw-up: putting PSN-Mumbai and PSN-Pune in the same Node Group across a WAN. The heartbeats over UDP 7800 will drop, the group fights itself, and CoA breaks intermittently. Keep Node Groups within a single LAN.

RADIUS server group on the switch, with automate-tester username probe-user probing each PSN every 60s on UDP 1812. The first PSN that answers within radius-server timeout 5 wins. If both PSNs miss radius-server retransmit 3 retries, the switch marks the server DEAD for radius-server dead-criteria time 3 tries 3. While dead, the switch skips it and uses the next server in the group. Cat 9k 17.9+ adds aaa group server radius ISE-PSN with load-balance method least-outstanding so requests are spread across both PSNs in normal operation. Expected output: show radius statistics shows Number of responses: 4567 and Server state: UP per PSN.

When the switch marks all configured RADIUS servers as DEAD, it must decide what to do with new endpoints plugging in. authentication event server dead action authorize vlan 100 tells it: drop new sessions into VLAN 100 (the Critical Auth VLAN) — typically a limited DHCP-only network so users can still get to a help-desk page. authentication event server dead action authorize voice does the same for voice. Without this config, the switch defaults to denying the port — meaning total RADIUS outage = total network outage for new logins. Senior interviewers always test this; many candidates know fail-open but not the Critical VLAN nuance.

Three port behaviours during 802.1X rollout: Closed (Monitor Mode OFF) — port denies all traffic until auth succeeds. The pure 802.1X experience, but breaks PXE boot, WoL, etc. Open (Monitor Mode) — port allows all traffic, ISE logs would-be auth decisions but doesn't enforce. The "see-what-would-happen" mode you live in for weeks before turning on enforcement. Low-Impact — port has a pre-auth dACL that permits DHCP/DNS/PXE/TFTP but blocks everything else; auth then opens the rest. Low-Impact is the sweet spot for enterprises with imaging workflows; Closed is for high-security. Expected on-switch: authentication open vs no command, plus ip access-group PRE-AUTH in on the port for Low-Impact.

Eight steps, narrate them in this order: (1) Endpoint sends EAPoL-Start. (2) Switch replies EAP-Request:Identity. (3) Endpoint sends EAP-Response with username/MAC/identity. (4) Switch wraps the EAP payload into a RADIUS Access-Request to PSN. (5) PSN and endpoint do the EAP method exchange (TLS handshake, MSCHAPv2, etc.) through the switch — switch is just a relay. (6) PSN hits AD/LDAP/internal-store to look up group membership. (7) PSN returns RADIUS Access-Accept with authorization attributes (dACL, VLAN, SGT). (8) Switch programs the port and sends EAP-Success to the endpoint. Endpoint is now on the network. The whole flow is ~2-8 seconds depending on EAP method and WAN.

MAC Authentication Bypass. When an endpoint can't speak 802.1X (a printer, IP camera, badge reader, legacy IP phone), the switch waits for the 802.1X timeout (~30s if Closed mode), then learns the MAC from the first frame and sends it as both username and password in a RADIUS Access-Request. ISE checks the MAC against its Endpoint Database (built by profiling probes) — if known and authorized, returns an Access-Accept. The huge gotcha: MAB is trivially spoofable (clone a printer MAC and you're in). Mitigations: lock down MAB-authorized devices to a printer VLAN with a dACL that only allows IPP/9100, enable profiling to detect "this MAC suddenly speaks Windows DHCP" and CoA them off, layer 802.1X-with-MAB-fallback for laptops.

Three EAP methods, all establishing a TLS tunnel before exchanging credentials. EAP-TLS — mutual cert: both endpoint and ISE present X.509 certs. No password ever leaves the device. Strongest auth, but you need a PKI (ISE internal CA, or AD-CS). Mandatory for high-security and BYOD. PEAP (Protected EAP) — server-only cert: ISE presents its cert, endpoint validates it, then sends username+MSCHAPv2 password inside the tunnel. Easy rollout (uses existing AD passwords) but you must teach users to validate the cert (90% of breaches start with a fake ISE cert). EAP-FAST — Cisco's PAC-based method, used mainly internally on AnyConnect/Cisco IP phones. Faster than TLS because the PAC replaces the cert exchange after first use, but Cisco-centric. Modern best practice: EAP-TLS for managed devices, PEAP-MSCHAPv2 only as legacy fallback, EAP-FAST for Cisco-only ecosystems.

Both are guest captive portals. Local WebAuth (LWA) — the switch/WLC hosts the portal page locally; endpoint hits it, posts credentials, switch sends a RADIUS check to ISE. Simpler on cheap deployments but limits portal customization. Centralized WebAuth (CWA) — the switch sends the endpoint to ISE itself (redirect URL inside the Access-Accept), ISE renders a fully-branded portal, validates the guest credential, then sends a CoA back to the switch with the new authorization. CWA is what every enterprise uses because it gives Sponsor flows, Self-Reg, social login (Google/Microsoft365), and a single look-and-feel across wired + wireless + VPN. LWA still shows up on legacy IOS switches without CoA support.

RFC 5176. CoA is ISE telling the switch "the authorization decision you got 5 minutes ago is stale — re-auth this session or apply these new attributes". Three flavours: CoA Push (Reauth) — switch drops the session and starts fresh 802.1X. CoA Port Bounce — switch flaps the port down/up (forces DHCP renew, used after VLAN changes so the endpoint gets the new VLAN's DHCP). CoA Disconnect (Terminate) — switch tears down the session entirely. Triggers: posture completes (Unknown → Compliant → new dACL), profiling changes the device type (an IP phone got profiled as a Windows laptop = re-authz), Guest Sponsor approves a request, admin manually clicks Bounce in the Live Logs. CoA travels UDP 1700 (Cisco) or 3799 (RFC). If your firewall blocks PSN→switch:1700, profiling and posture silently break.

Yes — and you should, on user-access ports. The switch tries 802.1X first; if the endpoint doesn't respond to three EAPoL-Identity requests (~30s default), it falls back to MAB and learns the MAC. Config: authentication order dot1x mab + authentication priority dot1x mab. This is how a port can serve a Windows laptop with 802.1X today and an IP phone with MAB tomorrow without reconfig. Common mistake: leaving authentication open in production after PoC — port stays open during the 30s fallback, which is a security gap. For low-impact mode, pair with a pre-auth dACL.

Auth failure = "I can't prove who you are" → wrong cert, expired AD password, EAP method mismatch. Live Logs show event 5400 Authentication failed. Authorization failure = "I know who you are but you don't match any allow-rule" → user is valid in AD but the AuthZ policy hits the default DenyAccess. Live Logs show 5434 Endpoint conducted several failed authentications or 15039 Rejected per authorization profile. Diagnosing distinction: open the failure in Live Logs → if the "Authentication Policy" line is blank, AuthN failed; if it's filled but "Authorization Profile" is DenyAccess, AuthZ failed. The fix path is completely different — AuthN means credentials/PKI; AuthZ means policy logic.

EAP chaining (EAP-FAST v2 / TEAP) lets ISE authenticate BOTH the user AND the machine in a single EAP exchange. Why this matters: a corporate Windows laptop boots → machine auth via cert → user logs in → user auth via PEAP-MSCHAPv2. Without chaining, ISE has two separate sessions and can't easily write a policy like "only allow if BOTH the laptop is corporate AND the user is in Engineering". With chaining, both identities ride in one EAP exchange and the AuthZ rule can match EAP Chaining Result EQUALS User and Machine Both Succeeded. The catch: Windows native supplicant only supports it via the Cisco AnyConnect NAM client; Windows 11 22H2+ adds TEAP support natively. This is a senior-only question — most candidates have never heard of it.

dACL (Downloadable ACL) — ISE sends a per-session ACL that the switch applies to the port. Best for fine-grained L3/L4 control per user without touching VLANs. Limits: switch TCAM space, ACL length, no scaling beyond a few thousand sessions. VLAN assignment — ISE returns Tunnel-Type=VLAN, Tunnel-Medium=802, Tunnel-Private-Group-ID=20 in the Access-Accept; switch moves the port to that VLAN. Best when you want true L2 isolation (Guest VLAN, Quarantine VLAN). Limits: requires CoA Port-Bounce to make the endpoint DHCP-renew. SGT (TrustSec) — ISE tags the session with a numeric Security Group; downstream switches/firewalls enforce via an SGACL matrix. Best for large-scale microsegmentation without renumbering VLANs. The senior pick today is SGT-first with dACL fallback on non-TrustSec hardware.

TrustSec = Cisco's role-based access control framework. SGT (Security Group Tag) is a 16-bit number ISE assigns at authentication time, riding inside the Ethernet CMD (Cisco Meta Data) field. SGACL (Security Group ACL) is the policy matrix at the enforcement point — "source SGT 8 → destination SGT 20: permit tcp 443 / deny tcp 22". The endpoint never sees the SGT; only the TrustSec-capable infrastructure does. The value proposition: instead of 200 VLANs and a tangle of ACLs, you have ~30 SGTs and a single SGACL matrix that ISE pushes everywhere. Three-line interview answer: "SGT tags the user/device, SGACL enforces between SGTs, ISE owns both."

SXP (SGT eXchange Protocol) over TCP 64999. The problem it solves: not every switch supports inline CMD tagging — Cat 2960-X, older Nexus, some firewalls don't. SXP lets a TrustSec-capable switch tell a non-capable device "IP 10.40.5.12 = SGT 8" out-of-band, so the destination can still enforce SGACLs against that IP. ISE itself can act as SXP speaker/listener so you don't need a hierarchy of switches forwarding it. Two SXP topologies: single-hop (speaker → listener) for small networks, multi-hop with aggregator for hundreds of devices. Watch for: SXP is TCP, no encryption by default — wrap in IPsec or MD5 if traversing untrusted paths.

CTS Environment Data + CTS Policy Acquisition. The switch first authenticates to ISE as a Network Device (PAC-based), then issues cts refresh environment-data to fetch the SG table (numeric → name mapping) and cts refresh policy to pull the SGACL matrix relevant to its local SGTs. Switch caches them; ISE can push refreshes via CoA Env-Data-Refresh. Verify on the switch: show cts environment-data and show cts role-based permissions. The matrix shows up as Default permission: PERMIT IP-00 with explicit deny rows per source/destination SGT pair. If show cts is empty after RADIUS works, your CTS PAC didn't provision — re-issue cts credentials id SW-PUNE password Cisco123.

A dACL is a named ACL stored on ISE (Policy → Policy Elements → Results → Authorization → Downloadable ACLs). The Access-Accept contains attribute cisco-av-pair=ip:inacl#1=permit ip any 10.50.5.0 0.0.0.255 OR a name reference ACS:CiscoSecure-Defined-ACL=PERMIT_ENG; switch issues a second RADIUS request to download the named ACL once, then applies it to the port. Why ISE-stored instead of switch-stored: change the ACL once in ISE, and the next time any switch downloads it, every endpoint inherits the change without touching switch config. Senior caveat: dACL length is bounded by switch TCAM — Cat 9k handles ~1500 ACEs comfortably; older 2960 cuts at ~64.

The headline ones: User-Name, Class (carries session-ID), Filter-Id or cisco-av-pair=ip:inacl#1=... (dACL), Tunnel-Private-Group-ID (VLAN), cisco-av-pair=cts:security-group-tag=0008-00 (SGT), Session-Timeout (re-auth timer), Termination-Action=RADIUS-Request (re-auth on timeout, don't disconnect), cisco-av-pair=url-redirect-acl=ACL-WEBAUTH-REDIRECT + url-redirect=https://ise:8443/... (CWA redirect). For posture, add cisco-av-pair=url-redirect pointing at the posture portal. You'll be asked: "What two attributes are mandatory for CWA?" — Answer: the redirect-URL AND the redirect-ACL; without the ACL the switch doesn't know what traffic to redirect.

Authorization Profile = the bundle of RADIUS attributes ISE will return — VLAN, dACL, SGT, redirect URL, timers. It's the "envelope". Reusable across many rules. Authorization Policy = the if-then rule that decides WHICH profile to apply, based on conditions like AD:memberOf CONTAINS Engineering AND EndPoint:LogicalProfile EQUALS Corp-Laptop. One Authorization Policy rule → one Authorization Profile reference. Standard naming pattern: Profile: PERMIT_ENG_DACL, Rule: Engineering_PSC → PERMIT_ENG_DACL. Interviewers often test the inversion: "Can two rules use the same profile?" Yes, that's exactly the design intent — reuse profiles, multiple rules.

Yes — that's the point of CoA Push Reauth + Profile Update. ISE sends a CoA with new attributes (new dACL, new SGT); the switch applies them to the existing session without dropping it. Works on Cat 9k with aaa server radius dynamic-author + CoA enabled. The endpoint doesn't notice — no DHCP renew, no traffic interruption. Use this for posture-pass transitions (Unknown → Compliant: swap the redirect-dACL for the production dACL). Caveat: VLAN changes still require a Port-Bounce or full Reauth because the endpoint needs a new DHCP lease in the new subnet.

The Profiler service on each PSN consumes signals from the probes (RADIUS, DHCP, SNMP, NMAP, HTTP, AD, NetFlow) and runs them against a library of ~600 Endpoint Profile Policies. Each profile has weighted conditions; when an endpoint's collected attributes cross the profile's Minimum Certainty Factor (typically 70+), the endpoint is tagged. Example: Apple iPad has rules like DHCP:host-name CONTAINS iPad (40 points) + DHCP:option-55 EQUALS Apple-fingerprint (40 points) + OUI from MAC EQUALS Apple (20 points). 100 points = locked in as Apple-iPad. Profile changes can trigger CoA so the new AuthZ rule applies.

DHCP probe for unmanaged endpoints — DHCP option 55 (Parameter Request List) is so vendor-specific it identifies the OS in one packet. iPhone, Windows 10, Android, ChromeOS all have distinct fingerprints. RADIUS probe for managed endpoints because it's always on. Most experienced engineers turn ON DHCP + RADIUS + SNMP and leave NMAP + NetFlow off until they need them. Big anti-pattern: turning ON every probe by default — NMAP scans saturate small PSNs and trip IPS alarms on the network team.

Endpoint Profile = leaf (Apple-iPad-Mini, Apple-iPad-Pro, Apple-iPad-Air). Logical Profile = group of leaves you treat the same way ("All-iPads"). Why: AuthZ rules should match Logical Profiles, not Endpoint Profiles, so adding a new iPad model in 2027 doesn't require an AuthZ rule change. Standard fleet has Logical Profiles like Corp-Laptops, BYOD-Mobile, IoT-Printers, IoT-Cameras, IP-Phones. Common interview probe: "Why match Logical instead of Endpoint?" Answer = scale + maintainability.

Yes — and it's the foundation of how MAB stops being trivially spoofable. With profiling on, even a MAB-authenticated printer is continuously evaluated. The moment the "printer" starts sending DHCP option 55 fingerprint = Windows 10, ISE re-profiles, fires CoA, and the AuthZ engine drops it into a Quarantine VLAN. So the design pattern: enable MAB for IoT, but pair it with mandatory profiling + a CoA-fired re-auth-on-profile-change. Without that, MAB-only is a thin lid on a deep hole.

Three knobs. (1) Profiler Feed — keep the offline feed updated weekly so new profiles don't re-classify in bulk after an update. (2) Endpoint Attribute Filter — disable noisy attributes (some DHCP options bounce a lot during DHCP renewals); Profile Configuration → Filter Endpoint Attributes. (3) CoA settings on AuthZ Profile — set Reauth instead of Port Bounce for profile changes, and gate it with Wait for Profiler Completion. Watch for: bursty CoA after a switch reboot when 200 phones DHCP at once — node group + staggered re-auth timers (random offset) helps. Real war story: a 1000-port floor went into a CoA loop because someone enabled NMAP probe globally; turning it off fixed it in 90 seconds.

Seven steps: (1) Endpoint authenticates (802.1X/MAB). (2) AuthZ assigns Posture_Unknown profile — limited dACL + redirect to https://psn:8443/portal/posture. (3) Endpoint's AnyConnect/Cisco Secure Client ISE Posture module (or Network Setup Assistant) detects redirect, runs the posture probes (AV running? OS patches? disk-encryption?). (4) Client posts result to PSN. (5) PSN evaluates against the Posture Policy. (6) If Compliant → PSN sends CoA Reauth with new attributes (production dACL, no redirect). If Non-Compliant → CoA Reauth with remediation dACL + redirect to remediation page. (7) Compliance state stored in Session Cache with a timeout (default 1 hour). Periodic re-assessment configurable.

Three layers. Posture Condition = the atomic check ("Defender Antivirus is running", "BitLocker is enabled on C:", "Windows OS build ≥ 22621"). Posture Requirement = a Condition bound to a Remediation action (if AV not running → trigger a remediation script that starts the service). Posture Policy = which Requirements apply to which user/device/OS combination, e.g. "Windows 11 + AD-joined laptops must meet REQ-AV + REQ-BITLOCKER + REQ-PATCH-30D". The policy then maps to an AuthZ profile decision via the Session:PostureStatus condition.

The ISE Posture module in AnyConnect/Cisco Secure Client can run in two UI modes. Visible mode — shows the user a System Scan window with status, remediation prompts, "Click here to fix". Best for BYOD / managed laptops where you want the user to act. Stealth Mode — runs silently, no UI; posture happens behind the scenes. The user only notices when access changes (kiosk laptops, server consoles). Stealth requires the user to have admin rights once during install so the service can be installed as SYSTEM. Senior interview spike: "Can stealth mode do remediation?" Yes — for auto-remediation actions like "start AV service" or "trigger Windows Update" — but it cannot pop a dialog asking the user to act.

The redirect-ACL is a LOCAL ACL on the switch (not on ISE) that defines which traffic gets HTTP-intercepted and redirected to the ISE portal. Typical content: deny ip any host <ISE-PSN> (allow direct to ISE for posture-module download + posting), deny udp any any eq 53 (allow DNS), deny udp any any eq 67 (allow DHCP), permit ip any any (intercept everything else). The Access-Accept from ISE references this ACL by NAME: cisco-av-pair=url-redirect-acl=ACL-WEBAUTH-REDIRECT. If the name doesn't match a local ACL on the switch, redirect silently fails — endpoint reaches DNS and DHCP but the browser sees timeouts. Cisco's #1 deployment bug.

Top three causes. (1) Posture module version mismatch — endpoint has 4.x, ISE expects 5.x; module can't post results. Verify in AnyConnect → Statistics → ISE Posture → "Failed to acquire discovery host". Fix: update Client Provisioning Resources in ISE, push a re-download. (2) Discovery host unreachable — posture module hits http://enroll.cisco.com or the configured discovery URL; if firewall blocks port 80, no discovery. Fix: switch to discovery method HTTP Discovery via NAD redirect. (3) Redirect ACL on switch is broken — the module can't reach ISE to post, so it stays Unknown. Verify show ip access-list ACL-WEBAUTH-REDIRECT on the switch. Run all three checks; one will be the answer.

Hotspot — no credentials at all; user accepts AUP and is on the network. For coffee-shop-style open access. Logs MAC but no identity. Self-Registered — user fills a form (name, email, phone), ISE auto-creates an account with auto-expiry (typically 8 hours), often sends OTP via SMS/email. Good for visitors. Sponsored — visitor requests access, an internal sponsor (employee) approves via portal/email, ISE creates the credential. Best for high-security tenants. Cisco ISE 3.x adds social login (Microsoft 365, Google) inside Self-Registered flows so the user signs in with their own cloud identity.

Six steps. (1) Guest's laptop joins SSID-Guest → WLC sends MAB to ISE. (2) ISE has no match for the MAC → AuthZ rule "Guest_Unknown" returns Access-Accept with url-redirect=https://psn:8443/portal/PortalSetup.action?portal=Guest + url-redirect-acl=ACL-GUEST. (3) WLC programs intercept; guest opens browser, hits CNN, gets redirected. (4) Guest fills the Self-Reg form, submits, gets OTP, logs in. (5) ISE creates the GuestUser internal account, then sends CoA Reauth to the WLC. (6) Second auth lands on the GuestUser identity; AuthZ rule "Guest_Authenticated" returns a permissive dACL with internet-only access. The whole flow is 60-120 seconds.

Goal: get an employee's personal device onto corp Wi-Fi with EAP-TLS using an ISE-issued certificate. Five steps. (1) Device joins SSID-Onboarding with PEAP credentials (employee AD password). (2) ISE recognises personal-device + first-time → redirects to BYOD portal. (3) Portal pushes Network Setup Assistant (NSA) — a small app that calls SCEP/EST to ISE's internal CA, generates a key pair, gets a cert signed. (4) NSA installs the cert + creates a Wi-Fi profile pointing at SSID-Corp (EAP-TLS). (5) Device disconnects from SSID-Onboarding, reconnects to SSID-Corp using the new cert. From now on, no password, no portal — just cert auth. The Endpoint Identity Group RegisteredDevices tracks all BYOD-enrolled devices.

For email: ISE has a built-in SMTP client; configure in Administration → System → Settings → SMTP. Sends from your corporate mail relay (e.g. smtp.corp.local:25) or any SMTP service. For SMS: ISE doesn't speak SMS natively; integrates with an SMS gateway provider over HTTPS API — Twilio, Click-Send, India's MSG91 — via the Administration → System → Settings → SMS Gateway page (URL template with placeholders for phone + message). The OTP is generated by ISE's Guest service and stored in the Internal Endpoints DB until validation. Common deployment goof: forgetting to test-send from the SMTP page; production guest flows then fail silently on the OTP step.

Yes — CWA works the same on wired and wireless. The switch (Cat 9k) must support device-tracking + http intercept and have a redirect-ACL configured. Common use: visitor desks in a lobby with wired Ethernet ports; same SSID-Guest experience via cable. The subtle difference: on wired, the switch must do an HTTP intercept to redirect the browser; on wireless, the WLC handles it. Wired needs the IOS-XE policy-map type control subscriber stack (Identity Services), which has more moving parts to debug than the WLC equivalent.

Four certs on every PSN. Admin cert — used by the admin GUI (port 443) and ERS API. EAP cert — presented to supplicants during EAP-TLS/PEAP/EAP-FAST inner TLS. Usually has the PSN FQDN as CN and Subject Alt Names for every PSN node. Portal cert — used by guest/sponsor/BYOD/posture portals (port 8443). pxGrid cert — used to authenticate to pxGrid subscribers. Best practice: one wildcard cert covering *.ise.corp.local + SANs for all PSN/PAN hostnames; use a corporate CA so endpoints already trust the chain. The chain (root + intermediate) must be imported into the Trusted Certificates store on ISE.

ISE 2.0+ ships with a built-in Certificate Authority, a hierarchy of root CA + node CA + endpoint sub-CA. Used to sign endpoint certs during BYOD enrolment (via SCEP/EST) and pxGrid certs. The internal CA scales to ~1M endpoint certs across a deployment. When to use it: any enterprise that doesn't have a mature AD-CS infrastructure, or any BYOD program where you don't want personal devices to touch your corporate CA. When NOT to use it: high-security shops with existing AD-CS — keep one CA hierarchy, use AD-CS via SCEP. Critical caveat: rebuilding the internal CA invalidates every endpoint cert it issued; expect a mass re-enrolment storm.

Three enrolment paths. SCEP (Simple Certificate Enrollment Protocol) — the legacy default. HTTP-based, uses a shared secret for initial trust. Widely supported (Cisco, Microsoft AD-CS, ISE internal). EST (Enrollment over Secure Transport, RFC 7030) — modern replacement; uses TLS + client auth for trust. ISE 3.x supports EST. More secure than SCEP. CWA + Cert Provisioning — the portal-driven flow where the BYOD user clicks through, and ISE silently runs SCEP/EST under the hood. Senior question framing: "Why use EST?" Answer: SCEP's reliance on a shared secret means anyone with the secret can request certs; EST replaces that with TLS mutual auth.

Because ISE extracts the Certificate Authentication Profile (CAP) identity from the cert and tries to match it against an Identity Store. The CAP defaults to Subject-CN. If your cert CN is sneha.s@corp.local but AD has sneha.s (no UPN suffix), ISE searches AD for the UPN and finds nothing. Fix: change the CAP to extract Subject Alternative Name → UPN instead, OR set the Identity Store to "Any Internal/AD" with attribute mapping. Verify in Live Logs → the failed step is 15042 Username does not exist. Senior fix-in-one-line: align the cert SAN UPN with AD's userPrincipalName.

Two-step pre-stage. (1) Import the NEW cert into ISE but DON'T bind it to the EAP role yet. (2) Publish the new cert's CA chain to every endpoint trust store (GPO, MDM). Wait for endpoints to trust the new chain. (3) During a maintenance window, bind the new cert to the EAP role on every PSN (Administration → System → Certificates → System Certificates → select PSN → click cert → "Make it the EAP cert"). The old cert keeps working for currently authenticated sessions (Session-Timeout decides when they re-auth). Endpoints whose trust store has the new chain succeed on the next auth. The 4-AM-Saturday horror story: replacing the EAP cert without pre-publishing the chain → every endpoint sees "untrusted server" and refuses to auth → 30,000 users stuck → reverse the change, do it again next week with pre-stage. Don't be the 4AM person.

AD Join — ISE becomes a domain-joined member, creates a computer object, uses Kerberos for auth, supports MSCHAPv2 + machine auth + EAP-FAST + Group-Policy queries. Required for any deployment using PEAP-MSCHAPv2 against AD. LDAP — simple bind to AD or any LDAP directory; reads attributes, but cannot do MSCHAPv2 hash comparison (no Kerberos). Use LDAP when you don't want ISE in your AD domain (multi-tenant MSPs), or when the directory ISN'T AD (OpenLDAP, eDirectory). Most enterprises do AD Join for primary auth + LDAP for secondary external directories.

Yes — ISE 2.x+ supports multi-forest. Each forest is its own Active Directory Join Point with its own service account and trust. ISE then has a Identity Source Sequence that walks join points in order during auth. Use case: a merger-and-acquisition shop where the acquired company runs acme.local and HQ runs corp.local — both are unmerged for the next 18 months. Limit per current docs: 200 join points across the deployment. Watch for trust validation — if HQ and Acme don't have an AD trust, ISE handles them as independent identity stores, which is fine but means you can't say "Engineering across both forests" in one rule.

Standard: AD:External Groups (the famous "memberOf" check), AD:Name, AD:Department, AD:userPrincipalName. Custom: any LDAP attribute you mark for retrieval in the AD Join Point's "Attributes" tab (e.g. employeeType, extensionAttribute1). The senior interview move: "Can I match on extensionAttribute1 = 'PCI-Scope-User'?" Yes, but you must add the attribute to the retrieval list first; ISE caches it per session. Hot tip: matching on memberOf with nested groups requires turning on Use AD User Groups Recursive Search in the AD Join Point — without it, nested groups don't resolve and your AuthZ rule silently misses everyone in nested groups.

Three common causes. (1) ISE is talking to a remote-site DC over a slow WAN; AD Join Point should be configured with site-aware DCs only (use Test User to see which DC ISE hits). Fix: set Preferred DCs to the local site's DCs explicitly. (2) Too many concurrent kerberos requests; AD Join Point has a per-PSN connection limit (~100 default). Fix: scale PSNs OR enable AD response caching (Authentication Domains → cache results 60s). (3) Antivirus on the DC blocking the SMB connection used for group queries. Live Logs reveal: 24408 AD: Authentication completed; group retrieval timed out. Quick triage: from ISE CLI show application status ise + application configure ise → Test AD connection.

pxGrid (Platform Exchange Grid) = Cisco's pub/sub bus where ISE shares session, identity, SGT and posture context with ecosystem partners. 1.0 used XMPP over TCP 5222 — clunky, hard to firewall, vendor-specific clients. 2.0 (default in ISE 2.4+) uses WebSocket + REST over TCP 8910 / 7400 — modern, easier integrations, opens the door to non-Cisco subscribers (Splunk, ServiceNow, Cortex XSOAR). Both versions authenticate via mutual cert — every subscriber must present a cert signed by a CA ISE trusts. Best practice today: deploy pxGrid 2.0; pxGrid 1.0 is legacy-only.

ANC is the reverse pxGrid flow — instead of ISE publishing to subscribers, a subscriber tells ISE to take action on an endpoint. Typical: Firepower detects malware on a host → publishes a "quarantine" action with the MAC to ISE's ANC topic → ISE looks up the active session → sends CoA Reauth to the switch with a Quarantine dACL/SGT. The endpoint is contained within seconds, automatically, without an L2 ticket. Configure: Operations → ANC → Endpoint Assignment, define policies (Quarantine, Port-Bounce, Shutdown). For interviews, ANC is the killer pxGrid story — "Firepower sees malware, ISE quarantines, all without a human".

The hit list: Cisco Firepower / FMC — maps RADIUS sessions to firewall connections (logs show user + posture + SGT next to every TCP flow). Cisco DNA Center — fabric-aware automation, SDA microsegmentation. Cisco Secure Network Analytics (Stealthwatch) — enriches NetFlow with user identity for forensic timelines. Forescout — cross-NAC visibility for hybrid Cisco+Forescout shops. Splunk pxGrid app — feeds ISE events into SOC dashboards. Cortex XSOAR / SOAR platforms — automated playbooks call ISE ANC to quarantine. 3rd-party MDM (Workspace ONE, Intune) — push compliance state for posture decisions.

ERS (External RESTful Services) = ISE's classic REST API for CRUD on policy objects — create an internal user, modify a guest account, query endpoints. Synchronous request/response over HTTPS:9060. pxGrid = pub/sub for real-time events. Don't confuse them. Use ERS for provisioning/admin (your ITSM portal creates 50 internal users), use pxGrid for events (your SIEM consumes RADIUS session updates as they happen). Activate ERS at Administration → System → Settings → ERS Settings; create a dedicated ERS-Admin account; pin source IPs. As of ISE 3.x, OpenAPI also exists as the modern replacement for ERS for new integrations — same idea, OAuth2 instead of basic-auth.

Use the 7-step flow above. The single most important screen is Operations → RADIUS → Live Logs. Filter by Username or Endpoint MAC (paste the MAC with colons). Click the failed row → modal opens with: Authentication Method, Identity Store, Authorization Policy that matched (or "no match → DenyAccess"), Failure Reason. The failure reason maps to a numbered ISE error code (5400, 12503, 22056) that points to the actual problem — Cisco's Error Code DB is canonical: https://www.cisco.com/c/en/us/td/docs/security/ise/syslog/.../ISE-syslogs.html. Knowing the top 10 error codes by heart (5400 = auth fail, 12503 = EAP fail, 24408 = AD timeout, 11038 = invalid cert) saves you twenty minutes per ticket.

Live Logs = the event log — every auth attempt, success and failure, last hour by default. Source: MnT. Live Sessions = the active session table — endpoints currently authenticated, with their assigned VLAN/dACL/SGT/posture state. Source: PSN session cache. Two questions, two screens. If a user has no Live Session row but a successful Live Log, the switch dropped the session (port shut, link down). If they have a Live Session marked "Posture Pending" forever, the redirect-ACL is broken. The first 5 minutes of every ISE ticket: open both, screenshot both.

The AuthZ side. Open Live Sessions, click the user → see the assigned dACL, VLAN, SGT. Then on the switch: show ip access-list interface Gi1/0/14 — does it include permits to the app's subnet/ports? If using SGT: show cts role-based permissions from 8 to 20 — is the SGACL right? If using VLAN: is the VLAN gateway present, is the DHCP scope alive, does ACL on the L3 SVI permit traffic to the app? 80% of "authenticated but can't reach X" tickets are a missing line in the dACL or an SGACL deny somewhere downstream. Fix in ISE → CoA → done in <5 min.

From the GUI: Operations → Troubleshoot → Diagnostic Tools → TCP Dump. Pick the node (PSN under test), interface (typically Gi0), set a filter like host 10.20.5.50 and port 1812, click Start. ISE captures up to 10MB by default; download as pcap and open in Wireshark. From the CLI: tech dumptcp Gi0 file myfile.pcap filter "host 10.20.5.50". What you're looking for: RADIUS Access-Request landing (so the switch IS sending), Access-Accept going back, and the attributes inside. Common reveals: encrypted EAP payload (use the RADIUS shared secret to decrypt in Wireshark via edit → preferences → protocols → RADIUS); a missing CoA reply because firewall blocks UDP 1700.

A Support Bundle is a zipped archive of debug logs from a PSN/PAN/MnT node — Operations → Troubleshoot → Download Logs → Support Bundle. You generate one when escalating to TAC. Options: pick the date range (typically the hour around the incident), include core dumps + DB snapshots if requested. Output is ~500MB. You upload it to the TAC SR. Senior tip: don't generate Support Bundles preemptively (they overwrite older ones on the node); generate only when the incident is bracketed. Before going to TAC, run the Endpoint Debug for the impacted MAC — Operations → Troubleshoot → Endpoint Debug — this captures per-endpoint detailed logs that often answer the question without TAC.

The Primary PAN replicates configuration to every other node over Oracle DB replication (TCP 1521). "Not in Sync" means a node missed updates — clock skew (NTP drift >5 min), DB replication channel blocked by firewall, or the node was offline during a config change. Fix flow: (1) on the node, verify time: show clock + show ntp. (2) from PAN: Administration → System → Deployment → click the node → Manual Sync. (3) If that fails, deregister the node and re-add it (loses any node-local config). Watch for: if multiple nodes go Not in Sync at once, suspect the network between sites, not the nodes themselves.

Event = any log line MnT received (RADIUS auth success, profile change, AD lookup). High volume — millions per day in a big deployment. Alarm = an event that crosses a threshold of operational concern (disk > 80%, AD unreachable, certificate expiring in 30 days, node Not in Sync). Alarms appear at the top-right bell icon on every page. The senior move: configure Alarm Notifications (Administration → System → Settings → SMTP + Alarms) to email/SMS the network team for P1 alarms only, otherwise the team learns to ignore them.

The 10 columns: Time (when MnT received it), Status (green tick / red X / yellow), Details (the magnifying-glass icon — click to drill in), Identity (Username from EAP-Response-Identity, may be anonymized for outer-EAP), Endpoint ID (MAC), Endpoint Profile (from Profiler), Authentication Policy (which Policy Set rule matched), Authorization Profile (which AuthZ rule matched), Authorization Policy (the actual profile name), NAS IP Address (which switch). The two columns most candidates ignore: Endpoint Profile (tells you Profiler picked the right device type) and Authorization Profile (tells you the final result). Click the Details icon → modal expands with the full Steps trail of policy evaluation.

Cisco's mandated order: Secondary PAN → MnT-Secondary → PSNs (one at a time) → MnT-Primary → Primary PAN. Primary PAN goes last so the deployment retains a functioning policy authority throughout. Pre-upgrade prep: take an ISE Backup of the Primary PAN (Administration → System → Backup & Restore), validate trust certs are not expiring during the window, verify time sync, ensure no in-flight policy changes. Each PSN reboots ~30 min for the in-place upgrade — schedule it during a window when the surviving PSNs can absorb the RADIUS load. Use the GUI's Upgrade tile (3.x) to script this; older versions need manual application upgrade prepare + application upgrade per node.

Patch = bug fix or security fix to the same major.minor version. Cumulative — install latest, don't chain. Apply via Administration → System → Maintenance → Patch Management → Install. Node reboots; ~15 min downtime. Patches are also installed in Secondary first, Primary last order. Upgrade = move major.minor (3.2 → 3.3). Multi-hour, downtime per node, DB migration. Pre-upgrade health check (Operations → Reports → Audit → Compatibility) is mandatory. The senior detail: patches and upgrades together — you cannot install a patch from version 3.3 on a node still at 3.2; upgrade first, then patch.

Two backup types. Configuration backup — policy sets, AD join points, certs, endpoint identity groups, user accounts, system settings. ~50-500MB. Take from Primary PAN. Operational backup — MnT log database. Big (GB-TB scale). Take from Primary MnT separately. Restore: same node role, same hostname, same IP — restore overwrites the box. Cross-node restore (different hostname) requires the application reset-config trick + careful sequencing. Backup encryption is mandatory with a key you set on backup; lose the key, lose the backup. Senior reminder: ISE backups DO NOT capture endpoint cert private keys from the internal CA — those have their own export-on-create step.

Three tier names you must know: Essentials (formerly Base) — covers 802.1X, MAB, basic AuthZ, guest, BYOD. Advantage (formerly Plus) — adds posture, profiling, TrustSec, pxGrid. Premier (formerly Apex) — adds TC-NAC (Threat-Centric NAC), Compliance, third-party MDM integration. Plus a Device Admin (TACACS+) license, separate. ISE 3.x moved to Smart Licensing — register the deployment with Cisco Smart Software Manager (CSSM) or an on-prem Smart Software Manager satellite. Counts are by concurrent active endpoint sessions, not by user. Senior trap: when you renew, the Plus/Apex names change to Advantage/Premier — same features, new SKU.