TACACS+ Accounting and Audit Logs: How to Track Every Network Administrator Action

TACACS+ accounting is the third “A” in AAA (Authentication, Authorization, and Accounting): the function that records what a network administrator actually did, not just what they were permitted to do. It logs each privileged session and each individual command, with the username, source address, privilege level, and timestamp attached, and sends every record off-device to a central server. RADIUS accounting stops at session-level detail, and local syslog can be altered by the same administrator it is meant to audit, so among these three, per-command TACACS+ accounting is the one designed for administrator audit trails. To make it audit-ready: enable both exec and command accounting, synchronize device clocks, forward records to a SIEM, and protect them as compliance evidence.

Let’s take an example, what if something changed on a core router at 03:41, and now half a region is offline. Authentication tells you who could log in to that device. Authorization tells you what they were allowed to do. Neither answers the question your incident bridge needs answered: who logged in, what commands did they run, and when? That is the job of TACACS+ accounting- the third and most neglected component of the AAA framework, and the one built to give you a command-by-command audit trail of every administrator action on your network devices.

This article covers how TACACS+ accounting works, what an accounting record contains, how it compares to RADIUS accounting and syslog-only logging, how the new TLS 1.3 transport changes the security picture, and how to operationalize all of it: device configuration, security information and event management (SIEM) pipelines, retention, and compliance evidence.

What Is TACACS+ Accounting?

TACACS+ accounting is the AAA function that records what an administrator did on a network device – which commands ran, under which privilege level, from which source address, and when. Authentication and authorization decide what is permitted; accounting is the only one of the three that produces evidence after the fact.

The AAA framework describes three questions a network answers about privileged access:

1. Authentication: is this person who they claim to be?
2. Authorization: is this person allowed to do what they’re attempting?
3. Accounting: what did this person actually do, and when?

Most AAA discussions stop after the first two. But authentication and authorization are permission controls; accounting is the accountability control. Without it, you know your access policy – you just can’t prove what happened under it.

TACACS+ (Terminal Access Controller Access-Control System Plus), documented in RFC 8907, is the protocol purpose-built for device administration AAA. Three protocol characteristics matter specifically for accounting and audit integrity:

• All three AAA functions are separated into distinct packet types, so accounting operates independently: you can account for every command even in sessions where authorization decisions were made locally.
• The entire packet body is obfuscated, whereas RADIUS (Remote Authentication Dial-In User Service) masks only the password field – so accounting records don’t cross the network in cleartext. RFC 8907 is itself careful to call this mechanism obfuscation rather than encryption. Treat it as traffic masking rather than modern cryptographic protection, run TACACS+ over a secured management network.
• It runs over TCP port 49, giving accounting delivery a reliable, connection-oriented transport. A failed TCP session is a detectable event rather than a silently missing record.

In the request/response flow, accounting comes last: the administrator authenticates, the device authorizes the session or command, and then the device sends an accounting request to the TACACS+ server describing what happened. The server records it and acknowledges with a success or error status. That record, not the login prompt, is what your auditors will eventually ask for.

If you are weighing the protocols against each other more broadly, see how TACACS+ compares to RADIUS and Diameter.

What Gets Logged: Anatomy of a TACACS+ Accounting Record

RFC 8907 defines three accounting record types, signaled by flags in the accounting request:

• Start: a task has begun (a session opened, a command initiated).
• Stop: a task has ended, typically carrying elapsed time and completion status.
• Watchdog (update): an interim update record for long-lived tasks, so a session that dies mid-flight still leaves evidence of how long it ran and what it last reported.

TACACS+ accounting record fields

Each record carries the packet’s identifying fields (user, port, remote address) plus a set of attribute-value pairs. The exact set varies by device platform, but a typical command accounting record includes:

