On this page
01 What an audit trail for network changes records
An audit trail for network changes lets someone who was not present reconstruct a change afterwards. It holds five facts: who made the change, when, from which address or console, the exact commands, and the configuration before and after. The ticket adds the reason.
Most networks have parts of this: device login logs, a command list on the AAA server, a nightly config backup. They are rarely joined; the joining is the work. This page, part of the network-layer authenticity reference section, covers the four sources, the key that links them, and the record needed for changes drafted by automation or a model.
02 The four sources and what each contributes
AAA command accounting. A device authenticating against TACACS+ or RADIUS can also send an accounting record per session and, with TACACS+, per command. RFC 8907 defines TACACS+ accounting as START, STOP and WATCHDOG records with arguments such as task_id, priv-lvl and cmd. RFC 2866 defines RADIUS Accounting as Start and Stop packets keyed by Acct-Session-Id; they describe the session, not the commands in it. The AAA server, which the operator does not administer, writes the record, and that gives it weight.
Device change logging. Every platform writes syslog lines on login, configuration mode entry and, on most, each command. It is the most detailed source and the least trustworthy, because the device being changed produces and stores it. It joins the trail once it reaches a collector.
Config archive with version history. A system pulls the running and startup configuration on a schedule and after every change event, and records a hash and a timestamp per version. The archive turns "something changed" into a diff. RANCID-style tools did this with files under version control; what matters is that every version is kept, hashed and unwritable from the device.
Change tickets. The ticket holds intent: what was meant to change, who asked, who approved, the window. Alone it proves nothing about what happened; joined to the other three, it explains them.
03 Why a device-only audit trail is not evidence
A device's local log buffer is volatile, small and overwritten in a ring. It is also controlled by anyone privileged enough to make the change under investigation: an operator in configuration mode can clear the log, set the clock or disable logging. A record the subject of an inquiry could have altered does not settle it.
NIST SP 800-92, the Guide to Computer Security Log Management, makes the point: logs must move to a separate, protected system, with integrity controls and retention set by policy. NIST SP 800-53 Rev. 5 states the same as controls: AU-9 protects audit information from modification and deletion; AU-10, non-repudiation, ties an action to an identity that cannot later deny it. The config archive follows the same rule, each version written once to a separate system and hashed on arrival, as in the tamper-evident log handling described for edge records.
04 An authorship record for automation and AI-assisted changes
When a script, an orchestration tool or a model-assisted workflow makes the change, the accounting record shows a service account, not a human. The trail then needs an authorship record with four fields: who ran the tool, what it proposed (the candidate diff, stored as its own hashed artefact), who approved it, and what it pushed. Proposal and push are not always identical, and the difference is what a review asks about.
In practice the tool writes its proposal to the archive as a pending version, tagged with ticket, operator and approver, before anything reaches a device. The push carries the ticket ID so the accounting server can join it. If a model drafted the change, store the request summary with the proposal; it is part of the authorship. The review procedure for AI-assisted changes covers what an approver checks before signing.
05 Comparing the sources
| Source | What it proves | What it misses | Who controls it |
|---|---|---|---|
| Device syslog | Command sequence, local timestamps | Anything after the buffer wraps or is cleared; identity without AAA | The device, anyone with enable |
| AAA command accounting | A named identity, from an address, sent a command at a time | The result and the config state; RADIUS sees sessions only | The AAA server team |
| Config archive | Before and after state, hash per version | Who made the change, unless pulls are event-triggered | The backup system |
| Change ticket | Intent, approval, window | What actually happened on the device | The service desk |
06 Worked example: reconstructing one change
Distribution switch dsw-02.example.net at 192.0.2.12 lost VLAN 40 at 03:14 UTC. Nobody on call claimed it. The TACACS+ log showed a session from 198.51.100.7, user jsmith, from 03:11:52 UTC, with command records for configure terminal, no vlan 40 and write memory ending 03:14:05. The address was the automation host, and the session carried ticket=CHG-4471 set by the tool. The archive, pulling on every accounting STOP, held a version from 03:14:20 whose hash differed from the 02:00 pull.
2026-09-22T03:13:58Z 192.0.2.12 jsmith tty2 198.51.100.7 stop task_id=4183 priv-lvl=15 cmd=no vlan 40 ticket=CHG-4471 $ git log --oneline -2 -- devices/dsw-02.example.net/running.cfg 9f21c3a 2026-09-22T03:14:20Z dsw-02 pull on acct stop 4183 sha256=7d0c...e41a b6e0d12 2026-09-22T02:00:03Z dsw-02 scheduled pull sha256=41ab...9c02 $ git diff b6e0d12 9f21c3a -- devices/dsw-02.example.net/running.cfg -vlan 40 name guest-wifi by port - tagged ethe 1/1/47 to 1/1/48
Ticket CHG-4471 was an approved decommission of the guest VLAN, scheduled for the following week. The pending proposal matched the pushed diff; the approval was present. The fault was the schedule field: the tool read the approval date as the execution date. The trail answered who, when, from where, what and why in ten minutes. The diff syntax is IronWare; the reference of IronWare configuration commands shows the same VLAN stanza, with show running-config as the pull target.
07 Building the audit trail
Enable AAA with command accounting
Configure TACACS+ authentication and per-command accounting on every device at all privilege levels, including commands that clear logs or reload. Where only RADIUS exists, enable session accounting per RFC 2866 and take commands from the device log.
Forward device logs off the box
Send syslog to a collector over TLS; only the collector's copy is in the trail. Sync every clock to the same NTP sources.
Run a config archive with version history
Pull running and startup configuration on a schedule and on every accounting STOP for a configuration session. Store each version with hash and timestamp, outside the network team's write path.
Carry one join key through every source
Issue a ticket ID before work starts and require it in the session (a login prompt, a tool-set argument or a comment in the change) and in the archive commit. Without it, reconstruction is a search by time window, which fails when changes overlap.
Record authorship for automated changes
Have every tool write its proposal to the archive as a pending version with operator, approver, ticket and, where a model drafted it, the request summary, before pushing. Push under a credential naming the tool.
Test reconstruction, then set retention
Each month reconstruct one random change without asking whoever made it, and fix any missing link. Set retention by policy, per SP 800-92.
08 Pitfalls: clocks, shared accounts, silent gaps
- Unsynchronised clocks. Without the ticket key, the join is by time. A device five minutes off NTP puts its commands in the wrong order against the AAA server. Treat drift as a trail failure.
- Shared accounts without a session key. A record that says
netopschanged the config at 03:14 names nobody. Individual accounts for people; a ticket argument for tools. - A backup that only runs nightly. Two changes between pulls collapse into one diff. Pull on every configuration session STOP too.
- A silent collector. A device that has sent nothing for its expected interval has a stopped trail. Alert on absence, not only errors.
The trail rests on two other records described in this lane: syslog collected over TLS into append-only storage supplies the device side of every entry, and a signed configuration bundle that carries the approver's identity is how the authorship record travels with the change itself.
09 Questions
What is the difference between TACACS+ and RADIUS accounting for an audit trail?
RFC 8907 TACACS+ accounting records each command with its arguments, so the trail contains what was typed. RFC 2866 RADIUS Accounting records only the start and stop of a session under an Acct-Session-Id, so with RADIUS the command detail must come from the device log.
Is the device log enough if I forward it to a syslog server?
Forwarding fixes volatility and deletion, since the collector's copy survives a cleared buffer. It does not fix identity: a device that authenticates locally logs an account several people may share. Forwarded logs, AAA accounting and a hashed archive together are the minimum.
How often should the config archive pull?
Daily at least, and on every event that shows a configuration session ended, such as a TACACS+ STOP record for a session that entered configuration mode or a config-change trap from the vendor MIB. Event-triggered pulls keep two changes in one night from merging into one diff.
How do I record a change that a model drafted and a human approved?
Store the proposal as its own hashed artefact before the push, with the operator who ran the tool, the approver, the ticket ID and a summary of the request to the model. Push under a credential naming the tool. The accounting record shows the tool; the archive shows the humans.
What retention period is right for a network audit trail?
Set it by policy, not by disk. NIST SP 800-92 recommends deriving retention from legal, regulatory and operational needs and protecting stored logs for that period. A year is a common floor for accounting records; config versions are small and kept for the device's life.
An audit trail for network changes is four sources and one key. Turn on command accounting, move logs off the device, keep every config version with a hash, and put the ticket ID into all three. Then extend the record to the tools, so a change drafted by automation or a model has a named operator, a stored proposal and an approver.