In the last two posts, one ISE Device Admin policy set handled everything: an IOS XE router and a Cisco ASA firewall. Its condition was DEVICE:Device Type EQUALS All Device Types, so the help desk group got the same read-only access on the firewall as on the router.
Most teams don't want that. This post splits the policy by device type, so routers and firewalls get different rules:
- Put each device into a Device Type Network Device Group (NDG):
RoutersorFirewalls. - Add a FW-Device-Admin policy set that lets only the admin group onto firewalls.
- Fault: the router policy set used
EQUALS All Device Types, so once the router moved intoRoutersit matched nothing and fell into the Default policy set. Every login to it failed with 13036 Selected Shell Profile is DenyAccess.
I built this in my home lab with Cisco ISE 3.5.0.527, a Cisco IOS XE 17.18.2 router and a Cisco ASAv 9.24(1) firewall, managed over SSH from Linux jump hosts. All output is real. Addresses are documentation values, and secrets and passwords are placeholders.
The same idea works for RADIUS network access policy sets (wired switches vs wireless controllers). TACACS+ shows it most clearly because the result is "can this person log in to this box".
Topology
| Device | Role | Address | Device Type NDG |
|---|---|---|---|
| ise35 | Cisco ISE 3.5, Device Admin | 192.0.2.10 | n/a |
| core-rtr5 | Cisco IOS XE 17.18.2 router | 10.86.251.11 | All Device Types#Routers |
| edge-fw7 | Cisco ASAv 9.24(1) | 10.86.249.10 | All Device Types#Firewalls |

| User | ISE group | Router | Firewall |
|---|---|---|---|
| na-01 | NetOps-Admins | Full access | Full access |
| hd-11 | NetOps-Helpdesk | Read-only | No access |
Before: one policy set for everything
Here's an authorization for na-01 on the ASA before the change. The policy set is IOS-Device-Admin and the device type is the root, All Device Types:

Step 1: Create the Device Type groups
Go to Administration > Network Resources > Network Device Groups. Under All Device Types, add two children: Routers and Firewalls.
Then edit each network device and set its Device Type: core-rtr5 to Routers, edge-fw7 to Firewalls. A device can be in only one group per NDG type, so this moves it out of the root group.
Step 2: Add a firewall policy set
Under Work Centers > Device Administration > Device Admin Policy Sets, add FW-Device-Admin:
- Condition: DEVICE:Device Type EQUALS All Device Types#Firewalls
- Allowed protocols: Default Device Admin
- Authentication: default rule, All_User_ID_Stores
- Authorization:
| Rule | Condition | Command set | Shell profile |
|---|---|---|---|
| FW-NetOps-Admins | IdentityGroup NetOps-Admins | CS-Permit-All | IOS_Priv15 |
| Default | (none) | DenyAllCommands | Deny All Shell Profile |
There's no help desk rule, so hd-11 falls through to Default and gets denied.
I first added the set below the existing IOS-Device-Admin set, expecting the broad set to catch the firewall first. It didn't. na-01 on the ASA immediately matched FW-Device-Admin >> FW-NetOps-Admins. That was the first sign of the fault below: EQUALS All Device Types no longer matched anything.
Result on the firewall
na-01 still gets in at privilege 15:
User na-01 logged in to edge-fw7
edge-fw7# show curpriv
Username : na-01
Current privilege level : 15
Current Mode/s : P_PRIV
hd-11 is refused at login:
$ ssh hd-11@10.86.249.10
Permission denied, please try again.
ISE shows why. The password was fine (22037 Authentication Passed), but the authorization result in FW-Device-Admin was the Deny All Shell Profile:

That's what we wanted.
Fault: the router fell into the Default policy set
Next I tested hd-11 on the router, which should still have read-only access:
hd-11@10.86.251.11: Permission denied (publickey,keyboard-interactive,password).
In Live Logs the policy is Default >> Default, which is the Default policy set, not a rule inside IOS-Device-Admin. Failure reason 13036 Selected Shell Profile is DenyAccess. The device type now shows All Device Types#Routers:

The cause is the condition on the old set: Device Type EQUALS All Device Types. EQUALS compares the device's group path exactly. When the device was in the root group, the path was All Device Types and it matched. After the move, the path is All Device Types#Routers, and EQUALS All Device Types is false. The broad set didn't catch routers and firewalls as I'd expected. It caught nothing, and every router login fell through to the Default set, which denies everyone. na-01 would have been locked out too.
If you want a parent group to match its children, use CONTAINS or STARTS WITH on the Device Type path, or point each set at the specific child group.
Fix
I changed the router set's condition to DEVICE:Device Type EQUALS All Device Types#Routers. Now each set names exactly one group:

The 4 hits on the Default set are the failed router logins from the fault. hd-11 is back on the router with read-only access:
core-rtr5#show privilege
Current privilege level is 15
core-rtr5#show running-config
core-rtr5#show clock
*15:39:20.664 UTC Sat Oct 31 2026
(show running-config prints nothing because the CS-Helpdesk-Show command set denies it, as in the IOS XE post.) hd-11 is still refused on the firewall.
Checklist for splitting policy sets by device type
- Before you move devices into child NDGs, search your policy sets for
Device Type EQUALS All Device Types. Each one stops matching the devices you move. - Watch the Default policy set's hit count during the change. Any new hits mean something fell through.
- Put specific sets above broad ones. Use
STARTS WITHorCONTAINSfor a broad set that should catch a whole subtree. - Keep at least one admin session open while you change Device Admin policy.
- Give the Default policy set a deny result, so a mistake fails closed rather than open, and check its hits after every change.
Failure codes seen
| Code | Meaning here | Fix |
|---|---|---|
| 13036 Selected Shell Profile is DenyAccess (FW-Device-Admin >> Default) | User has no rule in the firewall set | Working as designed |
| 13036 with policy Default >> Default | Device matched no policy set | Fix the policy set condition or the device's NDG |
Related: AAA, TACACS+ and RADIUS for Device Administration, ISE Live Logs failure codes and Cisco ISE 3.5 Initial Setup.