Hardware is an indispensable tool in designing a robust, resilient, and future-proof network. However, hardware is not the beginning and end in itself. Designing a resilient network also involves a strategic alignment of identity services with business objectives.

Network access control is non-negotiable for enterprises managing thousands of endpoints across wired, wireless, and VPN connections. Cisco Identity Services Engine (ISE) addresses this challenge head-on by serving as the policy decision point in a zero-trust architecture for the workplace. It uses integrated intelligence from across the security stack to ensure continuous and trusted access.

Furthermore, ISE empowers administrators to define who can access the network, from what device, at what time, and from where. It achieves this by building detailed context around every endpoint, such as user identity, device type, access location, connection method, and current threat posture. That context enables data-driven policy decisions in real-time.

This guide walks you through every key decision an enterprise must make before and during an ISE deployment, such as deployment models, node personas, sizing guidelines, high availability, and best practices that separate a resilient production deployment from a fragile proof-of-concept.

How Cisco ISE Works: Architecture and Core Components

Understanding the ISE architecture is the first step toward a successful deployment. There are three principal building blocks: nodes and persona types, network resources, and endpoints.

A node is any individual physical or virtual Cisco ISE appliance. What makes ISE flexible is the concept of personas: the role a node plays within the deployment. Each node can assume one or more personas, and the combination of all the personas deployed determines what services the ISE cluster can deliver.

The Four ISE Node Personas

1. Policy Administration Node (PAN) The PAN serves as the central management interface for all ISE configurations. It handles authentication setup, authorization rules, audit logging, and system-wide policy synchronization. In a distributed deployment, you can have a maximum of two PANs, one primary and one secondary, for high availability. All administrative changes are made on the primary PAN and then replicated to the rest of the deployment.

2. Policy Service Node (PSN) The PSN is the workhorse of any ISE deployment. It handles network access, posture assessment, guest access, client provisioning, and device profiling. Every RADIUS authentication and authorization decision runs through a PSN. In larger environments, multiple PSNs can be grouped into node groups. If one node in a group fails, the other nodes detect the failure and automatically reset URL-redirected sessions.

3. Monitoring Node (MnT) The MnT functions as the log collector for the entire deployment. It aggregates and correlates data from all PANs and PSNs. Furthermore, it provides the monitoring and troubleshooting tools administrators use to investigate access issues. ISE supports a maximum of two MnT nodes in a deployment. The secondary MnT automatically assumes the primary role if the primary node becomes unavailable. Cisco strongly recommends dedicating MnT nodes to the monitoring function alone, rather than combining them with the PSN persona on the same appliance.

4. pxGrid Node The pxGrid node enables Cisco ISE to share context-sensitive session data with external platforms and partner systems. This is particularly relevant for zero-trust architectures, where ISE tags assigned to devices must be shared with tools like Cisco Secure Access to enforce consistent policies across users, IoT endpoints, and BYOD devices.

Cisco ISE Deployment Modes: Choosing the Right Model

The Cisco ISE Performance and Scalability Guide outlines three recognized deployment models, often referred to informally as small, medium, and large.

The session count is not the only factor driving this decision. The medium model becomes necessary when your organization requires persona separation. It means you require dedicated PSNs, a dedicated MnT, and redundant PANs rather than running everything on a single appliance. Redundancy and operational resilience are typically the more compelling reasons to move from small to medium, even when raw session volume does not demand it.

Standalone vs. Distributed Deployments

A standalone deployment runs all personas on a single node. This is appropriate only for lab environments or very small pilot networks. A distributed deployment assigns different personas to different nodes, which allows the cluster to scale, specialize, and survive individual node failures.

Split Deployments

For organizations with a primary data center and a secondary site, a split deployment places the primary PAN and MnT at one site and the secondary nodes at another. PSNs can be placed at each site to keep the authentication local. This design reduces WAN dependency for RADIUS transactions while maintaining centralized management.

Dispersed Network Deployments

