Warning signs include access that continues after password changes, authentication that survives 2FA enablement, and tokens that appear outside normal visibility or audit views. Unusual OAuth app consent, unexpected scope expansion, missing token records, and activity from desktop or mobile app channels can also indicate persistence. Teams should treat unexplained continued access as a strong signal that revocation controls are incomplete.
How token persistence shows up after account compromise
Token-based persistence usually means the attacker is no longer relying on the original password path. The compromised session, refresh token, API token, OAuth grant, or app consent keeps working even after the password is changed or MFA is enabled, so the account still behaves as if it is trusted.
The clearest clue is a mismatch between what the user has done and what access still exists. If password resets do not break access, if new MFA does not force reauthentication, or if access continues from channels that should have been invalidated, you are likely looking at token persistence rather than a normal login artefact.
It is also common to see the persistence mechanism hidden from everyday views. Tokens may not appear in the same place as interactive sign-ins, and that gap can make the account look clean while the attacker keeps using a valid bearer artifact. That is why token visibility, consent review, and revocation logging matter as much as password hygiene.
What telemetry and account behaviour usually betray it
Behavioural clues are often more useful than a single alert. Watch for unexpected OAuth app consent, scope expansion after the initial compromise, or continued access from desktop and mobile application channels when browser sign-in has been reset. Those patterns suggest the attacker has shifted to a durable token path.
Another strong indicator is activity that keeps showing up outside the normal audit or session record. Missing token inventory, unexplained token reuse, or successful requests from clients that should have been cut off all suggest the revocation process did not reach every issued credential.
For identity teams, the practical question is not only whether a token exists, but whether you can prove it is dead. A token that cannot be located, cannot be tied back to an owner, or cannot be revoked cleanly is already a persistence problem, even before you confirm malicious use.
What to confirm before calling it persistent access
Start by checking whether the suspected token still authorises requests after the expected invalidation event. If the password was changed, MFA was reset, or the account was disabled and access still succeeds, treat that as evidence of incomplete control coverage rather than a user convenience issue.
Then separate legitimate long-lived integrations from attacker-controlled persistence. Some application tokens and delegated grants are expected to survive a password reset, but they should still be discoverable, scoped, owned, and revocable. A token that is both durable and unexplained is the combination that matters.
If you need a knowledge baseline for response planning, the ITDR guide is useful because it frames token replay, session abuse, and identity response as one detection problem rather than separate events. For broader breach patterns involving stolen tokens and compromise paths, The State of NHI & AI Agent Breach Report 2026 provides useful context on how attackers maintain access after the initial theft.
Risk and Threat Considerations
Token persistence matters because it breaks the assumption that password resets and MFA changes restore safety. If revocation does not reach the active bearer token, the attacker can keep operating with valid access while defenders think the account has been remediated.
Failure mechanism: A stolen refresh token, session token, or app consent remains valid, or is reissued through a linked flow, so the attacker retains authorised access after the original credential path has been changed.
Impact: The compromise can last far longer than an interactive sign-in theft, enabling continued mailbox access, data exfiltration, privilege expansion, lateral movement, and repeated reentry until every active token path is revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token persistence hinges on lifecycle control of authenticators and revocation after compromise. |
| IA-2 — Identification and Authentication (Organizational Users) | Continued access after password or MFA changes shows identity authentication controls are not fully terminating sessions. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detecting hidden token use depends on correlating sign-ins, consent, and request activity across logs. | |
| Recommendation — Tighten authenticator lifecycle controls and verify stolen tokens are revoked, expired, or invalidated. Require reauthentication and session termination when account state changes after compromise. Review audit records for token reuse, consent changes, and post-reset access anomalies. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Stolen or exposed tokens are the common persistence material after account compromise. |
| NHI-07 — Long-Lived Secrets | Persistence often survives because tokens outlive the password reset and remain valid too long. | |
| Recommendation — Detect leaked tokens quickly and rotate or revoke them before they can sustain access. Shorten token lifetimes and remove durable credentials that can outlast recovery actions. | ||
| MITRE ATT&CK | T1528 — Steal Application Access Token | Token-based persistence commonly uses stolen access tokens to preserve authorised access after compromise. |
| Recommendation — Hunt for stolen token use and map it to post-compromise access paths in detections. | ||
| NIST CSF 2.0 | DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, Software, and Services | Ongoing token use after remediation is an unauthorized connection pattern that must be monitored. |
| Recommendation — Correlate access monitoring with token revocation events to confirm containment. | ||
Practitioner Guidance
What to prioritise: Treat unexplained continued access as a revocation failure first, not just an anomaly. The immediate job is to identify every token-bearing path tied to the account and determine which ones still work after the supposed containment action.
What to verify: Confirm whether you can see the token, bind it to an owner or app, revoke it, and prove that no request still succeeds with it. If any of those steps fail, the environment is not yet contained.
Decision rule: If access survives password change or MFA enablement, escalate to token and consent review, then rotate any downstream secrets or integrations that the token could still reach. If the token cannot be inventoried, treat that as a visibility gap with security impact, not a documentation issue.
Practitioner takeaway: Token persistence is usually a control-coverage problem, not a password problem, so the right response is proof of invalidation across every active token path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org