Field	Example	Why it matters for audit
user	jsmith	Ties the action to a named individual – the basis of non-repudiation (no one can credibly deny the action was theirs)
rem_addr	10.20.4.17	Where the administrator connected from
port	vty1	Which line/interface the session used
start_time / stop_time	1787283712	When it happened (epoch time – meaningless if device clocks aren’t synchronized)
task_id	4821	Correlates the Start and Stop records of the same task
service	shell	The service context (exec shell, PPP, etc.)
priv-lvl	15	The privilege level in effect – flags fully privileged activity
cmd / cmd-arg	shutdown	The actual command executed – the heart of command accounting
elapsed_time	1840	Session duration, from the Stop record

TACACS+ command accounting example

An annotated example, assembled from RFC 8907’s documented fields and attribute-value pairs (formatting varies by server implementation). Note that each command generates its own record:

Aug 21 03:41:52 10.1.1.5 jsmith vty1 10.20.4.17 stop task_id=4821 timezone=UTC service=shell priv-lvl=15 cmd=interface cmd-arg=GigabitEthernet0/1 Aug 21 03:41:57 10.1.1.5 jsmith vty1 10.20.4.17 stop task_id=4822 timezone=UTC service=shell priv-lvl=15 cmd=shutdown

Read that as: user jsmith, connecting from 10.20.4.17 on a privilege-15 session on device 10.1.1.5, entered an interface configuration context and shut the port down at 03:41. Each command is its own attributable record. Those two lines are the difference between an incident review that starts from a named user and an exact command, and one that starts from scratch.

Exec accounting vs command accounting

Two accounting scopes matter, and mature deployments enable both:

• Exec (session) accounting records that a shell session started and stopped – who logged in, from where, for how long.
• Command accounting records each individual command executed within the session, typically per privilege level. This is the capability that sets TACACS+ apart from the AAA and logging alternatives compared below: the audit trail is per action, not per session.

TACACS+ Accounting vs RADIUS Accounting vs Syslog-Only Logging

All three can loosely be called “logging,” but they answer different questions and offer very different integrity guarantees.

	TACACS+ accounting	RADIUS accounting	Syslog-only
Granularity	Per command and per session	Per session (start/stop/interim, bytes, duration)	Whatever the device chooses to emit
Designed for	Device administration audit	Network access and usage/billing	General event logging
Ties events to authenticated user	Yes – records generated by the AAA flow itself	Yes, at session level	Not inherently – depends on message content
Transport	TCP 49, reliable connection (TCP 300 with TLS 1.3)	UDP 1813, with application-layer acknowledgment and retry	UDP 514 typically; fire-and-forget unless TLS syslog is configured
In-transit protection	Full packet body obfuscated; TLS 1.3 available per RFC 9887	Not encrypted – individual attributes may be obscured, the record body is not	Cleartext unless TLS is configured
Tamper resistance	Records leave the device immediately for a central server the device administrator may not control	Central, session-level only	Local logs can be altered or disabled by the same administrator being audited; forwarding helps but lacks AAA correlation
Best for	Answering “who ran what command, when”	Answering “who was connected, for how long, using how much”	Supplementary operational context

The distinction that matters most for administrator accountability: RADIUS accounting was designed around network access sessions. It tells you a session existed and what it consumed – the right level of detail for subscriber billing and access tracking, but it says nothing about what changed on the device. Syslog can capture command events on some platforms, but a privileged administrator can typically alter or disable local logging on the very device they are changing: the administrator being audited controls the audit trail. TACACS+ command accounting exports each action off-device, as part of the AAA flow itself, to a server the device administrator does not control. Centrally stored, it is significantly harder to tamper with than local logs – though integrity ultimately depends on how you protect the accounting server and its storage, which is covered below.

Securing the Accounting Channel: TACACS+ over TLS 1.3 (RFC 9887)

TACACS+ obfuscation has been the protocol’s weakest point for its entire life, and accounting records are exactly the traffic you least want readable in transit – they contain usernames, source addresses, privilege levels, and full command strings.

RFC 9887, published as a Proposed Standard in December 2025, addresses this directly: it updates RFC 8907 to run TACACS+ over Transport Layer Security (TLS) 1.3, deprecating the original obfuscation mechanism in favor of certificate-based mutual authentication, with TCP port 300 assigned as the well-known port for secured connections.

What to do with that today:

