The Offboarding Blind Spot: How One Ex-Employee Crippled a School District for 21 Months

Potter's path is textbook. He worked as a senior IT support specialist from May 2022 to April 2023. In that time, he provisioned his own accounts across multiple platforms. He recorded credentials in a personal spreadsheet. When he left, the district disabled his main AD account but did not revoke Google Workspace sessions or rotate passwords for the shared Google admin account. They did not check third-party service integrations. Potter used his retained Google admin access to reset passwords for Schoology and Apple School Manager. He could do this because those services had been configured to allow password resets via Google SSO, but the recovery email on the Google admin account was still his personal address. Once he regained direct access, he changed the recovery email and locked out the district. The mechanism is not a vulnerability. It is a tenant configuration property that no one monitors. To detect this, security teams would need to audit the recovery email addresses for all administrator roles across every SaaS application. Most teams never do. A script in Google Admin Console can list all users with admin privileges and their recovery emails, but even that only covers Google. For third-party services, there is no unified view. The attack chain: retain -> recover -> escalate -> persist -> disrupt.

Most teams skip the step of revoking sessions and recovery paths after termination, not just passwords. Here is the sequence that closes the gaps.

When Potter struck, the district had no incident response plan for insider attacks. The most impactful action per phase: within the first hour, the IT director should have locked all admin accounts and reviewed audit logs to identify the attacker's IP range. The most commonly missed action: checking third-party service recovery configurations. Here are role assignments for any similar scenario. CISO: declare an incident and engage legal counsel. IR Team: collect logs from Google Workspace, Apple School Manager, Schoology, and GoDaddy. Look for password reset events and OAuth token grants. DevOps / IT: block all IP addresses associated with the terminated employee (home ISP, current employer VPN ranges). Legal: draft preservation notices and coordinate with law enforcement if criminal activity is suspected. Communications: prepare internal notification to affected departments and external messaging if student or staff PII was exposed. The handoff that stalls incidents most often is when the IR team finishes its investigation but does not hand a clean 'restoration of secure access plan' to the IT team. That handoff should include a checklist of all accounts that need password resets and all trusted devices that need re-enrollment. In Potter's case, the district spent weeks recovering because they had to wait for Apple to re-enroll device management. A pre-negotiated emergency escalation path with Apple and Google would have cut that time by 80%.

Three lessons that generalize beyond this story. First, access is not binary. Disabling a directory account does not revoke sessions or SSO tokens. You must treat session revocation as a separate action. Second, credentials are not the only threat. Recovery paths, password manager entries, and delegated admin roles persist long after a password change. Map those for every employee during onboarding, not just during offboarding. Third, insider threat mitigation is not an IT-only problem. The decision to centralize or decentralize identity decisions has a direct impact on residual risk. If every business unit can grant access to a SaaS app without IT oversight, your offboarding process will always be incomplete.