They are signing in as an app, not a user
You reset the admin, revoked the sessions, and the attacker is still reading every mailbox. They added a credential to a privileged app. Here is the Entra persistence that survives password resets.
You caught the breach, reset the admin, revoked the sessions. The attacker is still in. They are not signing in as a user.
What it is
Entra ID applications and service principals authenticate with their own credentials, separate from any user. An attacker who can manage application credentials, through Application Administrator, ownership of a privileged app, or a compromised admin role, adds a new client secret, certificate, or federated credential to an application that already holds powerful permissions, such as broad Microsoft Graph application roles. That credential authenticates as the app and survives user password resets and MFA. This is T1098 (account manipulation) and T1556 (modify authentication process).
Why it works
It is not a human sign-in, so it is easy to miss, and password resets and session revocation do not touch it. It is standing access at application scope, for as long as the credential lives.
How to detect it
In the Entra audit logs, look for a client secret, certificate, or federated credential added to a privileged application by an actor that does not normally manage it, then the service principal signing in from a new location.
The fix that holds
Restrict who can manage application credentials by limiting Application Administrator and app ownership. Least-privilege application permissions, apply conditional access to workload identities, and alert on credential additions to privileged apps. When you respond, find and remove every added credential, not just the first one, because the attacker may have minted several.
Practice it
We built an Entra application credential backdoor scenario in GraphLattice Range so teams learn why evicting the admin is not the end, and how to clear app-scope persistence for good.