Large enterprises with multiple geographically distributed sites require PSNs placed near the endpoints they serve. Authentication requests should not traverse a WAN link if a local PSN can serve them. For very large dispersed networks, load balancers in front of PSN pools are strongly recommended. When load balancers are present, the switch RADIUS configuration points to the load balancer's virtual IP address rather than individual PSN addresses.

Cisco ISE Sizing Guide: Matching Hardware to Your Environment

Selecting the right appliance or virtual machine size is one of the most crucial decisions in an ISE deployment. Undersized nodes create performance challenges during authentication, which directly impacts user experience and network availability.

The Cisco ISE Performance and Scalability Guide provides current sizing data for the SNS 3700 and SNS 3800 hardware appliance series, as well as equivalent virtual machine specifications. Key variables that drive sizing decisions include:

• Concurrent active sessions: The total number of endpoints authenticated at peak load

• Authentication transactions per second (TPS): How many new authentications must be processed each second, particularly relevant during morning login surges or network reconvergence events

• Enabled services: Profiling, posture assessment, and guest services each consume additional resources on PSNs

• Log volume: The MnT node must store and index logs from every PSN and PAN in the deployment

For PSN sizing, authentication rate data is crucial. A larger physical appliance processes significantly more authentications per second than a smaller one or a lightly-resourced virtual machine. Organizations that rely on aggressive posture checks or profiling feeds will require more PSN capacity than deployments using basic 802.1X only.

For MnT sizing, log retention requirements drive storage planning. Longer retention windows require more disk, and high-volume deployments generate logs rapidly.

Cisco ISE Sizing Best Practice: Always size for peak load, not average load. Network reconvergence events, such as a core switch restart or WAN outage recovery, can produce authentication bursts that are several times the steady-state rate. If the PSN cannot absorb these bursts, users experience access delays or failures precisely when the network needs to recover quickly.

Cisco ISE Deployment Best Practices

The Cisco ISE Secure Wired Access Prescriptive Deployment Guide provides detailed guidance on how to structure a production deployment. The following practices are essential for any enterprise rollout.

Use a Phased Deployment Approach

It is disruptive to enable port-based authentication across a wired network in a single step. The recommended approach uses three progressive modes:

Monitor Mode (Open Mode): Authentication is active. However, the port remains open regardless of the result. No access is denied. This phase builds visibility. Building visibility means you can see how many endpoints authenticate successfully, how many fail, and the reasons for the failure. It causes zero disruption to end users while you identify and resolve authentication issues before enforcement begins.

Low-Impact Mode: A pre-authentication access control list (ACL) limits what an unauthenticated endpoint can reach. Upon successful authentication, ISE pushes a downloadable ACL or VLAN assignment that grants appropriate access. This mode is well-suited for environments where devices need DHCP and DNS before completing authentication.

Closed Mode (Restricted Mode): The port blocks all traffic except 802.1X authentication exchanges until the endpoint authenticates successfully. This is the most secure mode and is appropriate for environments with mature endpoint management and well-tested authentication policies.

Separate Personas on Dedicated Nodes

Running the PSN and MnT personas on the same node degrades performance for both functions. High log volumes from a busy PSN can saturate the MnT node's processing capacity. Cisco's documentation explicitly recommends that MnT nodes be dedicated to the monitoring function in production environments.

Plan RADIUS Failover Carefully

Each access switch requires at least two RADIUS server entries : (1) pointing to two different PSNs, or (2) to load balancer virtual IPs. Configure dead-time parameters to prevent the switch from continuing to send authentication requests to an unresponsive PSN. A recommended configuration sets the dead-criteria time to 10 seconds with 3 failed attempts before marking a server dead, and a deadtime of 15 minutes before retry. Probe-based recovery allows the switch to restore a PSN to active status as soon as it becomes reachable again.

Use CA-Signed Certificates

Self-signed certificates on ISE nodes create certificate warnings for end users and complicate trust chain management across large deployments. For internal endpoints managed by Active Directory, an enterprise PKI is appropriate. For guest and BYOD portals visible to unmanaged devices, a publicly trusted certificate authority avoids unnecessary friction.

