Showing results for 
Search instead for 
Did you mean: 

ISE Security Best Practices (Hardening)


What is covered in this document?

This document covers information regarding security, hardening and testing of Identity Services Engine (ISE). Information included such as TLS & Software versions, our testing processes, how is it hardened, upgraded paths, password policies, best practices and plus much more.

What Cisco ISE versions does this document support?

This document focuses on the current and latest supported ISE release versions below. Cisco ISE 2.7 version is the suggested/recommended release based on the software quality, stability, and longevity. To ensure proper support and coverage, customers/partners should be moving to our current recommended release of ISE 2.7.


Release Notes

ISE 2.6

ISE 2.6 Release Notes

ISE 2.7

ISE 2.7 Release Notes

ISE 3.0

ISE 3.0 Release Notes

What Cisco ISE versions are under EOS/EOL ?

Please refer to our EOS/EOL page for more information.

ISE Hardening and Security Best Practices


Follow the same as in the Cisco Prime Infrastructure Admin Guide wherever applicable. In summary, the underlying OS is based on Redhat Linux but access to underlying OS is not provided. Only required ports open, and rest closed through a firewall. Vulnerability testing is also performed. ISE follows the Cisco Secure Development Lifecycle (CSDL) process:

There is no official hardening document, use this as general guidance:

  • Upgrade to latest patch levels in each release.
  • Use of strong password policies for CLI, admin Web UI and Internal Users  (complexity, expiry, history, etc.).
  • Differentiated access for admins, each with own account whether local or via external ID store.
  • Create policies with least privileges for general access and provide highest privileges based on granular policies.
  • Do not use superadmin account for daily maintenance.
  • Restrict console access and admin web access by configuring the access restriction under Administration > System > Admin Access > Settings > Access > IP Access.
  • Restrict syslogs sent to MnT from deployment nodes only for enhanced security under Administration > System > Admin Access > Settings > Access > MnT Access.
  • Minimize the session Idle timeout for admin UI access.
  • Disable SSH for higher security, or per above, update access restrictions for SSH access. Use higher SSH encryption algorithms, encryption modes for enhanced security.
  • Update pre-and post-banner config for admin which is applicable for both UI & CLI.
  • Implement connection limit settings via CLI to set max TCP connections and TCP/UDP/ICMP rates as per your environment scale.
  • Configure ACLs that require ISE PSN access to specific ports (8443, 8905, etc, versus ip or tcp any any).
  • Enable FIPS to enforce higher security algorithms.
  • Review internal user accounts and disable those not in use.
  • Limit access returned for health probe accounts used by access devices and load balancers.
  • Deploy unique certs per node versus wildcard certs for higher security.
  • Deploy firewalls and other security devices that restrict access to nodes to required operational ports.
  • Use of offline updates for posture and agent files is more secure than live access which requires direct Internet access; firewalls and proxy as compensating controls.
  • Use separate, dedicated interfaces for management and services.
  • Enable scheduled backups during lesser load time or off-office hours for configuration and operational data at regular intervals.
  • Secure store used for backup files, support bundles, log files, and associated encryption keys.
  • Configure purging policies for your end devices inventory based on their inactivity, guest account types, registered devices..etc.
  • Minimize the period of keeping local log files.
  • Suppress Repeated Failed clients with recommended failure counts and also reject the RADIUS requests from clients with repeated failures to avoid processing load on authentication failed endpoints continuously. 
  • Suppress Repeated successful authentications to save the operational audit reports.
  • Enable “Detect high rate of RADIUS requests” to detect higher rate of RADIUS requests in your environment.

Password Policies

Cisco Identity Services Engine provides configuration of password policies for ISE admin users (UI/CLI) and ISE internal users. Cisco ISE already provides default configuration for password policies which enhances your security. Refer to Administration > Settings > Admin > password policies for ISE admin users’ password policies, account disable policies and lock/suspend settings and Administration > Identity management > settings > User authentication settings for ISE internal user’s password policies and Account disable policies. 

Disclose invalid usernames

It is recommended to disable “Disclose invalid usernames” for enhanced security. By default Cisco ISE is disabled to show invalid usernames in case of authentication failures. You can enable this settings to show invalid usernames during debugging scenarios for certain duration or always.

Connection and Rate Limiting

ISE has two independent types of network limits:

  • Connection Limits.
    • Limit TCP connections. Can be configured via CLI.
  • Rate Limits.
    • Limit packet rate to average number of packets per second.
    • Applied to TCP, UDP and ICMP.

Network Limit Notes:

  • Enhances security by limiting connections from known addresses
  • Mitigates DOS attacks by limiting connections and floods
    • Remote addresses may be spoofed so beware
  • Limits operate at the firewall (iptables) level
    • Not traffic shaping
    • No indication when limit reached

Public Key Infrastructure (PKI) and TLS versions support.

It is recommended that clients/servers negotiate to use a higher version of TLS for enhanced security. Please see the respective ISE Compatibility Guides for the specific TLS versions and cipher suites supported per version of the product.


Compatibility Guide

ISE 2.6

ISE 2.6 Compatibility Guide

ISE 2.7

ISE 2.7 Compatibility Guide

ISE 3.0

ISE 3.0 Compatibility Guide

How is information encrypted in ISE for local Identity Storage?

ISE has below user management in place.

  • ISE Admin users
  • ISE internal (a.k.a Network Access) Users
  • ISE CLI users

