How should security teams handle MFA gaps across SaaS applications?

Why This Matters for Security Teams

MFA gaps across SaaS are rarely a single missed setting. They usually reflect inconsistent identity coverage across native login, federated access, admin paths, service accounts, and exception workflows. That makes the problem operational, not just architectural. Current guidance from the NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward governance, asset visibility, and continuous control verification rather than one-time deployment.

For SaaS, the risk is that a user can appear protected by MFA in one path and remain reachable through another. That is how attackers turn weak coverage into full account takeover, especially when legacy apps, break-glass accounts, or app-specific credentials bypass the main IdP. NHI Management Group research on the Ultimate Guide to NHIs shows that only 20% of organisations have formal offboarding and revocation processes for API keys, which is a reminder that identity control often fails at the edges, not the center. In practice, many security teams discover MFA gaps only after a SaaS compromise forces a manual inventory of every login path.

How It Works in Practice

Handling SaaS MFA gaps starts with mapping every authentication path and proving which ones are actually enforced. That means documenting IdP-initiated login, SP-initiated login, local SaaS credentials, mobile access, API-based access, break-glass accounts, contractor access, and any legacy or embedded flows. Teams should then compare each path against policy, since “MFA enabled” in a console does not guarantee enforcement everywhere.

The practical control model is simple:

• Require MFA at the identity provider where possible, not just inside the SaaS tenant.
• Block alternate sign-in methods unless there is an approved exception with an expiry date.
• Use conditional access for device, location, and risk-based enforcement where the SaaS app supports federation.
• Maintain a control inventory that records each app, each login method, and the evidence proving MFA enforcement.
• Test for bypasses using disabled users, legacy protocols, and direct URL access rather than relying on configuration screenshots.

This is where identity governance and incident lessons converge. The Salesloft OAuth token breach and Microsoft Midnight Blizzard breach both illustrate how trust assumptions around access paths can fail when credentials, tokens, or delegated access are not tightly governed. For SaaS MFA, evidence matters as much as enforcement: teams should be able to show policy, exception handling, and test results for each critical app. These controls tend to break down in mixed environments where legacy authentication, tenant-to-tenant federation, and business-owned exceptions are allowed to persist without expiry.

Common Variations and Edge Cases

Tighter MFA enforcement often increases helpdesk load, application friction, and business resistance, so organisations have to balance security coverage against operational continuity. That tradeoff is especially visible in SaaS estates with acquired applications, partner logins, or older products that do not support modern federation.

There is no universal standard for this yet, but current guidance suggests treating exceptions as time-bound risk decisions rather than permanent architecture. If a SaaS app cannot support enforced MFA through the IdP, security teams should classify it as a higher-risk application, add compensating controls, and track a remediation plan. Where service accounts or automation identities are involved, MFA is usually the wrong control entirely; those flows need workload identity, scoped tokens, and lifecycle controls instead.

NHI Management Group research shows that 97% of NHIs carry excessive privileges and 71% are not rotated within recommended time frames, which matters because SaaS access often blends human and non-human paths in the same platform. The practical edge case is a shared SaaS tenant where humans use MFA and automated integrations do not. In that environment, teams should separate controls by identity type, use strong inventory discipline, and avoid assuming that human MFA coverage automatically extends to integrations or delegated OAuth apps.

Related resources from NHI Mgmt Group

• How should security teams prove MFA compliance across all applications?
• How should security teams inventory webhook integrations across SaaS applications?
• How should security teams detect lateral movement across SaaS applications?
• How should security teams handle cloud secrets that are shared across applications and pipelines?