Enforce Periodic Accounting Updates

Without periodic RADIUS accounting updates, ISE session records can become stale. The recommended practice sends accounting updates every 2,880 minutes (two days). This keeps session data up-to-date in the ISE database, ensuring that changes in endpoint posture or authorization are reflected without a full re-authentication.

High Availability in Cisco ISE Deployments

High availability is not a feature added at the end of a deployment. Rather, it is a design principle built in from the beginning.

For the PAN, the primary-secondary pair ensures that administrative access and configuration changes remain available even if one node fails. Failover is not automatic for the PAN in all scenarios; administrators should understand the manual promotion procedure and practice it before it becomes necessary in a production incident.

For the MnT, automatic failover from primary to secondary occurs without administrator intervention when the primary node becomes unavailable. The secondary MnT continues to collect logs and provide monitoring visibility until the primary is restored.

For PSNs, high availability is achieved through redundancy. Access switches are configured with multiple PSNs, so if one PSN becomes unreachable, authentications fail over to the next available node. PSN node groups add an additional layer of session resilience, enabling surviving nodes to handle URL-redirect sessions that were originally tied to a failed node.

For very large deployments, hardware load balancers in front of PSN pools distribute authentication load and provide transparent failover. When load balancers are used, the switches see only the virtual IP address of the load balancer, which simplifies switch configuration and abstracts PSN pool changes from network device management.

Common Pitfalls to Avoid in ISE Deployments

Skipping Monitor Mode: Many deployments rush to enforcement before understanding the authentication landscape. This results in access disruptions for devices that fail authentication for reasons that could have been resolved quietly during a monitor mode phase.

Undersizing PSNs for peak load: Sizing for average load instead of burst load degrades authentication performance during reconvergence events, lowering reliability when it matters the most.

Combining PSN and MnT on the same node: It is acceptable in small deployments, but creates mutual performance degradation in medium and large environments.

Using self-signed certificates in production: This causes certificate errors on endpoints, complicates troubleshooting, and can block authentication in strict environments.

Neglecting RADIUS server dead-time configuration: Without proper dead-time settings, a failed PSN continues to receive authentication requests, adding latency before the switch fails over to a healthy node.

Not testing failover before production: PAN failover, PSN failover, and load balancer behavior should all be tested and documented before a deployment goes live.

(16) ISE Deployment Planning Checklist

Use this checklist before beginning your ISE deployment:

• Determine the deployment model (small, medium, large) based on session volume and redundancy requirements

• Decide whether to deploy on physical appliances (SNS series) or virtual machines

• Map persona assignments to specific nodes. Avoid combining PSN and MnT personas in medium or large deployments

• Plan high availability for PAN, MnT, and PSN tiers

• Identify whether load balancers are needed for PSN pools

• Size each node based on peak session count and TPS requirements

• Obtain CA-signed certificates before deployment. Do not use self-signed certificates in production

• Plan Active Directory integration and confirm domain connectivity, NTP synchronization, and required TCP/UDP ports

• Define a phased rollout beginning with Monitor Mode

• Document failover procedures and schedule a test before go-live

Conclusion

A well-planned ISE deployment provides  enterprises with granular, policy-driven control over every endpoint that touches the network. The decisions made during planning, such as deployment model, persona separation, node sizing, high availability design, etc., determine whether ISE becomes a reliable pillar of network security or a persistent source of operational pain.

The most effective deployments treat ISE not as a checkbox item but as a long-term investment in network visibility and access control. Start with Monitor Mode to build understanding before enforcement. Size for peak, not average. Dedicate nodes to their intended personas. And integrate ISE into the broader zero-trust strategy rather than deploying it in isolation.

If your organization is evaluating or expanding its ISE deployment, Securview's security engineering team can assess your current environment, recommend the right deployment model, and guide implementation from planning through production validation.

‍