An adversary-in-the-middle phishing page can relay a legitimate sign-in and capture a resulting session artifact. MFA may have succeeded while the attacker still obtains a way to reuse the session. The useful response is to identify the access path and its controls, rather than treating “MFA enabled” as the end of the assessment.
Match the control to the access path
| Control | What to check | Limit to account for |
|---|---|---|
| Phishing-resistant authentication | The required strength and actual user method | Registration alone does not enforce a policy |
| Device requirements | Which apps and devices must satisfy the access policy | Coverage and exceptions need validation |
| Token Protection | Supported resource, platform and application | It does not cover every browser or application |
| Detection and response | An alert reaches an accountable reviewer | A licensed detection is not a staffed response service |
Microsoft’s Token Protection documentation now includes limited browser support in preview for selected applications accessing Azure Resource Manager, alongside supported native-app resources. Do not describe it as protecting every browser session, or as having no browser support at all. Check the current Token Protection support matrix for the exact scope.
A password reset is not a complete containment check
Password changes and administrator resets affect token classes differently. Microsoft’s refresh-token revocation matrix distinguishes password-based tokens, non-password cookies and other sessions. Avoid claiming that a reset either ends all access or never revokes anything.
Use an authorized response runbook: block or disable compromised access as appropriate, revoke sessions, address affected devices and investigate persistence. Existing access tokens and application-owned sessions may require additional action or time. Verify containment using Microsoft’s access-revocation guidance and the affected application’s controls.
Check what could outlive the stolen session
- Unexpected authentication methods or credential changes.
- New application consent or permissions.
- Mailbox forwarding, inbox rules and delegated access.
- Other affected users, devices and sessions.
- Emergency-access arrangements and the evidence needed before restoring normal access.
These checks need an incident owner and appropriate authorization. A public checklist cannot determine which accounts to disable in a specific live system. Preserve relevant evidence and record what was changed, when and by whom.
For preventive work, start with a bounded pilot
Agree representative allowed and denied sign-ins. Check emergency access and reporting before enforcement. Document exceptions with owners and review dates. A tenant-wide policy should not go live merely because a test administrator can sign in.
The MFA and Conditional Access hardening scope covers agreed preventive changes and validation. Device-code phishing is a separate authentication path to include in the review.
Know which accounts are properly protected, and be able to prove it.
We review sign-in controls, agree pilot changes and validate the allowed and denied access paths. Active compromise needs a separately authorized response scope.