MFA only strengthens the login step. Consent phishing abuses the authorized session after the user approves a malicious app, so the attacker inherits legitimate token-based access. The control gap is in delegated authorization, not authentication. Teams need consent review, app allowlisting, and token revocation because MFA cannot judge whether the requested permissions are safe.
Why MFA Cannot Decide Whether a Consent Grant Is Safe
MFA is designed to prove that the person at the keyboard is the right person. consent phishing bypasses that boundary by convincing the user to approve a malicious OAuth app, at which point the attacker operates through legitimate delegated access. That means the risk lives in authorization scope, token issuance, and app trust, not in the login ceremony. Guidance from NIST Cybersecurity Framework 2.0 still applies, but the control objective shifts from authentication hardening to application governance and access review.
This is why incidents such as the Microsoft Midnight Blizzard breach matter to defenders studying delegated access abuse: once a token is granted, the attacker no longer needs to defeat MFA again. In practice, many security teams encounter the blast radius only after a user has already approved an app that looked routine, rather than through intentional misuse of a login control.
How Consent Phishing Works in Practice
Consent phishing usually starts with a convincing prompt that asks for permissions an app does not need. The user sees a familiar identity provider screen, enters valid credentials, completes MFA, and then approves the app. From there, the attacker can use the resulting access token or refresh token to read mail, access files, or move into downstream systems, depending on the scope granted. That is why this pattern is so effective: it turns user trust into delegated privilege.
Security teams need to treat consent as an authorization event, not a one-time user action. Current best practice is to combine app allowlisting, admin consent workflows, publisher verification, and periodic review of OAuth grants. Where available, token revocation and conditional access policies should be triggered quickly when risky apps or unusual permissions are detected. The Schneider Electric credentials breach is a useful reminder that identity compromise often expands through legitimate access paths, not just password theft. For broader control design, NIST Cybersecurity Framework 2.0 supports governance around access, monitoring, and recovery, which maps well to consent abuse response.
- Review all third-party OAuth apps for publisher, scope, and business justification.
- Require admin approval for high-risk permissions such as mail, directory, and file access.
- Revoke suspicious refresh tokens and remove app grants immediately after detection.
- Log consent events and correlate them with impossible travel, new device, or unusual app behavior.
These controls tend to break down when organisations allow broad self-service app consent across large tenant populations because legitimate and malicious approvals become difficult to distinguish at scale.
Where Current Defenses Still Fail
Tighter consent controls often increase friction for legitimate SaaS onboarding, requiring organisations to balance user productivity against reduced attack surface. That tradeoff is real, and there is no universal standard for this yet, especially in environments that rely heavily on business-owned applications. The question is not whether all app consent should be blocked, but which permissions deserve pre-approval, which need human review, and which should never be user-consentable.
Another edge case is hybrid identity environments where the same user can approve apps in multiple tenants or across shadow IT tools. In those settings, MFA gives a false sense of closure because the attack may begin after the login has already succeeded. Better governance includes periodic consent recertification, monitoring for overbroad scopes, and fast removal of stale grants. The lesson from the Microsoft Midnight Blizzard breach and similar identity incidents is that token-backed access persists until someone actively removes it. Security leaders should align these controls with NIST Cybersecurity Framework 2.0 functions for Protect, Detect, and Respond, while using the Schneider Electric credentials breach as evidence that credential theft and delegated access abuse often converge in the same incident path.
In practice, the most resilient programmes do not assume MFA is a complete answer; they treat it as one layer in a broader consent, token, and app-trust control model.
FRAMEWORK_REFS—
[
{
“framework_code”: “NIST-CSF”,
“control_ref”: “PR.AC-1”,
“relevance_note”: “Consent phishing exploits granted access, so identity and access governance is central.”,
“framework_summary”: “Review app consent, token scope, and account trust as part of access control governance.”
},
{
“framework_code”: “OWASP-NHI”,
“control_ref”: “NHI-04”,
“relevance_note”: “Covers secret and token exposure after delegated access is granted.”,
“framework_summary”: “Inventory and revoke exposed tokens, then enforce least privilege on all non-human access paths.”
},
{
“framework_code”: “NIST-AIRMF”,
“control_ref”: null,
“relevance_note”: “Useful for governing decision-making and accountability around risky autonomous or delegated actions.”,
“framework_summary”: “Set oversight, monitoring, and escalation rules for all systems that can act without direct human review.”
}
]
