What should organisations do when attackers may still have alternate access paths after containment?

When containment is not the same as closure

Containment ends active spread, but it does not prove the attacker lost every foothold. If a threat actor reached an app registration, API token, delegated permission, cloud role, or service principal, those paths can outlive the noisy part of the incident and re-enable access later. The practical question is not whether one account was locked down, but whether every trust path that supported the intrusion has been discovered and removed.

That is why the cleanup phase has to start from inventory and trust relationships, not from the first compromised login. Teams should identify which identities, secrets, applications, roles, and delegation chains existed before the incident, then compare them against what is still authorized after containment. In incident response terms, this is a scope problem as much as a remediation problem.

Rebuilding from inventory also helps separate true persistence from ordinary operational complexity. Some access paths are owned, expected, and legitimate, while others are shadow artifacts created by administrators, automation, or integrations. If those are not distinguished, responders may rotate the obvious secret, declare success, and leave behind a durable alternate route.

Why alternate access paths survive the first cleanup

Attackers often favor whatever survives password resets and account disablement. A stolen token, an overprivileged service principal, a long-lived OAuth grant, or a forgotten application role can all preserve access even after the primary user account is remediated. That makes the incident broader than an endpoint or mailbox compromise, because the real persistence layer may live in the authorization fabric.

Alternate access paths are especially dangerous when they are indirect. For example, a compromised application can keep acting through its own credentials even after a human operator’s session is revoked. Likewise, a role assignment or delegated consent can preserve reach into multiple systems without leaving an obvious interactive login trail. The attacker does not need the original entry point if another valid path still exists.

Good cleanup therefore checks for what still has authority, not just what was used first. Inventory should cover issued secrets, active tokens, app registrations, delegated permissions, role bindings, and any automation or machine-to-machine trust that can still authenticate or authorize actions. Where those objects are not visible, they are often the first place persistence hides.

For a practical view of how stolen secrets, service accounts, and lateral movement continue to drive real incidents, see The State of NHI & AI Agent Breach Report 2026.

What “closed” should mean after an identity-driven incident

An incident should not be considered closed until every unauthorized path is either removed or explicitly accepted as a documented exception. That means verifying ownership of each identity-bearing object, revoking anything not required for business operation, and rotating credentials where the compromise window cannot be bounded with confidence. The answer is not to delete everything, but to restore a trusted minimum set.

Closure also depends on proof. Teams should be able to show which tokens were invalidated, which apps were decommissioned or reapproved, which roles were removed, and which service principals were retained with a clear business justification. If that evidence does not exist, the cleanup is incomplete even if alerts have gone quiet.

This is where identity lifecycle management becomes an incident response discipline. Discovery, revocation, revalidation, and reissue are the control sequence that turns a noisy containment action into durable recovery. The organization is finished only when the environment can no longer be reached through an unauthorized relationship the attacker previously enjoyed.

For the attack pattern perspective, MITRE ATT&CK Enterprise Matrix remains useful for mapping credential access, privilege escalation, and lateral movement, while CISA cyber threat advisories help teams align cleanup priorities with active adversary behavior.

Risk and Threat Considerations

When alternate access paths remain in place, the organization has not just a remediation gap but a renewed compromise risk. The attacker can return through a different token, app, or delegated trust path, often without re-triggering the original detection chain, which makes the incident look contained when it is still live.

Failure mechanism: Cleanup targets the visible account compromise but misses durable authorization artifacts such as grants, roles, service principals, or long-lived secrets, allowing the attacker to reauthenticate or act through a separate valid path.

Impact: Persistence can survive containment, leading to repeat intrusion, wider lateral movement, and delayed eradication even after the obvious account has been reset or disabled.

Practitioner Guidance

What to prioritise: Start with the trust objects that can still authenticate or authorize action, not with the most obvious user account. If a secret, token, app registration, or role can still reach production systems, treat it as higher priority than a clean-looking login history.

What to verify: Confirm that inventory is complete enough to explain every surviving path into the environment. The question to answer is simple: if the original foothold were reused, what other valid route would still let the attacker in?

Decision rule: If you cannot prove an access path is required, attributable, and freshly reviewed, remove or disable it first and reintroduce it only after business validation. That is safer than waiting for evidence of abuse.

Practitioner takeaway: A breach is not truly contained until the organization has removed every unauthorized trust relationship that could let the attacker come back under a different identity, token, or role.

Related resources from NHI Mgmt Group

• Why do former employees still keep access after offboarding in many organisations?
• Why do organisations still accumulate access risk even after they invest in SSO coverage?
• How do organisations use identity-level context to speed up investigation and containment after an access incident?
• What should organisations do first when they discover a contractor may still have access after termination?