How should security teams defend against authorization phishing when passkeys and MFA are already in place?

Teams should treat passkeys and MFA as authentication controls, not complete protection against post-login abuse. Authorization phishing targets OAuth consent, device code, and token exchange flows after login succeeds. The right response is browser-layer detection, device code flow restrictions where feasible, scoped conditional access, and validation through live simulations. Security teams should assume authentication strength alone does not close the attack path.

Why This Matters for Security Teams

Passkeys and MFA reduce password theft, but they do not stop authorization phishing after a session is established. Attackers increasingly aim at consent screens, device code entry, and token exchange because those flows can turn a legitimate login into delegated access. That makes the problem closer to post-auth session abuse than classic credential theft, and it is why browser-layer controls and policy enforcement matter.

The gap is especially visible in OAuth-connected environments where third-party apps, copilots, and automation tools can request broad scopes with a few clicks. NHI Management Group research on the State of Non-Human Identity Security found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly the kind of blind spot authorization phishing exploits. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access control must cover the full lifecycle, not just the initial login event.

In practice, many security teams discover the issue only after a user has already granted an unsafe app access or a token has already been minted.

How It Works in Practice

Defence starts by treating authorisation as a separate control plane from authentication. Passkeys prove the user is present, but they do not prove that a requested consent is safe. Security teams need layered controls that inspect the browser session, constrain risky flows, and verify the legitimacy of the transaction at the moment it happens.

Useful controls include limiting or disabling device code flows where the business does not need them, applying scoped conditional access to high-risk apps, and blocking consent to unapproved OAuth applications. Browser telemetry can help detect patterns such as suspicious consent prompts, unusual redirect chains, or token-grant activity that occurs immediately after login. For environments that rely heavily on Microsoft and Google ecosystems, incident patterns described in NHIMG research such as CoPhish OAuth Token Theft via Copilot Studio and the Microsoft Midnight Blizzard breach show how legitimate identity systems can still be abused after the primary login succeeds.

• Use allowlists for OAuth apps and admin consent workflows for anything outside approved business domains.
• Require step-up checks for high-risk consent grants, especially when scopes include mail, files, directory, or offline access.
• Monitor device code usage and alert on long-lived or repeated code-entry attempts.
• Run live simulations that test consent phishing, not just password or MFA bypass scenarios.

CISA cyber threat advisories consistently show that identity compromise often becomes a foothold for broader access, which is why validation must happen continuously rather than only at sign-in. These controls tend to break down in highly federated SaaS environments because consent decisions, token issuance, and app governance are spread across multiple admins and platforms.

Common Variations and Edge Cases

Tighter consent controls often increase user friction and administrative overhead, requiring organisations to balance attack resistance against the need for legitimate app onboarding. That tradeoff becomes sharper in engineering, research, and automation-heavy teams where OAuth apps, service integrations, and AI assistants are part of normal work.

Current guidance suggests treating device code flow as a high-risk pattern rather than a universally bad one. It can be necessary for some headless or constrained devices, but it should be restricted, monitored, and time-boxed. The same applies to admin consent: best practice is evolving, but broad tenant-wide consent without review is increasingly viewed as unacceptable in mature environments. For teams dealing with autonomous tooling or agent-driven workflows, the boundary between user consent and workload delegation can blur, which makes post-login abuse harder to spot.

That is why validation should include live attack-path testing against the actual identity stack, not only policy review. Cases involving delegated mailbox access, token replay, or app-to-app privilege chaining often expose gaps that static policy documents miss. The challenge is well illustrated by NHIMG reporting on the DeepSeek breach, where exposed secrets and broad access surfaces created opportunities beyond simple login compromise.

Security teams should assume passkeys narrow one attack path, but do not close the authorisation phishing path when consent and token handling remain too permissive.

Related resources from NHI Mgmt Group

• How should security teams defend against phishing kits that steal MFA tokens and cookies?
• How should security teams defend against live phishing panels that intercept MFA codes?
• How should security teams defend against AItm phishing that steals a session after MFA succeeds?
• How should security teams handle stolen OAuth tokens when MFA is already in place?