We recently had to terminate a user quickly, which prompted me to build a reversible script for emergency access lockdowns instead of handling everything manually. It currently revokes sessions and MFA, resets credentials, blocks sign-in, and disables the on-premises directory account.
Most of our services use Microsoft SSO, but we still have legacy applications that require separate action. We also use Azure Virtual Desktop, where revoking sessions does not necessarily remove someone from an active session, so those sessions need to be found and terminated separately.
For a suspected insider threat, compromised account, or urgent termination, what access do you disable, revoke, reset, or verify first? I'm especially interested in overlooked areas such as VPN connections, non-SSO applications, collaboration tools, physical access, device access, API keys, and active virtual desktop sessions. I'd also appreciate advice on making the process auditable and safely reversible.
4 Answers
Make the script report results per system instead of returning one overall success message. For each action, record what was requested, whether the system accepted it, whether the resulting state was verified, and whether manual follow-up remains. Save the relevant pre-change state for restoration, but keep restoration as a separately approved process so you do not accidentally re-enable access that was already disabled. Avoid putting passwords or secrets in the logs, and test the workflow regularly with an account that has active sessions across your real applications.
Start with the central identity account: disable it in both on-premises directory services and the cloud directory, revoke all sessions and refresh tokens, reset the password, and block sign-in. Then terminate VPN connections, remove building access, and check for active virtual desktop sessions. SSO handles most applications, but keep a list of every exception that still needs a manual action.
That matches the general sequence I’m using. The virtual desktop check is particularly important because revoking the identity session does not reliably remove someone from an already active desktop session.
Don’t overlook credentials the person may have created or known about. Review API keys, personal access tokens, service accounts, cloud access keys, scheduled jobs, SSH keys, certificates, shared passwords, and application secrets associated with their work. Rotate anything that cannot be confidently attributed or restricted, and review recent activity for signs that credentials were copied or used elsewhere.
Treat every non-SSO system as a separate checklist item. Collaboration platforms, remote-access tools, legacy applications, email rules, shared file services, and any admin consoles may maintain their own sessions after the main account is disabled. Also look for VPN sessions and devices that are currently online rather than assuming the directory change will disconnect them immediately.
This is where most of the surprises tend to be. Some services accept the identity change quickly, while others leave an existing session alive until it expires or an administrator terminates it directly.
The per-system status is a good improvement. A single successful script run could otherwise hide a failed legacy-app action or an active desktop session that still needs attention.