Blog
They wrote secured. The app still has Mail.Read.
At 02:22 Priya resets the password for devon.p and revokes sessions. Invoice helper still has application permission Mail.Read. The scribe writes that the account is secured.
At 02:22 on 29 October 2026, Priya S (on-call, platform) resets the password for devon.p in Entra ID and chooses revoke sessions. The interactive sign-in at 01:47 came from an ASN the user's other sign-ins do not use. At 01:51 the audit log records Consent to application: devon.p consented enterprise application Invoice helper, client id ending 4f6c2d1, application permission Mail.Read. That permission authenticates as the app, not as devon.p. Marcus T (incident commander) reads the plan. It says: on a suspected takeover of anyone who can consent, reset the password, revoke that user's sessions, and remove every application that account consented that day, including application permissions. Disable the account until those grants are gone. Do not write that the account is secured while an application permission consented by that account still has Mail.Read. Priya says the password reset kills the token. She does not open Enterprise applications. She does not disable devon.p. Noor A (identity), who owns the consent policy, is not on the call. At 02:31 a service principal sign-in for client id ending 4f6c2d1 succeeds against Microsoft Graph. No user is on that row. At 02:44 the scribe writes that the account is secured, the password was reset, and sessions were revoked.
A weak record of those twenty-two minutes reads:
Account secured. Password reset and sessions revoked.
A strong one reads:
29 October 2026, 02:22 to 02:44. Incident-response tabletop. Seats: Marcus T (incident commander), Priya S (on-call, platform). Noor A (identity, owns the Entra consent policy) was not on the call. Inject at 02:22: interactive sign-in for devon.p at 01:47 from an unfamiliar ASN. Audit log at 01:51, Consent to application, devon.p consented Invoice helper, client id ending 4f6c2d1, application permission Mail.Read. The permission authenticates as the app. Plan: on a suspected takeover of anyone who can consent, reset the password, revoke that user's sessions, and remove every application that account consented that day, including application permissions. Disable the account until those grants are gone. Do not write that the account is secured while an application permission consented by that account still has Mail.Read. Priya resets the password and revokes sessions at 02:22. She says the password reset kills the token. She does not open Enterprise applications. devon.p stays enabled. At 02:31 the service principal sign-in for client id ending 4f6c2d1 succeeds against Microsoft Graph. No user on the row. Mail.Read is still listed on Invoice helper. At 02:44 the scribe writes that the account is secured. Facilitator stops the sitting before anyone treats that sentence as the finding, and before anyone tells devon.p the account is secured. Nothing was deleted. The account was not disabled. Follow-up: Noor removes the Invoice helper application permission, or writes why Mail.Read may remain after a password reset and a session revoke, by 12 November 2026.
Both notes say the password was reset and sessions were revoked. Only the second shows that Mail.Read was still on Invoice helper at 02:44, and that a service principal sign-in succeeded at 02:31 with no user on the row. The first costs you the mailbox. On the night this is real, Invoice helper still authenticates to Graph after devon.p's password is reset, and a reader in March thinks the revoke ended access to that mail.
A password reset does not remove an application permission
Priya is looking at the user blade. The token she means is devon.p's refresh token. Mail.Read on Invoice helper is an application permission. The app requests a token as itself. Revoke sessions sets the user's refresh-token time. It does not delete a permission on a service principal, and it does not disable the account that consented the app. The plan already named those two steps. A password reset is not a substitute the plan wrote.
An Okta group edit that leaves an AWS role session running is a different object, in the group-edit post. That session belongs to a role the user assumed before the group change. This sitting starts after the password is already reset. The object still listed is the application permission. Whether the break-glass vault opens without Okta is a different sitting again, in the break-glass post. This one does not open a vault.
Revoke sessions is the user, not the app
The 02:31 row has no user because the sign-in is the service principal. A reader who only checks devon.p's sign-in log after 02:22 can honestly say the user has not signed in again, and still miss the app. The plan asked for every application that account consented that day. Invoice helper is that application. Noor owns the consent policy and is not in the room. Write the absence on the same lines as the permission. Do not smooth it into a sentence that says the account was secured.
If the plan's takeover steps name a password and do not name application permissions, run the free plan self-check before the next sitting. It asks whether the last test produced findings with owners, and whether they were closed. Noor's follow-up is that finding. A line that says the account was secured is a record you can produce, and it is the wrong one.
What the packet records
Write the grant in the free evidence template: the plan sentence, the 01:47 sign-in, the 01:51 consent, client id ending 4f6c2d1, application permission Mail.Read, the password reset and session revoke at 02:22, the 02:31 service principal sign-in with no user, that devon.p stayed enabled, that nobody opened Enterprise applications, and that Noor was absent, with the follow-up date. Hang the inject on the business email compromise family in the scenario library. That family walks a vendor bank-detail change, a CEO-impersonation wire, a recall race, and mailbox compromise. It does not have a minute where a password reset and a session revoke are written down while an application permission still has Mail.Read. Add this minute. Do not fold it into a line that says the account was secured. Put the file in the evidence index on the row for that exercise, with the date and the owner, so the next questionnaire finds the permission you did not open. The evidence template sits with the other record formats in the template library.
The record shows that these named people left Mail.Read on Invoice helper and wrote that the account was secured. It does not show that the 02:31 sign-in read a message, and it does not show that deleting the service principal would have made the next sign-in fail. Those are a check of the tenant after the permission is gone. This file is the permission they did not open.
Bottom line: write the client id and the application permission that is still consented. Secured is the smoothed version. The packet has to show the grant.