What should teams do first when a compromised employee account can reach critical systems?

What to do first when a compromised account can still reach critical systems

The first priority is containment, not diagnosis. If the account can still touch critical systems, the safest sequence is to stop the account’s live access, revoke the privileges that made the reach possible, and preserve evidence before wider cleanup. A delayed response can turn a single account compromise into a broader systems incident.

That order matters because session tokens, delegated access and standing roles can remain valid even after a password reset. If the account is still trusted by VPN, SSO or downstream admin paths, the attacker may keep moving unless those paths are cut off explicitly.

How to contain the account without creating a bigger outage

Disable the account or terminate its active sessions first, then remove privileged entitlements and rotate any shared secrets the account could use. For a practical runbook, see Account Takeover Response Playbook, which focuses on session revocation, token invalidation and recovery steps for compromised user and service accounts.

If the identity is tied to infrastructure or administrative access, look beyond the user record itself. The relevant control problem is usually the path of access, not just the account object, so you also need to remove standing access through SSO, VPN, admin roles, delegated access or app credentials that were issued from that identity.

When the compromised account is part of a broader identity incident, use an identity-centric containment model rather than ad hoc account resets. Identity Incident Response Playbook is useful when the incident involves multiple authentication artifacts, conditional access paths or privilege relationships that need to be removed in a coordinated way.

What else to check before restoring normal access

Preserve audit logs before changing too much, then identify where the account authenticated from and what it accessed. If critical systems were reachable, assume the attacker may have used the account for more than one action path, including privilege escalation, lateral movement or secret access, and verify whether any shared credentials, API keys or service logins exposed by that account need replacement.

For systems where the account’s reach extended into infrastructure, key material or service identities, the blast radius can be wider than the human user account. The same incident may also require checking whether the account was used to alter trust settings, add persistence, or plant a new login path that survives the initial lockout.

Risk and Threat Considerations

A compromised account that can still reach critical systems is dangerous because the attacker is already inside a trusted path. The main risks are privileged misuse, persistence through surviving sessions or delegated access, and further exposure if the account can approve, modify or impersonate other access paths.

Failure mechanism: The initial password reset or account disable step does not always invalidate active tokens, cached sessions, app passwords, delegated grants or standing admin roles, so the attacker keeps operating through a still-valid trust relationship.

Impact: Critical systems can be modified, data can be exfiltrated, secrets can be harvested, and the compromise can expand from one account to a broader identity or infrastructure incident.

Practitioner Guidance

What to prioritise: Treat live access termination as the first decision point. If you can suspend sessions faster than you can investigate root cause, do that first and document the exact access paths that were cut.

What to verify: Confirm that every high-value access path tied to the account is gone, including SSO sessions, VPN access, role assignments, delegated permissions and any shared secret that would let the same identity re-enter.

Decision rule: If the account can authenticate to a critical system, credential reset alone is not enough. Remove the trust relationship first, then investigate whether the account was also used to create persistence or to access other identities.

Practitioner takeaway: In a critical-system compromise, containment should be judged by whether the attacker can still act, not by whether the password has been changed.

Related resources from NHI Mgmt Group

• Employee
• What breaks when a service account is compromised in production systems?
• Who is accountable when a compromised machine identity is used to reach sensitive systems?
• What should organisations do when a compromised account starts acting normally at first?