# The admin left. Their account on the core switch didn’t

> What PS-4, PS-5 and PS-7 in SP 800-53 mean for local accounts, shared secrets and MSP engineers on network devices, and what evidence shows a departure was handled.

**Compliance** · 2026-09-29 · 6 min read · By Beyrak A., Founder & Security/System Engineer

**Key takeaways**

- PS-4 asks you to disable access and revoke “any authenticators and credentials associated with the individual”. On network gear, many of those live on the devices, not in the directory.
- Shared accounts are covered in so many words: AC-2 item k and IA-5 item i want their passwords changed when someone leaves. Rotating SNMP communities, AAA keys and pre-shared keys the same way is a reading of PS-4, not a line NIST wrote.
- The evidence is per device: a snapshot after the leave date with no local account for that person, and no change made under their account since.

## What PS-4 asks when someone leaves

When an engineer leaves, the directory account is usually disabled the same afternoon. That covers the VPN, the wiki and, if your devices authenticate through TACACS+ or RADIUS, most of the network. It doesn’t cover the local account created on a core switch during an outage three years ago, or the enable secret they typed a thousand times.

SP 800-53 Rev. 5 puts the requirement in PS-4, personnel termination. On termination you “Disable system access within” a period you define, and “Terminate or revoke any authenticators and credentials associated with the individual.” The discussion adds a practical note: “In certain situations, organizations consider disabling the system accounts of individuals who are being terminated prior to the individuals being notified.” AC-2 connects the two processes directly. Its last item asks you to “Align account management processes with personnel termination and transfer processes.”

The word that matters for network teams is “any”. The directory account is one credential. The rest are spread across devices, and nobody gets an HR ticket for them.

## Transfers and MSP engineers count too

Leaving the company isn’t the only trigger. PS-5 covers people who move to another role: “Review and confirm ongoing operational need for current logical and physical access authorizations”, then “Modify access authorization as needed.” A network engineer who moves to the application team keeps knowing the break-glass password unless someone decides otherwise.

PS-7 covers external personnel, and its discussion lists “network/security management” among the services external providers deliver. If an MSP runs part of your network, you’re expected to require the provider to notify you “of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges”, within a period you set, and to “Monitor provider compliance with personnel security requirements.” In practice that means knowing which accounts on your devices belong to the provider’s engineers, and checking them when the provider tells you someone left, or when it forgets to.

## Where the credentials actually live

Before you can revoke credentials, you need the list. On a typical multi-vendor network it looks like this, and the split that matters is personal versus shared.

*Example: credentials on network gear, on departure*

| credential | lives on | kind | on departure |
|---|---|---|---|
| local admin account | every device | personal | remove everywhere |
| API key or token | firewall, controller | personal | revoke |
| personal certificate | PKI, VPN gateway | personal | revoke |
| break-glass account | every device | shared | change password |
| enable or root secret | every device | shared | change |
| SNMP community or user | every device | shared | rotate if known |
| TACACS+ or RADIUS key | device, AAA server | shared | rotate if known |
| VPN pre-shared key | VPN peers | shared | rotate if known |

Personal credentials get removed. Shared ones stay in place, but the secret changes if the person knew it.

Personal credentials are the straightforward part: delete the account on every device, revoke the key, revoke the certificate. Shared credentials are harder, because the account stays and only the secret changes. For shared admin accounts, NIST says it in so many words. AC-2 item k asks for “a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group”, and IA-5 item i repeats it: “Changing authenticators for group or role accounts when membership to those accounts changes.”

For secrets that aren’t accounts, such as SNMP communities, TACACS+ and RADIUS keys, and VPN pre-shared keys, NIST doesn’t name them. Rotating them when someone who knew them leaves is our reading of “credentials associated with the individual” in PS-4b, backed by the same logic as IA-5 item i. It’s a defensible reading, but write it into your procedure as your decision rather than presenting it as a quote. The cheaper fix is upstream: IA-2(5) asks you to “require users to be individually authenticated before granting access to the shared accounts or resources”. The fewer people who ever see a shared secret, the fewer rotations a departure triggers.

Break-glass accounts need one more note. The AC-2 discussion says local accounts kept for when network resources are unavailable, which it calls “accounts of last resort”, “remain available and are not subject to automatic disabling or removal dates.” The account stays. That doesn’t exempt its password: if the person who left knew it, it’s a shared authenticator and AC-2 item k applies.

