What signs suggest OAuth access is still active after account recovery?

How to tell the recovery boundary has not actually cut off OAuth access

After account recovery, the key question is not whether the password changed, but whether the attacker still holds an authorisation path that survives the reset. OAuth can leave behind consented application grants, refresh tokens, and other delegated access that continues independently of the interactive login channel. That is why post-recovery review must focus on what remains authorised, not only on who can sign in.

Consent artefacts are often the clearest sign. If the account shows unfamiliar app grants, unusual scopes, or an integration that the user does not recognise, the attacker may still be able to act through the existing authorisation grant even if the primary password has been replaced. For a precise view of how these flows work, review RFC 6749: The OAuth 2.0 Authorization Framework alongside the vendor recovery guidance.

Another strong indicator is continued token-backed activity. If refresh tokens are still being used, or if mail, files, contacts, or other data continue to move through a known integration after recovery, that suggests the attacker is living off delegated access rather than reauthenticating interactively. In practice, this often shows up as background access that looks legitimate to the platform because it is using an already approved client and scope set.

Session behaviour matters as well. If some sessions end on password change but others persist, or if new activity appears from the same application after the reset, the account may still have active authorisation artefacts that were never revoked. That distinction is important because recovery that only resets the password can leave the real compromise path intact.

When the activity is tied to mailbox or storage access, the risk is especially operational. The attacker does not need the login screen if the authorised integration can already read, sync, or exfiltrate content. That is why signs of continued access to email, shared drives, calendar data, or API-connected storage after recovery should be treated as a probable residual-session or residual-consent problem until proven otherwise.

Risk and Threat Considerations

OAuth recovery failures are dangerous because they can create a false sense of closure. The account owner may believe the incident is over after changing a password, while the attacker still has a valid token, scope, or app grant that continues to operate unnoticed.

Failure mechanism: The attacker keeps using refresh tokens, retained consents, or already authorised applications after the interactive credentials are reset, so the recovery action does not remove the true access path.

Impact: Mailbox access, file access, and other delegated actions can continue after recovery, extending theft, monitoring, or impersonation even when the password has already changed.

Practitioner Guidance

What to verify: Confirm whether recovery included revoking active sessions, removing suspicious consents, and invalidating refresh tokens, not just resetting the password. If any of those steps were skipped, treat continued access as plausible.

Decision rule: If the account shows unfamiliar app consent or post-reset background activity, remove the app grant first and then assess whether broader credential or session revocation is needed. If the access is tied to a trusted business integration, validate the owner, scope, and issuance history before restoring it.

What practitioners underestimate: The absence of login alerts does not mean the account is clean. OAuth abuse often survives recovery precisely because it bypasses the login channel the user can see.

Practitioner takeaway: Effective recovery is measured by the disappearance of authorised access paths, not by the success of a password reset.

Related resources from NHI Mgmt Group

• What signs suggest a Git secret leak may still be active after cleanup?
• Why do ephemeral credentials still leave risk in machine access models?
• What breaks when a contractor account still has privileged access after termination?
• Who is accountable when contractor badge access is still active after the engagement ends?