• Treat obfuscation as a management-network assumption, not a control. Until TLS 1.3 is available across your estate, TACACS+ traffic – accounting included – belongs on an out-of-band or otherwise restricted management network.
• Ask your platform vendors where RFC 9887 sits on their roadmap. Support will arrive unevenly across device operating systems and AAA servers, and mixed-mode operation on ports 49 and 300 is the realistic interim state.
• Fold it into procurement now. If you are evaluating an AAA platform this year, the TLS 1.3 transport is a reasonable question to put on the requirements list rather than a retrofit to negotiate later.

How to Set Up TACACS+ Accounting in Practice

Configuration syntax differs by vendor, but the pattern is consistent across Cisco IOS/IOS-XE, Junos, PAN-OS, FortiOS, and AOS-CX. Consult your vendor’s current AAA documentation for exact commands; conceptually you will:

1. Define the TACACS+ server: its address, the shared secret, and TCP port 49 and confirm reachability from the device’s management interface.
2. Enable exec accounting: so session start/stop records are generated for administrative logins.
3. Enable command accounting for privileged levels: at minimum the highest privilege level (level 15 on Cisco-style platforms, or the equivalent superuser role), and ideally every level from which configuration changes are possible.
4. Send start and stop records: (the “start-stop” style) rather than stop-only, so long-running sessions are visible while they’re open, not only after they end.
5. Verify end to end: run a test command, then confirm the record arrives on the TACACS+ server with the correct username, command string, and timestamp.

Common pitfalls that undermine an otherwise correct setup

• Unsynchronized clocks. Accounting timestamps are audit evidence. If device clocks drift, your trail can’t be correlated with SIEM events or other systems. Synchronize every device via NTP (Network Time Protocol) before relying on accounting data – unsynchronized clocks are a recurring finding in access-control audits.
• Exec accounting without command accounting. Knowing a session occurred without knowing what happened inside it satisfies almost no audit requirement. Enable both.
• Underestimating volume. Command accounting on a large estate generates far more records than session accounting. Size the accounting server’s storage and your downstream pipeline for it, or records will be dropped just when activity and risk are highest.
• No fallback plan. Decide deliberately what a device should do if the TACACS+ server is unreachable. During an outage, device administration is the tool you need most, so your accounting design should assume it will be exercised under stress. This is also the question to put to any AAA vendor during evaluation: what does the device do when the server is unreachable, and can the fallback itself be audited?

Who changed the router configuration? A day-in-the-life example

An engineer applies an access control list (ACL) change during a maintenance window, and two hours later a monitoring alert fires. The on-call lead pulls the command accounting trail for that device and sees the exact ACL lines entered, the username, and a timestamp thirty seconds before the first alert. The review moves immediately from establishing who touched the device to fixing what they changed.

Feeding TACACS+ Accounting Logs into SIEM and Long-Term Audit Storage

Getting accounting records onto the TACACS+ server is only half the job. Device-side or single-server storage has three problems for audit purposes: retention limits, a single point of failure, and no correlation with events from the rest of your estate.

The operational pattern that closes those gaps:

1. Centralize immediately: Forward accounting records from the TACACS+ server to your SIEM or centralized log store as they arrive, so no record’s survival depends on one host.
2. Normalize the fields: Map user, device, command, privilege level, and timestamp into your SIEM’s schema so accounting events can be joined with authentication logs, change tickets, and network telemetry.
3. Set retention by the strictest applicable requirement: rather than a single comfortable default. Different frameworks impose different minimums, and the strictest one governs.
4. Alert on behavior, not just failures: Command accounting enables detection rules that session logs can’t support. A practical starting rule: flag any privilege-15 command accounting event outside approved change-window hours, on any device tagged as production core. Others worth building: configuration commands from an unrecognized source IP, unusually long privileged sessions, and command sequences associated with covering tracks (log manipulation attempts, AAA reconfiguration).

This is also where a centralized AAA platform earns its keep. Alepo builds the Alepo AAA Server, an authentication, authorization, and accounting platform for operators and enterprises that terminates TACACS+ alongside RADIUS and Diameter on a single stack- with command authorization, privileged access, and audit logging for network device administration, plus integration into the security stack. One pipeline for the whole estate instead of per-device log pulls.

