Thanks for the input, Marvin!   I was able to confirm that the secondary device was defined as a network access device in ISE.   I was able to resolve the issue. Here's what I had to do in order to resolve both issues:   Issue 1:   Not able to access(no authorization)  the secondary device via SSH using the standby ip address (10.1.153.117) using the local account. Resolution: It turned out that I was missing the fallback method under the aaa configuration "aaa authorization command ISE", so I had to remove this statement and add this one " aaa authorization command ISE LOCAL" --- Issue resolved   Issue 2: Not able to access the secondary device via SSH using the standby IP address (10.1.153.117) using the AD/tacacs+ account.  Resolution: I found out that the primary management interface (10.1.153.116) was communicating with aaa-server/ISE servers   aaa-server ISE (inside) host 10.1.53.25 aaa-server ISE (inside) host 10.1.53.26)   through the inside interface and that's why the AD/admin accounts were able to SSH to the primary unit but not the standby unit. Since the management standby IP address (10.1.153.117) had no path (active interface on the standby unit) to communicate with the aaa-servers/ISE, then ssh access was failing. So, the solution was to either use the local admin account to ssh to the standby unit, which was successful; or to replace the secondary aaa-server to use the MGMT interface, which was also successful.   aaa-server ISE (inside) host 10.1.53.25 aaa-server ISE (management host 10.1.53.26   Issue 3: Not being able to access the standby unit using ASDM Resolution: After correcting the access use described above, I issued the dir disk0: on the standby unit and the output showed that the correct asdm.bin was missing, so I simply copied the file using TFTP from the primary unit. Here's the command I used: "failover exec mate copy /noconfirm tftp://10.1.22.87/asdm-7101.bin disk0:/"   Thanks again for your  input.   Best, ~zK ... View more