Compromised Entra admin account: what to do in the first hour

Global admin account hacked: what to do first

If you only read one section, read this one. The order matters because each step closes a gap the previous one leaves open.

1. Sign in as someone else. Use a second Global Administrator or an emergency access account, never the account you suspect.
2. Disable the account. This blocks new sign-ins and new tokens, even if the attacker holds the password and can pass MFA.
3. Revoke sessions. This invalidates refresh tokens and browser session cookies. Access tokens already issued can keep working for up to about an hour in apps that do not support Continuous Access Evaluation.
4. Reset the password. Do it as an administrator, so the attacker's registered methods are not consulted.
5. Remove persistence. Attacker-registered MFA methods and devices, OAuth consent grants, app registrations and service principal credentials, role assignments, inbox rules and forwarding.
6. Verify by reading the tenant back. Role membership, sign-in logs after the revoke timestamp, authentication methods. A command that returned without error is not proof.
7. Capture evidence and fingerprint every export.

Microsoft's own emergency revocation procedure for Entra-only users runs disable first, then revoke sessions, then disables the user's registered devices. The steps below follow that order and add what a privileged account needs on top of it.

Step 0: sign in with a second Global Administrator or an emergency access account

Do not investigate from the compromised account. The attacker may be watching it and may have added their own authentication methods to it, and anything you do from it is something they can reverse. Use a second Global Administrator or one of your emergency access accounts. Disabling an administrator is a sensitive action: Microsoft lists Privileged Authentication Administrator as the least privileged role that can update accountEnabled for administrators, and Cloud Device Administrator at minimum to disable devices; User Administrator is enough for ordinary users, not for admins. If the compromised account is your only Global Administrator, see the questions at the end of this guide, then read our break-glass account guide once the incident is closed.

Step 1: disable the account

In the Entra admin center, open the user, go to Properties, clear Account enabled, and save. The scripted equivalent is Update-MgUser -UserId <id> -AccountEnabled:$false; the Graph call is PATCH /users/{id} with the body {"accountEnabled": false}. The least privileged Graph permission combination is User.EnableDisableAccount.All plus User.Read.All.

Disable is the strongest single step because it removes the attacker's ability to come back. Once disabled, in Microsoft's words, "the user can't gain new tokens for any application tied to Microsoft Entra ID." Account disable is also one of the five Continuous Access Evaluation (CAE) critical events, so CAE-capable clients working against Exchange Online, SharePoint Online, and Teams are cut off within minutes rather than at the next token expiry. What disable does not do is end an access token already in the attacker's hands in an app that does not support CAE. That is why step 2 exists. For the two actions compared in detail, read revoke sessions vs disable user.

Step 2: revoke refresh tokens, and know what survives

On the user's Overview page select Revoke sessions, or run Revoke-MgUserSignInSession -UserId <id>. The Graph method is POST /users/{id}/revokeSignInSessions, least privileged permission User.RevokeSessions.All. Microsoft describes it as invalidating "all the refresh tokens issued to applications for a user (and session cookies in a user's browser), by resetting the signInSessionsValidFromDateTime user property to the current date-time." Every application then has to sign in again, and because the account is disabled, that sign-in fails.

Now the part most runbooks skip. Microsoft Learn states plainly that access tokens already issued keep working until they expire: "By default, access tokens issued by Microsoft Entra ID last for 1 hour," and the token lifetime page puts the default at a random value between 60 and 90 minutes. For an application that does not support Continuous Access Evaluation, the attacker can keep using a token they already hold for that long, whatever you do in the directory: "For applications using access tokens, the user loses access when the access token expires." For CAE-capable client and workload pairs, an administrator revoking all refresh tokens is a critical event and the still-unexpired token is rejected with a claim challenge, so access ends within minutes, up to about 15 minutes. Microsoft also notes "there might be a small delay of a few minutes before tokens are revoked," and that Entra ID cannot revoke a session token an application issued under its own scheme.

Practical consequence: treat the hour after disable and revoke as a window in which the attacker may still be reading mail or files through a non-CAE client. Keep working through the persistence steps; do not wait it out. And do not treat the 2xx response from either call as containment. The revoke reference says only that success "returns a 2xx series response code." Whether access has ended is something you read back from Microsoft in step 5.

Step 3: reset the password

Reset the password as an administrator and do not hand the new one to anyone until step 4 is complete. A password change is also a CAE critical event, so it reinforces the cutoff for CAE-capable clients. Do not rely on it alone: Microsoft states that against an illicit consent grant, resetting passwords or requiring MFA is not effective because the malicious app is external to the organization. A password reset removes one credential; it does nothing to an OAuth grant, an app secret, or a role assignment the attacker created while they held the account.

If the account is synced from on-premises Active Directory, Microsoft's procedure adds two things: disable the on-premises account as well, and reset the password twice in Active Directory to mitigate pass-the-hash while replication catches up.

Step 4: remove persistence