For the wider picture of AAA as a network security control rather than a connectivity function, see how the AAA server secures networks.

Compliance and Governance Use Cases for TACACS+ Accounting

Command-level accounting maps onto the audit and accountability language of the major frameworks. Control numbering and wording change between editions, so verify against the current published standard before quoting it in an audit response.

• PCI DSS: requires logging and monitoring of access to system components in the cardholder data environment, with audit trails that link access to individual users and defined retention of audit history. For in-scope network devices, per-command accounting tied to named users is a direct fit for those logging requirements.
• SOX: change-control evidence: for infrastructure supporting financial reporting systems, command accounting provides the “who changed what, when” record that supports IT general controls testing.
• NIST SP 800-53: the Audit and Accountability (AU) control family calls for defined auditable events, audit record content sufficient to establish what occurred and who was involved, protection of audit information, and defined retention. Accounting records address the content requirements; your storage design addresses the protection ones.
• ISO/IEC 27001: the Annex A logging and monitoring controls expect activities, exceptions, and events to be logged, protected against tampering, and reviewed – privileged user activity specifically included.

The operating principle across all four: treat accounting logs as audit evidence, not debugging data. That means write-once or integrity-protected storage, restricted access – the administrators being audited should not be able to modify the audit trail – and documented retention.

In practice, an audit request looks like this: “Provide the record of all configuration changes to the in-scope firewalls between March 1 and March 31, with the individual who made each change.” With command accounting centralized, that’s a filtered query returning named users, exact commands, and timestamps. Without it, it’s a scramble through partial syslog archives and an uncomfortable meeting.

Conclusion: Accounting Turns Access Policy into Accountability

Authentication and authorization answer “who is allowed to do this.” Accounting answers the question that gets asked after an outage, a breach, or an audit letter: “who did this, and when?” Without command-level accounting, incident reviews run on interviews and guesswork, and compliance evidence is reconstructed instead of retrieved. With it, every privileged action on every device is a queryable, attributable record.

See how the Alepo AAA Server consolidates TACACS+ device-admin accounting with RADIUS and Diameter on one platform- book a demo now to see it live.

FAQs

Q1. What’s the difference between TACACS+ accounting and TACACS+ authorization?

Authorization is the decision before the action – may this user run this command? Accounting is the record after the action – this user ran this command at this time. Authorization enforces policy; accounting proves what happened. You need both: authorization without accounting leaves no evidence, and accounting without authorization records actions you never controlled.

Q2. Can TACACS+ accounting logs be tampered with or deleted by an administrator?

The design makes it much harder than local logging: records leave the device as part of the AAA flow and land on a central server the device administrator typically doesn’t control. But integrity ultimately depends on implementation. Protect the accounting server itself, restrict who can administer it, and store records in integrity-protected (write-once or hash-chained) storage. Treat “tamper-proof” as a property you earn through storage design, not something the protocol gives you for free.

Q3. Does TACACS+ accounting log failed commands, not just successful ones?

Accounting records what the device reports. A command denied by authorization is captured by the authorization exchange – and on many platforms can generate its own accounting or log event – while command accounting records the commands the session executed. For full coverage, log authorization failures alongside accounting records in your SIEM: failed attempts are often the more interesting security signal.

Q4. How long should TACACS+ accounting logs be retained?

Set retention by the strictest compliance requirement that applies to you; frameworks differ, and internal legal or security policy may exceed all of them. A common enterprise pattern is a year or more of retained history with recent months immediately searchable, but confirm against the current text of each standard in scope rather than adopting a default.

Q5. Is TACACS+ accounting alone enough for compliance, or do I still need a SIEM?

Accounting generates the evidence; it doesn’t review, correlate, protect, or retain it at scale. Frameworks generally require log review, alerting, and protected retention, which is SIEM and centralized-storage territory. Think of TACACS+ accounting as the authoritative source feeding that pipeline rather than a replacement for it.