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 Cisco ISE. Information included such as TLS & Software versions, our testing processes, how is it hardened, plus much more.

What ISE versions does this document support?

This document will focus on the current supported releases of ISE. Please reference our EOS/EOL page for more information. To ensure proper support and coverage, customers/partners should be moving to our current recommended releases of ISE 2.4 & ISE 2.6

Secure Development

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


Vulnerability Testing

As part of CSDL ISE undergoes vulnreability testing.  This involves both industry standard testing tools and custom testing targeted at the product functionality.  Some of the industry standard tools that are used:

  • IBM AppScan
  • Codenomicon
  • Retina
  • Nessus
  • SkipFish

When is testing completed?

Testing is completed on those releases where new features are released. Patch releases are not subjected to vulnerability testing as we do not introduce new features in patches. Instead we fix reported PSIRTs in patches.


ISE Hardening and Security Best Practices


Follow the same as in the Cisco Prime Infrastructure Admin Guidewherever 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 current patch levels.
  • Use of strong password policies for CLI and Web UI.  (complexity, expiry, history, etc.)
  • Differentiated access for admins, each with own account whether local or via external ID store.
  • Policy of least privileges
  • 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; LHS: Settings
  • Disable SSH for higher security, or per above, update access restrictions for SSH access.
  • Update pre-and post-banner config for admin
  • Implement 1.2 connection limit settings via CLI to set max TCP connections and TCP/UDP/ICMP rates.
  • 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 user services
  • Secure store used for backup files, support bundles, log files, and associated encryption keys.



Underlying Operating System (OS)

Customers do not have direct access to the OS.

Version Underlying OS
ISE 1.3 RHEL 6.4 x86_64 ADE-OS
ISE 1.4 RHEL 6.4 x86_64 ADE-OS
ISE 2.0 RHEL 6.4 x86_64 ADE-OS
ISE 2.0.1 RHEL 7.1 x86_64 ADE-OS
ISE 2.1 RHEL 7.1 x86_64 ADE-OS


Main 3rd Party Components

ISE 2.x

  • Apache Tomcat/8.0.23
  • Oracle Database 11g Enterprise Edition Release - 64bit Production


Ports Used in ISE

The Cisco ISE Ports Reference for each version of ISE details all of the network ports and their uses.


Connection and Rate Limiting

ISE has two independent types of network limits:

  • Connection Limits.
    • Limit TCP connections.
  • 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)

Please see the ISE Compatibility Guides for the specific TLS versions and cipher suites supported per version of the product.


Government Certifications

Global Certification GlobalCertifications_ISE_2016-05-31.png


Cisco FIPS 140 page lists ISE 2.6 as certified. PLease see associated documentation in the admin guide and release notes


Cryptographic modules are FIPS approved.  They undergo a self-test when initialized.

Product Cryptographic Acceleration Module Security Level Software
Certificate or Compliance Letter
Cisco Identity Services Engine (ISE) 2.6

Cisco ISE uses embedded Federal Information Processing Standard (FIPS) 140-2-validated cryptographic module, Cisco FIPS Object Module Version 6.2 (Certificate #2984). For details about the FIPS compliance claims, see Global Government Certifications.

FIPS Level 1 ISE 2.6 Compliance Letter


Common Criteria

Product PP Compliance Evaluation Assurance Level mage Completion
Cisco Identity Services Engine (ISE) 

collaborative Protection Profile for Network Devices Version 2.1

Extended Package for Authentication Servers Version 1.0

Network Device Protection Profile 2.6 2019.12.17


Certificate Date:  2019.12.17


The TOE includes the following options: Cisco Identity Services Engine Appliance 3515, Cisco Identity Services Engine Appliance 3595, Cisco Identity Services Engine Appliance 3615, Cisco Identity Services Engine Appliance 3655, Cisco Identity Services Engine Appliance 3695 and Cisco Identity Services Engine Virtual Machine (ISE-VM) on ESXi 6.7 running on UCSC-C220-M5SX.


  1. Visit the Common Criteria Portal
  2. Select “Certified Products” from the top tabs this will bring you to the following page:  
  3. Select:  “Download CSV”
  4. The xls spreadsheet you download – search for the following “Cisco Identity Services Engine”


EAL (Evaluation Assurance Level) is an aspect of Common Criteria evaluation.  Previously, EAL used to be categorized by numeric levels. The new EAL categorization is based on protection profiles.  We are certifying against the Network Device Protection Profile version 1.1 (NDPP 1.1).


We don't have  any existing special compliance effort planned towards the NERC standard.
Please reach out to Kevin Gagnon and Paul Forbes Bigbee on this request


US NIST SP 800-88 Compliance, included in the associated installation guides

PSIRT Issues and Vulnerabilities

ISE security issues are communicated through Cisco PSIRT.


Security / Separation of ISE Portals and ISE internal DB


How is information encrypted in ISE for local Identity Storage?

  • The UNIX/Linux passwords for ISE CLI admin and oracle are SHA-256 hashed since ISE 1.3. Prior to ISE 1.3 we used MD5 for hashing CLI passwords.
  • Oracle db users' passwords are in Oracle wallet
  • Since ISE 1.2 internal users' passwords are encrypted using block cipher mode CBC with AES algorithm and base64-encoded. Since ISE 1.4 use SHA-256 for hashing internal administrator passwords.  
  • Only the ISE CLI admin users' passwords in MD5 hash are viewable as part of ISE CLI running-config. The other files are not normally accessible.


How is the user database encrypted?

ISE has ID stores for ISE internal (aka NA) users, admin users, and guest users, which stored in Oracle db tables, but not user databases per se.
ISE 1.2+ has passwords encrypted using Block cipher mode (CBC) with the AES algorithm and then base64 encoded, before storing in the database. Please note that ISE admin users do not have direct accesses to the database in normal operations."

Does ISE use SALT?

Taken from Wikipedia, “… In cryptography, a salt is random data that is used as an additional input to a one-way function that "hashes" data, a password or passphrase. …


ISE does not always use salt. IIRC, the password of an internal admin users is using salt but not for the internal NA users. See Encryption for TACACS+ user passwords i... - Cisco Community

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.



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?

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