Any identity-bearing object or access route that allows an attacker to regain access after the original compromise is discovered. OAuth apps, service principals, tokens, and newly granted roles become re-entry paths when lifecycle governance is incomplete.
How Re-entry Paths Work
A re-entry path is not the initial foothold itself, but the surviving route an attacker can use to come back after defenders believe the compromise has been removed. That usually means something still authenticates, authorizes, or can be reactivated, such as an app registration, service principal, refresh token, API key, delegated role, or forgotten integration.
The term is best understood as a lifecycle problem. If the original incident response focuses only on the visible account or endpoint, an attacker may keep a parallel route alive through consent grants, cached tokens, cloud app credentials, or secondary admin assignments that were never revoked.
Why Re-entry Paths Persist
Re-entry paths persist because modern access is often distributed across identities, tokens, roles, and delegated permissions rather than a single login. A compromise can be cleaned up in one place while the attacker’s durable access remains elsewhere in the access graph.
Incomplete offboarding, weak credential rotation, stale OAuth consent, and inconsistent revocation all create the same outcome: an object that still has authority even though the incident was supposedly contained. This is why re-entry paths are especially common in environments with many service accounts, automation workflows, and third-party integrations.
Common Forms Of Re-entry Path
In practice, re-entry paths often show up as identity-bearing objects that outlive the response effort. A compromised service principal with persistent secrets, an OAuth app with broad consent, a token that was not invalidated, or a newly granted emergency role that was never removed can all become the attacker’s way back in.
-
Persisted tokens and secrets that were copied before discovery.
-
Applications or integrations with standing permissions that were not reviewed.
-
Privileged roles or delegated access granted during response and left in place.
-
Linked systems where one revoked credential still leaves another trusted path intact.
What Re-entry Paths Reveal About Governance
Re-entry paths expose gaps in lifecycle governance more than gaps in perimeter defense. They show that revocation, ownership, inventory, and periodic review were not strong enough to remove every surviving path back into the environment.
That is why the concept matters in identity-heavy environments: the attacker does not need to defeat the whole control stack again if one durable permission edge still exists. A clean incident response requires proving that all routes tied to the compromise were removed, not just the one that was first detected.
Risk and Threat Considerations
Re-entry paths matter because they let an attacker regain access after a containment action appears to have succeeded. The main risk is false closure: defenders may rotate one secret or disable one account while a parallel access path still exists elsewhere in the authorization chain.
Failure mechanism: incomplete revocation, stale delegated permissions, long-lived tokens, or overlooked application trust relationships preserve a usable foothold that the attacker can return through later.
Impact: repeated compromise, privilege persistence, delayed eradication, and renewed access to data, workloads, or administrative control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Re-entry paths often survive through unmanaged tokens and secrets. |
| AC-2 — Account Management | Re-entry paths arise when accounts, roles, or app access remain active after compromise. | |
| AC-6 — Least Privilege | Excess standing access makes alternate return paths easier to exploit. | |
| Recommendation — Inventory, rotate, and revoke authenticators that could preserve post-compromise access. Disable and review every account, role, and delegated access path tied to the incident. Reduce standing permissions so compromise does not leave durable alternate access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero Trust emphasizes continuous verification rather than trusting a previously used access path. |
| Recommendation — Revalidate every request and trust decision instead of relying on prior session state. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers often return through surviving valid credentials or permissions. |
| Recommendation — Hunt for reused valid accounts and remove any surviving trusted access paths. | ||
Practitioner Guidance
Why practitioners should care: the important question is not only whether the obvious account was disabled, but whether every identity-bearing object tied to the incident was accounted for and removed. Re-entry paths are often discovered only after a second intrusion, which means post-incident validation should treat residual permissions as a containment failure until proven otherwise.
Practitioner takeaway: if an identity, token, app, or role can still authenticate or be reactivated after incident response, the compromise is not fully closed.