An identity-provider sign-in record shows MFA satisfied by a claim in the token. What does that assert?

## What the field is saying Identity providers record, per sign-in, both what was **required** (single-factor, multi-factor) and how the requirement was **met**. When the detail reads along the lines of *"MFA requirement satisfied by claim in the token"*, with an authentication method of *"previously satisfied"*, the provider is telling you something precise and easily misread: > The credential presented at this sign-in already contained an assertion that a multi-factor authentication happened **at some earlier point**, and that assertion was accepted. No factor was exercised here. The multi-factor claim is a **record of a past act, carried forward inside a token**. It is not an observation of the present one. ## Why this is not an edge case The overwhelming majority of sign-ins in a modern estate are **non-interactive**: a client silently exchanges a refresh token for a new access token, a session cookie is presented to a web application, a desktop client renews on a timer. Every one of those produces a record that says the multi-factor requirement was satisfied by a claim. The estate would be unusable if it did not. Which is exactly why the same record shape is what **token theft looks like**. In an adversary-in-the-middle phish, the victim is proxied to the genuine provider, authenticates for real, approves a genuine multi-factor prompt — and the proxy captures the resulting session artefact. The attacker replays it. The provider sees a valid credential bearing a valid multi-factor claim and honours it. There is no failed logon, no second prompt, and nothing anywhere that looks like a defeated control. ## The four things that actually discriminate 1. **Device identity.** Was the sign-in from a registered, compliant device with a device identifier the tenant knows, or from an unrecognised device or none at all? 2. **Network origin.** A new IP address, a new autonomous system, a hosting provider or anonymising service rather than a residential or corporate range. 3. **Client application and user agent.** A client the user has never used, or a client that does not match the platform the user works on. 4. **The minting event.** Work backwards: which interactive sign-in could have produced this token? If there is a genuine interactive sign-in on the user's own device shortly before, that is the moment the claim came from — and it is also the moment the artefact was most likely stolen. If there is no plausible minting event at all, the token's provenance is unexplained, and that is a finding. ## Direction of every claim here - A successful sign-in proves **a credential was accepted**, not that a person authenticated. - A multi-factor claim proves **a factor was exercised at some earlier time**, not that it was exercised now. - A user confirming "yes, I approved a prompt this morning" **corroborates the earlier act** and says nothing about who holds the resulting token. In a proxied phish, the user's genuine approval is precisely what the attacker needed. - The **absence** of a second prompt proves nothing about legitimacy. Not prompting on refresh is the design, not a failure. ## Why the source is unusually trustworthy One real strength: these records are written by the identity provider, not by the endpoint. An adversary with administrative control of a laptop can clear a Windows Security log, but cannot edit the provider's sign-in history. When endpoint telemetry is suspect, the identity provider's account of which credentials were accepted, from where, for which application, is often the most reliable narrative you have — provided you are collecting both interactive and non-interactive sign-ins, because many teams collect only the interactive ones and then wonder why the timeline stops. ## The evidentiary consequence If the credential in play is a token rather than a password, then password-centric reasoning is simply about the wrong object. A password change does not, by itself, retire an already-issued refresh token or session artefact — deciding what must be invalidated, and in what order, is a containment call for the incident lead. Evidentially, your job on this record is narrower and clearer: state that the accepted credential was a bearer artefact carrying a prior multi-factor claim, name the device and network context that make its provenance implausible, and identify the interactive sign-in it most likely descends from.