MFA protects interactive sign-in, but it does not stop a user from granting consent to a malicious app that can mint access tokens. Those tokens may allow mailbox access, rule changes, file access, or even account takeover if the scopes are broad enough. The real risk is delegated access created by user approval, not password theft.
Why MFA does not govern consented access
MFA answers a narrow question: “Did the right person complete an interactive sign-in challenge?” It does not answer whether that person should be allowed to grant a third-party app ongoing access. Once a user approves consent, the security boundary shifts from login to delegated authorization, which is why a phishing-resistant sign-in can still end in mailbox abuse or data exfiltration.
That distinction matters because business email compromise often succeeds without stealing a password at all. A malicious integration can request scopes that let it read mail, create forwarding rules, access files, or act through the mailbox after the user’s session ends. The danger is not authentication failure, it is over-broad delegated access that MFA never evaluates.
A useful way to think about this is that consent creates a token-bearing relationship, not a one-time login event. If the app is untrusted, over-scoped, or hidden behind a convincing user prompt, the attacker gains durable access until the grant is revoked, regardless of how strong the original MFA challenge was.
What the integration abuse path looks like in practice
In most cases, the attacker uses social engineering, a spoofed OAuth screen, or a legitimate-looking productivity tool to persuade the user to approve access. The user sees a routine sign-in and consent flow, but the app then receives access tokens with the permissions the user granted. That token can be used directly against email or adjacent cloud services without further MFA prompts.
For defenders, the important operational signal is that abuse may show up as normal-looking OAuth activity rather than obvious credential theft. Review of app consent, token issuance, mailbox rule creation, and unusual third-party access is often more valuable than chasing failed login attempts. In other words, the compromise path is authorization abuse, not broken authentication.
This is why controls around consent scope, app allowlisting, and admin approval matter so much. If every user can approve high-impact permissions, one click can create a delegated access path that is harder to spot and harder to unwind than a stolen password. NHIMG’s Ultimate Guide to Non-Human Identities is useful here because the same lifecycle issues, excessive privilege, and third-party exposure patterns that affect service credentials also appear in consented app access.
What practitioners should verify before trusting MFA as a control
What to verify: Confirm whether your tenant allows user-consented third-party apps, what scopes they can request, and whether mailbox or file permissions can be granted without admin review. If the answer is yes, MFA is only protecting the sign-in step, not the downstream access path.
Decision rule: Treat any app that can request mail, file, directory, or offline access as a privileged integration. Require approval, logging, and periodic review for those grants, and remove stale consents as part of identity hygiene rather than after an incident.
Common mistake: Teams often assume “MFA enabled” means “BEC resistant.” That is only true when the main risk is interactive account takeover. If the main risk is malicious consent, token misuse, or over-scoped delegation, the control objective has to move to consent governance and delegated access monitoring.
Practitioner takeaway: The control gap is not the MFA prompt, it is the permission grant that follows it. If an app can obtain tokens with broad scopes, then the real defensive question is whether users are allowed to create durable access relationships without meaningful review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Consent grants token-bearing access that needs lifecycle control and revocation discipline. |
| NHI-02 — Privileged Access and Least Privilege | Over-scoped integrations create delegated privilege beyond interactive MFA protection. | |
| NHI-05 — Lifecycle and Offboarding | User-approved integrations must be discoverable and revocable when risk changes. | |
| Recommendation — Restrict and review app grants that can mint access tokens with broad scopes. Apply least privilege to third-party app scopes and require approval for high-impact permissions. Inventory, recertify, and revoke stale third-party consents and tokens. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | The issue is access governance after authentication, not sign-in alone. |
| DE.CM — Continuous Monitoring | Abuse often appears as OAuth and mailbox-rule activity rather than login failure. | |
| Recommendation — Enforce access governance for delegated app permissions, not just MFA at login. Monitor consent events, token issuance, and rule changes for anomalous delegated access. | ||
| CIS Controls v8 | 6 — Access Control Management | User-consented integrations need controlled approval and periodic access review. |
| 8 — Audit Log Management | Detection depends on logs for consent, token use, and mailbox-rule creation. | |
| Recommendation — Restrict third-party app consent and periodically review granted access. Collect and review logs for app consent, token activity, and suspicious mailbox changes. | ||
| NIST SP 800-63 | 5.1.3 — MFA and Authenticator Binding | Shows MFA protects authentication, but not delegated authorization granted afterward. |
| Recommendation — Pair MFA with consent controls because strong authentication alone does not prevent token-based abuse. | ||
| MITRE ATT&CK | T1528 — Steal Application Access Token | Malicious consent commonly leads to token-based mailbox and cloud access. |
| Recommendation — Hunt for application token theft and abuse when third-party consent is granted. | ||
Related resources from NHI Mgmt Group
- Why do legacy MFA and conditional access controls still fail to stop business email compromise in cloud environments?
- Why do third-party email gateways lose effectiveness against business email compromise and vendor fraud?
- Why does MFA still fail to stop account compromise in environments with weak credentials and social engineering?
- Why do the CIS Controls help organizations reduce ransomware, business email compromise, and third-party attack risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