ISE admin and Internal Users stored in the Oracle database with below mechanisms for security. ISE CLI users are going to be stored in ADE-OS and is hashed for protection.

  • ISE command line interface passwords are hashed with SHA-256, salted and stretched.
  • ISE internal users are encrypted using Cipher Block Chaining (CBC) with AES algorithm and PKCS-5 padding mechanisms.
  • ISE administration web admin credentials stored locally in ISE are hashed with SHA-256, salted and stretched.
  • ISE stores passwords and passphrases in a database that is encrypted with Key Encryption Keys (KEKs) uniquely generated for each ISE deployment.

Does ISE use SALT?

ISE does not always use salt. IIRC, the password of an internal admin users is using salt but not for the internal NA users.

Upgrade paths:

You can upgrade to latest Cisco Identity Services Engine from your current Cisco ISE release versions. Here are the Paths available for you to upgrade to latest Cisco ISE release.


Upgrade from

ISE 2.6

ISE 2.1, 2.2, 2.3 or 2.4 Releases

ISE 2.7

ISE 2.2, 2.3, 2.4 or 2.6 Releases

ISE 3.0

ISE 2.4, 2.6, or 2.7 Releases

Refer to below upgrade guides for each release when you are upgrading to specific ISE versions.


Upgrade Guides

ISE 2.6

ISE 2.6 Upgrade guide

ISE 2.7

ISE 2.7 Upgrade guide

ISE 3.0

ISE 3.0 Upgrade guide

Secure Development

Cisco ISE follows the Cisco Secure Development Lifecycle (CSDL) Process.

Vulnerability Testing

As part of CSDL, ISE undergoes vulnerability testing.  This involves both industry standard testing tools and custom testing targeted at the product functionality.  Refer to vulnerability testing process as part of CSDL.

When is testing completed?

Cisco completes CSDL process testing and verification on all cisco ISE releases before making it available for customers. However, Patch releases doesn’t go through CSDL process as we do not introduce new features in patches. Instead we fix reported PSIRTs in patches as per the severity and impact.

Supported Protocols Standards, RFCs, and IETF Drafts

Cisco ISE conforms to the protocol standards, Requests for Comments (RFCs), and IETF drafts.

Ports Used in ISE

The Cisco ISE Ports Reference for each version of ISE, details all of the network ports and their purpose & usage. Refer to below table for the ports reference for each release.


Reference Link

ISE 2.6

Cisco ISE 2.6 Ports Reference

ISE 2.7

Cisco ISE 2.7 Ports Reference

ISE 3.0

Cisco ISE 3.0 Ports Reference


Cisco Employee

WOW. Nice Job putting this together Jason.



How is the user database encrypted?

"ISE 1.2 has passwords encrypted using Block cipher mode (CBC) with the AES algorithm and then base64 encoded, before storing in the database. ISE 1.1 has the same thing except using the ECB mode. Data fields other than passwords are not considered sensitive and not encrypted. Please note that ISE admin users do not have direct accesses to the database in normal operations."

How is the key used to encrypt/decrypt the passwords stored/secured?

Cisco Employee

I am not sure I understand the question.

AES symmetric cipher using CBC mode to make it a block symmetric cipher. CBC is more secure than ECB. The combination AES +CBC is used to encrypt the passwords.

AES uses different key sizes. The result of this is further base64 encoded to convert binary to ASCII and stored in the db. I am just interpreting what is provided in the ISE security best practices site.



Thanks Krishnan.  In order to decrypt the content stored in the database ISE needs to maintain a key and the IV (I believe).  Where and how is the key (or keys) protected which ISE uses to decrypt the encrypted passwords?

Cisco Employee

Hi Doug/Chris,

Do we know how and where we store the keys for AES+CBC used to encrypt passwords in the db?

There is a question from the community.

I wanted to respond “in a safe place”…☺. Well, that is not the answer I am looking for. Please see the email below.



Cisco Communities <>

ISE Security Best Practices (Hardening)

new comment by George Bekmezian<>

View all comments on this document<>

Cisco Employee

Please open up a TAC case if you are looking for further details.


Jeffrey Jones

how about an updated one for ISE versions 2.1 and 2.2

Community Member

We are looking for a more high level statement that we could provide to the customer .  A statement just stating we harden our OS in certain ways and don't open it up to customers to touch .  Also we address any issues on a per release basis .  Something like that.    Is there one and if not , who can we work with to write one up.


somewhat unrelated but I've disabled everything except TLS 1.2 in my ISE 2.3 environment via GUI however I still show TLS 1.1 and sometimes TLS 1 support enabled via an nmap scan. Is there a way to verify this via cli?

Jason Kunst
Cisco Employee

Please open a separate thread for this discussion

Cisco Employee

Your issue seems among those addressed in the upcoming ISE 2.4 so I would suggest you to join ISE 2.4 beta by going to to learn more.


Can anyone point me to some guidance on how to restrict SSH access to the ISE nodes from a select number of trusted networks? whilst the WebGUI can be configured to restrict access I can't see a way to easily restrict SSH other putting a firewall inline?

Cisco Employee

The IP restriction configuration in Web UI also imposes on SSH CLI access.

Rising star
Any chance the wording and information of this document can be updated for ISE 2.4/2.5, and kept updated in general for each major release? What was true a years ago may have changed, and even if it hasn't changed much it would be nice to know it's still relevant. For example the latest version in the document which refers to the ciphersuites in use is ISE 2.1. It's been awhile since it came out and perhaps certain ciphers are considered less secure and have been removed since from later versions of ISE, or added since. Another example is "In ISE 1.5 we plan to use SHA-256 for hashing internal administrator passwords." There never was an ISE 1.5, which means this block of text hasn't been updated since ISE 1.4 which came out nearly four years ago. Perhaps a stronger method is now in place for hashing internal administrator passwords such as SHA-3.

thanks for this post

Content for Community-Ad