A consented third-party app read mail and an executive asks whether MFA held. How do you answer?

## Why the question comes to you in this form An executive asking "did MFA hold?" is asking whether the control the organisation paid for and enforced did its job. On a consent-grant case the answer is *yes* — and that answer, unqualified, is useless and slightly misleading. The value of your reply is in reframing which control was actually exercised, using records rather than opinion. ## The mechanism, in the terms the record uses 1. A user is led to a real consent page at the real identity provider — typically from a phishing message whose link is genuine. 2. The user authenticates normally. Multi-factor is required and satisfied. This sign-in is unremarkable and looks it. 3. The user is shown an application asking for **delegated permissions** — permissions to act *on behalf of the signed-in user* — including a scope that reads mail. 4. The user approves. The identity provider writes a **consent / permission-grant** entry: the consenting user, the application (its identifier, display name and publisher), the scopes, and whether the consent was granted for that one user or tenant-wide by an administrator. 5. The application receives its own tokens under that grant and refreshes them on its own schedule. It never authenticates as the user again, so it never meets a factor challenge and produces no interactive sign-in. The crucial distinction in the grant record is **delegated** versus **application** permissions. A delegated mail-read scope consented by one user reaches that user's mailbox. An **application** permission consented by an administrator acts as the app itself, with no user, and can reach **every** mailbox in the tenant. Same phrase in a headline, two entirely different incidents. ## What you can say from the records alone - **That it happened, and when** — the grant entry is timestamped and names the consenting principal. - **What was granted** — the scope list, which is the blast radius. - **How wide** — user consent for one account, or admin consent across the tenant. - **Who the grantee is** — the application identifier, its publisher and whether the publisher is verified; a recently registered application in an unfamiliar tenant with a plausible display name is the standard pattern. - **Whether other users consented to the same application** — the same identifier appearing across many grants turns one victim into a campaign. ## What these records cannot tell you The consent trail proves **capability was granted**, not that data was read. Reads land in the mail platform's own audit trail, attributed to the application's identity rather than to an interactive user session. If that trail is not enabled or not retained, the honest position is that the app *could* read the mailbox for the whole window and you cannot enumerate what it took. Equally important is what is **absent everywhere else**. There is no endpoint alert: nothing ran on the laptop. There is no network anomaly: the traffic is the user's browser talking to the real identity provider, then a cloud application talking to a cloud API from someone else's infrastructure. There is no failed logon, no impossible travel, no malware. A programme whose detection strategy is endpoint and network telemetry sees this attack **not at all**. It is visible only if the identity provider's audit and consent logs are collected, which is precisely the log source most often left out of the pipeline. ## Common misreadings worth pre-empting - **"MFA failed."** It did not. The user authenticated with a factor and then authorised an application. Reporting a factor failure sends people to fix the wrong control. - **"So the attacker has the password."** They do not, and they never needed it. No credential passed through them. - **"Then a password reset ends it."** A password change does not by itself retire a grant or the tokens issued under it — the grant is a separate object with its own lifecycle, and what to invalidate is a containment decision for the incident lead. Your contribution is the evidence: this is a grant, not a credential. ## How to answer the executive Short, ordered, and record-backed: authentication held and here is the sign-in that proves it; the exposure came from an authorisation the user granted; the grant covers these scopes for this application, consented at this time by these accounts; this is what the scopes could reach, and here is what our mail audit trail can and cannot say about what was actually read. Then say which of those statements rests on a log you have and which rests on a log you do not — an executive can act on a stated gap, and cannot act on a confident answer that turns out to be unsupported.