Could a connected application retain access after a password reset?¶

Yes. Connected applications may use delegated permissions, refresh tokens, API keys, application passwords or service credentials that a normal password reset does not invalidate.

Identify the application's authority¶

Record the application name and client ID, publisher, permission scopes, consent time, approving user or administrator, affected accounts and token activity. Use stable IDs because a display name can be duplicated or misleading.

Establish whether consent applied to one user or the whole tenant. Broad permission describes potential access; event and resource logs are still needed to show what the application actually did.

Follow activity across the reset¶

Compare application, token and audit events before and after the password change. Continued file, message or settings activity may indicate surviving authority rather than a failed reset. Check whether the application created rules, changed permissions, downloaded data or accessed other accounts.

Where compromise is suspected, preserve consent, token and activity records before revocation when operationally possible. Remove or revoke the relevant permission and credential separately, then verify that requests fail and no related application or service account remains.

Distinguish organisation-managed applications from user-approved or unknown clients, but do not treat either category as conclusive without examining approval and use.