Why do MFA and SSO not fully cover browser-based identity attacks?

Why This Matters for Security Teams

MFA and SSO improve login assurance, but browser-based identity attacks often happen after the user is already authenticated. That shifts the risk from password theft to session abuse, delegated access abuse, and token replay. Attackers exploit consent screens, device code flows, malicious extensions, and stolen browser sessions because those paths inherit trust from the original sign-in.

For security teams, the problem is that authentication success is not the same as identity assurance for the rest of the session. Current guidance suggests treating browser runtime state, token scope, and delegated grants as first-class security signals, not just the initial login event. NHI Management Group’s Ultimate Guide to NHIs shows how quickly compromised identities can be operationalized once trust is established. Browser attacks follow the same pattern: once a session is valid, the attacker is inside the control plane.

This is why teams also need to understand post-authentication abuse patterns described in the 52 NHI breaches Analysis and correlate them with browser telemetry, not just IdP logs. In practice, many security teams encounter this only after a consent grant, token theft, or extension abuse has already produced a durable foothold.

How It Works in Practice

Browser identity attacks succeed by targeting the components that MFA and SSO usually do not continuously re-validate. A user may complete a legitimate sign-in, then unknowingly authorize an OAuth app, accept a device code prompt, or load a compromised extension that reads session cookies and tokens. The browser becomes the enforcement layer, which means identity risk moves into the session, the token cache, and the consent boundary.

Practically, defenders need to look at four control points:

• Session lifetime and token scope, especially for high-privilege browser sessions.
• OAuth app consent and delegated permission review, including admin consent where applicable.
• Browser extension governance, because extensions can observe pages, requests, and tokens.
• Step-up checks for risky actions, not just for initial sign-in.

OAuth and browser-session abuse are now well documented in public guidance from CISA cyber threat advisories, while threat reporting such as the Anthropic report on AI-orchestrated cyber espionage shows how quickly attackers chain valid access into broader operational use. For browser identity, that means continuous evaluation matters more than a one-time MFA challenge.

Current best practice is evolving toward session-bound policy, device trust, and runtime risk scoring tied to the browser context. These controls tend to break down in unmanaged endpoints with weak extension governance and permissive consent workflows, because the browser can become a trusted execution surface even when the user never intended to grant it that level of access.

Common Variations and Edge Cases

Tighter browser controls often increase user friction and administrative overhead, requiring organisations to balance stronger session security against productivity and support costs. That tradeoff is real, especially in environments where teams rely on third-party SaaS, federated identity, and bring-your-own-device access.

There is no universal standard for this yet, but current guidance suggests treating a few scenarios differently. First, device code phishing can bypass many user-awareness controls because the user is completing a legitimate flow on the wrong device. Second, consent abuse can be subtle when the malicious app requests low-friction scopes that later expand its usefulness. Third, session hijacking remains dangerous even when MFA is strong, because the attacker may inherit an already trusted session rather than replaying the login.

For organisations mapping this risk, the relevant lesson in NHIMG research is that identity compromise is often operational, not theoretical. The Ultimate Guide to NHIs — Why NHI Security Matters Now and Top 10 NHI Issues both reinforce the same operational pattern: once identity is compromised, the blast radius comes from what the session can do next, not from how the user logged in.

Browser-based attacks are hardest to contain when high-value apps trust SSO blindly, consent is broadly granted, and session monitoring is absent.

Related resources from NHI Mgmt Group

• Why do browser-based attacks create extra risk for NHI and human identity programmes?
• Why do browser-based attacks need different hunting controls than endpoint threats?
• Why do endpoint tools miss so many browser-based account takeover attacks?
• Why do indicator-based detections fail against modern identity attacks?