A privileged account is worth more to an attacker than the mailbox behind it, because it can create things that outlive the account. Assume they did. Work through each of these and record what you find and what you remove.

Authentication methods and devices

Review the account's registered authentication methods and remove any the real owner cannot vouch for: unfamiliar phone numbers, authenticator app registrations, security keys. Then list the devices registered to the user and disable any you cannot attribute, with Update-MgDevice -DeviceId <id> -AccountEnabled:$false; a disabled device object blocks new token issuance from that device. Microsoft's post-disable best practices also list an Intune wipe or selective wipe for managed devices, with the caveats that the device must be online and that data on a wiped device cannot be recovered, so decide that one deliberately.

OAuth consent grants

Search the Purview audit log for "Consent to application" events in the incident window and check whether IsAdminConsent is True, which indicates that someone with Global Administrator access granted broad access. Audit entries can take from 30 minutes up to 24 hours to appear, so search again later. Microsoft's remediation options are: remove the app assignment for the user, revoke the consent grant with Remove-MgOauth2PermissionGrant, or revoke the app role assignment with Remove-MgServicePrincipalAppRoleAssignment. Background is in our illicit consent grant entry and the OAuth consent response page.

App registrations and service principal credentials

List app registrations and service principals created or modified during the window. An attacker who held Global Administrator could have added a client secret or certificate to an existing application that already holds high privilege, then used that application's identity long after the user account is gone. Remove credentials you cannot attribute, and check whether any service principal was given a directory role; our guide on service principals holding Global Administrator covers why that is the quietest form of persistence.

Role assignments and group memberships

Compare the current members of Global Administrator, Privileged Role Administrator, and the other privileged roles with your last known good list. Remove any assignment, active or eligible, that you cannot explain. Check role-assignable groups too. If your tenant does not have Privileged Identity Management, use the audit log's role management events for the window; our guide on privileged roles without P2 covers how to keep a baseline you can compare against.

Inbox rules and forwarding

Check the mailbox for inbox rules that delete, move, or forward mail, and for mailbox-level forwarding. Attackers add these to hide security notifications and to keep a copy of the mailbox after they lose the account. Remove them, and check any other mailbox the account had delegated access to.

Step 5: verify containment by re-reading the tenant

None of the steps above is complete because a command returned without error. Containment is complete when Microsoft's own data says the state you wanted is the state that exists, and it stays that way. Read back at least these:

• The user object. accountEnabled is false and signInSessionsValidFromDateTime is at or after the time you revoked.
• Sign-in logs after the revoke timestamp. Filter to the account and to any application or service principal you touched. A successful interactive or non-interactive sign-in after your revoke time means something is still valid or something was missed. Failed sign-ins against a disabled account are the result you want to see.
• Authentication methods. Only methods the owner recognizes remain.
• Role membership. The privileged role lists match the baseline again, including eligible assignments and role-assignable groups.
• Consent grants and app credentials. The grants and secrets you removed are gone, and no new ones have appeared since.
• Devices. The devices you disabled show as disabled.

Repeat the sign-in log check after the access token window has passed (about an hour, longer if you have reason to think CAE long-lived tokens are in play). This is the difference between "submitted" and "verified", and it is what our glossary entry on containment verification is about.

Step 6: capture evidence and fingerprint the exports

Do this before the logs age out and before anyone starts tidying up. Export the sign-in and audit logs for the account and for every application you touched, covering the incident window and the hour after your revoke, plus the before and after lists for role membership, consent grants, app credentials, authentication methods, and devices. Record four timestamps: when the signal was observed, when the plan was ready, when each action was submitted, and when you verified the final state from Microsoft's data. Then compute a SHA-256 hash of every exported file, for example with Get-FileHash -Algorithm SHA256, and store the hash list with the files. A hash list does not prove who made the files, but it lets anyone show later that they have not changed since capture, which is what an insurer, an auditor, or your own post-incident review will ask for.

After the first hour

Once the account is contained and verified, the work turns to scope and hardening. Microsoft's guidance for consent grant incidents relies on the Purview audit log and notes that this only works if mailbox auditing and admin and user activity auditing were on before the attack; if they were not, turn them on now. Check what the account could reach, not only what it touched; our identity blast radius entry explains why. Then reduce the number of accounts that could cause this again: work out how many Global Administrators you need, and set up two emergency access accounts before you need them. Microsoft frames access token lifetime as a trade-off with "the amount of time that the client retains access after the user's account is disabled"; for administrator accounts, CAE-capable clients do more to shorten that window than a tighter token policy.

Sources

• Revoke user access in an emergency in Microsoft Entra ID, checked September 2026
• user: revokeSignInSessions (Microsoft Graph v1.0), checked September 2026
• Update user (Microsoft Graph v1.0), checked September 2026
• Configurable token lifetimes in the Microsoft identity platform, checked September 2026
• Continuous access evaluation, checked September 2026
• Risk-based access policies (Microsoft Entra ID Protection), checked September 2026
• Detect and remediate illicit consent grants (Microsoft Defender for Office 365), checked September 2026