Overview
- Privilege levels 0, 1 and 15 are a device feature, not an access model, which is how estates decay into “privilege 15 for everyone.”
- Per-command authorization is the fix: the device checks each command against central policy before running it, so a role becomes an explicit list of permitted commands.
- Copy the seven-role matrix below, scope each role by device group as well as by command, and design the server-unreachable failure mode deliberately.
Three months into the job, a tier-1 NOC (network operations center) operator logs into a core router to check an interface, holding the same access as the architect who designed the network. Not because anyone decided that. Because the device offers privilege 0, privilege 1, and privilege 15, the middle was never built out, and “just give them 15” unblocked a ticket one night and became policy by default.
When an auditor asks why, “that’s how the device works” is not an answer. TACACS+ privilege levels give you three usable tiers on most platforms; they are a device feature, not an access model, and the gap between the two is where most device-administration risk lives.
This guide closes that gap: what privilege levels give you, why per-command authorization is the mechanism that makes real roles possible, and the part nobody publishes- a seven-role access model you can copy, adapt in an afternoon, and defend in an audit.
Why network device privileges break down
Nobody designs their way into “privilege 15 for everyone.” Estates decay into it, and the decay follows the same four steps almost everywhere.
The three-bucket problem: levels 0, 1 and 15
Most network operating systems ship with three usable tiers: a near-empty level 0, a read-only level 1, and an all-powerful level 15. Three buckets cannot express a real team. A tier-2 operator who needs to bounce an interface does not fit in level 1, so they get 15. A contractor who only needs to read configs gets 15 too. The middle levels exist on paper; in most estates they sit empty.
How an estate reaches universal privilege 15 in four steps
- The incident exception: During an outage, someone needs config access they don’t have. They get it, correctly: restoring service comes first.
- The unrevoked exception: The outage ends. The access doesn’t. Nobody owns taking it back.
- The parity grant: The next hire asks for “the same access as” the person with the exception. Granting parity is easier than explaining the difference.
- The folklore boundary: Eighteen months on, who should have what is tribal knowledge. The written model, if one existed, no longer describes reality.
None of these steps is a mistake by the person taking it. The decay is structural, and it repeats until the access model stops depending on individual discipline. What stops it is a mechanism.
What are TACACS+ privilege levels?
TACACS+ privilege levels are numeric access tiers, 0 to 15, that a TACACS+ server assigns to determine which commands an administrator can run on a network device. Level 0 allows a handful of basic commands, level 1 gives read-only user mode, and level 15 grants full administrative control. Levels 2 to 14 are customizable but rarely used.
Cisco privilege levels: 0, 1 and 15 explained
Privilege levels are a Cisco IOS construct. Juniper Junos, Nokia SR OS and Aruba platforms each express administrative permissions in their own way, so confirm your own platform’s model before mapping roles onto it. On Cisco IOS it looks like this:
| Level | Default capability | Typical holder |
| 0 | Five basic commands (disable, enable, exit, help, logout) | Rarely assigned directly |
| 1 | User EXEC – a limited set of show commands, no config access | Default at login |
| 2–14 | Empty by default; commands must be assigned per level | Almost nobody in practice |
| 15 | Privileged EXEC – full configuration and administrative control | Administrators (in theory); everyone (in decayed estates) |
A TACACS+ server can assign these levels centrally at login, which already beats local accounts: one place to grant, one place to revoke.
Custom levels 2–14, and why almost nobody uses them
You can populate the middle levels by assigning individual commands to each level, per platform and often per device family. That is the problem: the assignments live in device configuration, drift between vendors and OS versions, and must be replicated estate-wide every time a role changes. Custom levels are technically available and operationally miserable to maintain, so the industry skipped them and jumped from 1 to 15. The fix is not better levels. It is moving the decision off the device.
Per-command authorization: the mechanism that makes roles real
If three buckets can’t express seven roles, what can?
Per-command authorization is a TACACS+ capability that checks every individual command an administrator enters against a central policy before the device runs it. Rather than granting a broad privilege level at login, the device asks the TACACS+ server about each command in turn, so a role can be defined as an explicit list of permitted commands.
Privilege levels are a device feature. Roles are an organizational design. TACACS+ per-command authorization is the mechanism that connects the two.
How a command authorization request is evaluated
When an engineer types a command, the device sends an authorization request naming the user, the device, and the command with its arguments. The server evaluates it against policy who is this, what role do they hold, what is this device, is the command on the role’s permitted list and returns permit or deny. The device enforces the answer. The exchange is defined in RFC 8907; a companion update, RFC 9887, modernized the transport with TLS 1.3 in December 2025.
One trade-off should be named plainly: per-command authorization adds a round trip to the server for each command. On a LAN this is invisible. On high-latency links to remote sites it is a real design consideration, and one reason server placement and redundancy are part of the role design rather than an afterthought.
Command sets and shell profiles
Policy is expressed in two building blocks. A shell profile sets the session context at login, including the privilege level the device sees. A command set is the explicit list of commands (with argument patterns) a role may run. The shell profile gets the engineer onto the device; the command set decides what they can do once there.
Where the policy lives: centrally, not on the device
This is the property custom privilege levels never had. The role definition lives on the server, once. Change the command set, and every device on the estate enforces the new definition on the next command. No per-device configuration, no drift, no folklore.
A seven-role model for network device access
Here is the model. Most network teams need between five and eight roles; seven covers the common shapes:
- Read-only monitoring
- Operational
- Change
- Platform
- Field technician
- Contractor / vendor support
- Automation service account
| Role | Typical holder | Should be able to | Must not be able to | Maps to |
| Read-only monitoring | Tier-1 NOC, dashboards | show output, interface status | Anything in config mode | NIST SP 800-53 AC-6, CIS Control 6, PCI DSS Req. 7 |
| Operational | Tier-2 NOC | Interface bounce, clear counters, scoped show run | Routing protocol config, ACL (access control list) edits | AC-6(1) |
| Change | Tier-3 / senior engineer | Full config within change window | AAA config, user management | AC-6(2), AC-5 |
| Platform | Network architect | Full config including AAA | Deleting accounting records | AC-6(5) |
| Field technician | On-site installer | Local port and PoE (Power over Ethernet) operations on access layer only | Anything at core or aggregation | AC-6, device scoping |
| Contractor / vendor support | Third party | Time-bounded, device-scoped, read-first | Persistent access, config mode by default | AC-2(2) |
| Automation service account | Ansible, backup, monitoring | A fixed, enumerated command list | Interactive login, anything not on the list | AC-2(9) |
Control references are indicative starting points for your own mapping exercise, not a compliance certification. Confirm the control set that applies to your scope with your auditor.
The separation between Change and Platform is deliberate: the person making routine changes cannot modify the AAA (Authentication, Authorization, and Accounting) configuration itself, and nobody can erase the audit trail of their own session. That is separation of duties applied to the CLI (command-line interface), and it is the first thing auditors look for in the matrix. It is also how you stop privilege escalation on network devices – when no role can widen its own access or delete the record of having tried, escalation needs a second person rather than a second command.
How to adapt it to your estate
Rename the roles to match your org chart, then adjust command sets, not role count. Fewer than five roles and you are back to buckets; more than eight and the model stops being maintained. Scope each role by device group as well as by command: a field technician role that is correct on an access switch is wrong on a core router. Alepo’s TACACS+ implementation supports centralized per-command authorization with multi-realm and multi-domain scoping, so one server can carry separate networks, or separate operating companies, as distinct realms.
Roles for automation and service accounts
The commonest hidden privilege-15 account in any estate is not a person. Ansible runs as somebody. The config-backup collector and the monitoring poller run as somebody. Usually that somebody has full access and a password unrotated since deployment. Give each automation identity its own role with an enumerated command list and no interactive shell. When a tool is compromised or simply misconfigured, the blast radius is the list, not the estate.
What happens when the TACACS+ server is unreachable?
The objection that stalls deployments deserves a direct answer: you design the failure mode, and each option has a cost.
| Fallback option | What it gives you | The trade-off |
| Local fallback account per device | Guaranteed last-resort access | Must be vaulted, rotated, and alarmed on use – if it becomes routine, the role model is gone |
| Second server, same site | Survives a server failure | Does not survive a site or WAN failure |
| Geo-redundant active-active servers | Authorization keeps answering through a site loss | More infrastructure; policy must replicate |
| Fail-open (permit all when unreachable) | Nobody is ever locked out | Indefensible in an audit; the outage becomes an access-control hole |
| Fail-closed (deny all when unreachable) | Safest on paper | Locks engineers out during an outage – exactly when they need the devices most |
Device administration is the tool you need most during a network outage, when engineers must reach devices fast over degraded paths. That is not a reason to avoid centralized control; it is the reason the server layer must be engineered for availability. In practice: geo-redundant, active-active deployment – the pattern Alepo implements for carrier estates – a vaulted and alarmed local fallback account, and a break-glass procedure that gets tested, not assumed.
To get the more information in details, you can also download the TACACS+ datasheet.
Proving least privilege to an auditor
Least privilege is a claim; the role model is the evidence. When an auditor asks how device access is controlled, the answer is the matrix above plus the accounting trail behind it. NIST SP 800-53 AC-6 and AC-2, CIS Critical Security Controls v8 Control 6, and PCI DSS v4.0 Requirement 7 are all evidenced by the same artifact: a documented mapping from role to permitted commands, enforced centrally, with per-command accounting records to prove it held. Readers outside North America can map the same evidence to ISO/IEC 27001:2022 Annex A 5.15 and 5.18.
The accounting side matters as much as the authorization side. Each record should carry who, which device, which command, and when, retained where no administrator role can delete it – individual accountability, the property shared accounts can never provide. How that evidence is protected sits within Alepo’s wider security posture.
Where this sits alongside subscriber access
TACACS+ governs the engineers who run the network. Subscriber and user authentication is RADIUS’s job, and the split looks like this:
| TACACS+ | RADIUS | |
| Who it controls | Network administrators | Subscribers, users, devices |
| Transport | TCP port 49 | UDP 1812/1813 |
| AAA separation | Authentication, authorization, accounting fully separated | Authentication and authorization combined |
| Authorization granularity | Per command | Per session |
| Where it fits | Device administration | Network access |
Also Read: How TACACS+ Compares to RADIUS for Network Authentication
Walk through a NOC operator session, a contractor session and a flagged escalation attempt on your own device types with the Alepo TACACS+ Server. Book a Demo and see per-command authorization applied to a real role model.
Frequently asked questions
Q1. What is the difference between privilege level 1 and privilege level 15?
Privilege level 1 is read-only user mode: a limited set of show commands and no configuration access. Privilege level 15 is full administrative control, including configuration mode. Neither expresses a real job role. Level 1 is too little for most operational work and level 15 is too much for almost everyone, which is why estates need command-level roles instead.
Q2. Is TACACS+ role-based access control the same as RBAC in identity management?
No, same principle, different enforcement point. IAM (identity and access management) RBAC governs access to applications and data through an identity platform. TACACS+ role-based access governs the network device CLI, enforcing roles as command sets when a command is entered. They complement each other: the directory defines who holds a role; TACACS+ enforces what the role can run.
Q3. How do I give someone read-only access to a router?
Assign a read-only role enforced by a TACACS+ command set that permits show commands and nothing else. Privilege level 1 alone is not enough: default level-1 access varies by platform, can leak more than expected, and cannot be tightened centrally. A command set states exactly what read-only means and applies it estate-wide.
Q4. What happens if the TACACS+ server goes down?
Whatever failure mode you designed. The options are local fallback accounts (vaulted and alarmed), fail-open, fail-closed, or server redundancy. Fail-open defeats the model and fail-closed locks engineers out mid-outage, so the sound design is a geo-redundant active-active server pair with a break-glass local account as a tested last resort.
Q5. How many roles should a network team define?
Five to eight. Fewer and you are back to the three-bucket problem, with people over-privileged because no role fits. More and the model outgrows the team’s ability to maintain it, which is how decay starts. Start from the seven-role matrix above, rename to fit your org, and resist single-person roles.
Q6. Can TACACS+ restrict access by device as well as by command?
Yes. Authorization policy can scope a role to device groups, so a field technician role applies at the access layer and nowhere else. Multi-realm and multi-domain support extends this, letting one server carry separate networks or operating companies as distinct realms.
Q7. How do I handle contractor access to network devices?
Time-bounded, device-scoped, and read-first. Grant a contractor role limited to the specific device group in scope, defaulting to read-only with config access added only for the change window, and revoked centrally when the engagement ends. Central revocation is the point: no hunting for local accounts a vendor left behind.
Q8. Do automation tools need their own TACACS+ role?
Yes: each automation identity gets a role with a fixed, enumerated command list and no interactive login. Ansible, config-backup collectors and monitoring pollers are the commonest hidden privilege-15 accounts in any estate. An enumerated command set caps the blast radius if the tool’s credentials are compromised or its playbooks misfire.
