How should security teams enforce MFA across browser-based SaaS and AI apps that do not support native controls?

Security teams should enforce MFA at the browser layer where native app controls are incomplete or inconsistent. That approach closes coverage gaps across third-party SaaS, shadow apps, and AI tools while preserving visibility into who accessed what and when. The practical test is simple: if an app cannot enforce MFA itself, the control should move to the access path instead.

Why This Matters for Security Teams

Browser-based SaaS and AI tools often sit outside the control plane that security teams rely on for MFA enforcement. When the app cannot natively challenge the user, the access path becomes the real control point. That matters because modern incidents frequently begin with stolen sessions, over-permissive browser access, or third-party OAuth paths rather than password reuse alone. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports strong identity assurance, but the implementation problem is that many SaaS and AI services do not expose the knobs needed to apply it consistently.

NHIMG research shows the operational gap clearly: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps in The State of Non-Human Identity Security by Astrix Security & CSA. That is a browser-path and token-path problem as much as an identity problem. Recent incidents such as the Salesloft OAuth token breach and the Microsoft Midnight Blizzard breach show how quickly access can be abused when control is not enforced at the entry point.

In practice, many security teams encounter this only after a token, session, or browser extension has already provided access to systems that were assumed to be protected by MFA.

How It Works in Practice

Browser-layer MFA enforcement works by moving the control to a place the app cannot bypass. Instead of depending on every SaaS or AI vendor to support native MFA, the organisation requires authentication at the browser, secure access proxy, identity-aware gateway, or managed browser layer before the user reaches the app. The key design goal is to verify the user and the device once, then continuously govern access through policy rather than trusting the destination app to do it.

This approach is strongest when it is paired with device posture checks, conditional access, and session controls. A browser policy can require phishing-resistant MFA, block unmanaged devices, limit copy and paste, or force re-authentication for sensitive actions. That is especially relevant for AI apps, where users may upload sensitive data into prompts or connect personal accounts without any native enterprise control. For broader identity context, NHIMG’s State of Non-Human Identity Security highlights how limited visibility into third-party access creates blind spots that browser enforcement can partially reduce. For credential hygiene, the State of Secrets in AppSec also shows how fragmented secret handling and weak practices increase downstream exposure.

• Use the browser or access gateway as the enforcement point when the SaaS or AI app lacks native MFA.
• Require strong authentication before session issuance, not after the app is already open.
• Bind sessions to device posture and re-check risk on sensitive actions.
• Prefer phishing-resistant methods where possible, then fall back to step-up MFA for exceptions.
• Log access at the browser layer so security teams can see which user, device, and app were involved.

This guidance tends to break down in unmanaged BYOD environments and consumer browser workflows because the organisation cannot reliably control the session boundary or the client state.

Common Variations and Edge Cases

Tighter browser enforcement often increases friction, requiring organisations to balance stronger access control against user experience and support overhead. That tradeoff is real, especially when employees access a mix of managed SaaS, shadow AI tools, and legacy web apps from different devices.

There is no universal standard for this yet, but current guidance suggests three common patterns. First, for managed devices, enforce MFA through a secure browser, identity-aware proxy, or endpoint-integrated access policy. Second, for unmanaged devices, use step-up authentication and restrict high-risk actions rather than granting full interactive sessions. Third, for high-risk AI workflows, combine browser MFA with strict upload, download, and session recording controls so the browser becomes the trust boundary, not the app itself.

Edge cases usually appear when vendors support only partial SSO, when sessions are long-lived, or when OAuth grants outlive the interactive login. Those scenarios are where browser MFA alone is not enough, because a valid session token can still bypass the user prompt. The DeepSeek breach and BeyondTrust API key breach reinforce the same lesson: access control must cover the full session lifecycle, not only the login page.

For teams standardising controls, NIST SP 800-53 Rev 5 Security and Privacy Controls remains the right baseline, but the practical implementation should assume that many browser-based apps will never support strong native MFA on their own.

Related resources from NHI Mgmt Group

• How should security teams govern local AI apps that bypass browser-based controls?
• How should security teams reduce browser-based identity compromise across SaaS apps?
• How should security teams implement lineage-based controls for AI artifacts across notebooks, registries, endpoints, and SaaS?
• How should security teams govern browser-based AI agents in SaaS environments?