## Local accounts are the ones that get missed

Local accounts pile up for ordinary reasons: a fallback for when the AAA server is down, a fix during an outage, a vendor engineer who needed access for a day, an automation job that predates the service account. Each one was reasonable when it was made. None of them is in the directory, so disabling the directory account doesn’t touch them.

AC-2(3) is the enhancement that catches them. It asks you to disable accounts within a period you define when they “Are no longer associated with a user or individual”, among other conditions. Its inactivity condition, disabling accounts that “Have been inactive for” a set period, needs login data, which lives in logs and on the AAA server rather than in the configuration. AC-6(7) adds the periodic check: “Review” the privileges assigned to the roles you choose “to validate the need for such privileges”, and remove them if the need is gone.

*Example: leaver sweep, jdoe, left 2026-08-14*

| device | local account | removed | note |
|---|---|---|---|
| core-sw-01 | jdoe | 2026-08-14 | by asmith |
| pan-fw-01 | jdoe | 2026-08-15 | by asmith |
| n9k-leaf-07 | jdoe | not removed | still present |
| fgt-branch-03 | jdoe | not removed | still present, used 08-21 |

- after leave: 08-21 fgt-branch-03, address group vpn-users edited
- attributed to: jdoe (matched by time window)

The directory account went on the leave date and two devices were cleaned up. Two weren’t, and one of them took a change under the departed engineer’s account a week later.

The last line is the one that matters. A change made under a departed person’s account after their leave date is either a colleague borrowing a known password or someone who shouldn’t have access. Either way it goes to incident response, not to next quarter’s review.

> Disabling the directory account is the easy half. The half that gets audited lives on the devices.

## What the evidence file should show

For each departure in the audit window, an assessor will want to follow one person from the leave record to the last device. A short, repeatable set covers it:

1. **The leave record and the disable time.** The HR date, and when the directory and AAA accounts were disabled, inside the period you set for PS-4a.
2. **A per-device check for local accounts.** A snapshot taken after the leave date showing no local account for that person on any device, including the ones nobody logs into often.
3. **Rotation tickets for shared secrets.** Which shared accounts and secrets the person knew, and the ticket that changed each one.
4. **No activity since.** A check that no change has been made under the person’s account on any device after the leave date.

The same set works for transfers under PS-5 and for provider engineers under PS-7, with the transfer date or the provider’s notice in place of the HR record. Check 9 of our [firewall audit checklist](https://nometa.az/en/blog/firewall-audit-checklist/) covers the wider question of who can administer each firewall.

## Where SAMURAI helps, and where it can’t

SAMURAI snapshots the configuration of every device it reads, including the local accounts and privilege levels defined on it, so the per-device check in step 2 is a search instead of a login to fifty boxes. Diffs show when an account line disappeared and who removed it. Change attribution shows any change made under the departed person’s account after their leave date: commit-correlated on PAN-OS, time-windowed on FortiOS. The results export straight into the evidence file, and [the same change record](https://nometa.az/en/blog/nist-800-53-baseline-configuration/) feeds your CM-3(7) review. The limits matter just as much:

1. **It’s read-only.** It shows the account that should have been removed. Removing it is still a person with a ticket.
2. **It only sees accounts in device configuration.** Accounts that exist only on the TACACS+ or RADIUS server, or in the directory, don’t appear in any device config.
3. **Don’t use it to prove a secret was rotated.** Keep the rotation ticket as the evidence for step 3.
4. **Shared accounts hide the person.** If the leaver worked under a shared “admin” account, attribution can only name that account, which is the best argument for IA-2(5).
5. **Snapshots are periodic.** An account added and removed between two syncs never shows up in a diff. [Snapshot-based change detection](https://nometa.az/en/blog/change-detection-without-audit-logs/) explains the trade-off, and the device’s own audit log covers the gap.

---

Canonical page: https://nometa.az/en/blog/nist-ps-4-network-admin-offboarding/
Part of SAMURAI, a self-hosted, multi-vendor network monitoring & security platform. Overview: https://nometa.az/llms.txt
Contact: info@nometa.az · Docker Hub: https://hub.docker.com/r/beyrak44/samurai