Shared admin password after a resignation

Sequence, strictly in this order:

1. Rotate the credential, not just the person. Change svc-admin on all 60 servers and remove the spreadsheet copy, scheduled in a maintenance window because services may run under that account. First, because an 11-month-old password sitting on a finance share and known to at least three people - one of whom has left - is the live exposure.
2. Disable VPN access and hunt for persistence. Check scheduled tasks, newly created local accounts, SSH keys, service accounts and group membership changes around the departure date. A shared credential cannot attribute activity, so assume the worst and verify.
3. Preserve logs before the 14-day rotation overwrites them. Export to write-once storage, hash and timestamp.
4. Notify HR and legal now, and let them decide whether and how the former employee is contacted.

Why offboarding failed: badge and domain account are not the credential that administers servers. svc-admin is a local account; disabling a domain identity does not touch it, and VPN may authenticate against a separate directory. Offboarding that only checks the directory tests the person, not the access. The 01:00 logons are the proof: three successful authentications that nobody can attribute to a human.

The ambiguity is the trap, so treat it as an investigation rather than an incident response.

• Preserve first. Export VPN logs with source IP, geolocation, session duration and which servers were touched; then the firewall/NAT records mapping that residential ISP address to the session. Hash and timestamp the export.
• Test the benign explanation. Ask each current administrator separately and in writing whether they were working at those times, and whether the source IP is theirs. Separately matters: a shared conversation contaminates the statements you may later rely on.
• Give legal the decisions on engaging counsel, whether a police report is warranted, and any statutory clock. You do not interview the former employee; HR or legal does. Your output is technical fact-finding.
• Do not delay rotation to preserve logs. If the password must be changed before the export is complete, record the time, the reason and who authorised it in the incident log.

The uncomfortable finding to report upward: with one shared credential, you cannot prove who acted, and that inability to attribute is itself a control failure worth stating plainly to HR and to the audit committee. It is also the argument that funds the fix.

Target state: individual accounts, just-in-time elevation, no shared secrets.

• Retire svc-admin; each administrator gets a named account, and service workloads get their own managed identities where the platform supports it.
• Put privileged access behind a vault or PAM tool: per-session checkout, approval, automatic rotation after use, and no standing admin rights on endpoints.
• Route interactive admin sessions through a jump host with session recording.
• Rotation must be event-driven (any departure, any suspicion) with a 12-month ceiling, not an annual calendar reminder.

Evidence, measured not asserted:

• Count of servers still sharing a local admin password hash - target zero, queried rather than sampled.
• Percentage of privileged sessions attributable to a named human in the logs - target 100%.
• Median elapsed time from HR leaver event to full access removal, including local accounts, VPN, SaaS and shared secrets. If it exceeds one hour, the process is broken regardless of tooling.
• A 60-day-old privileged session retrieved on request, proving retention beyond 14 days.

Also fix the trigger, not just the tools: offboarding should be fired by an HR system event that opens a checklist with a named owner and closure evidence. Given the cancelled tooling project, start with the checklist and its owner - tooling bought before the process exists tends to be abandoned the same way.