MFA coverage gaps are now a compliance and insurance risk

At a glance

What this is: This is an analysis of how MFA enforcement gaps are becoming a regulatory, insurance, and breach-risk problem across modern identity environments.

Why it matters: It matters because IAM teams now need provable MFA coverage across apps, browser-based access, and edge cases, not just stated policy compliance.

By the numbers:

• 2 in 5 of these accounts are missing MFA, and many also have a password vulnerability.
• A 1,000 user organization has over 15,000 accounts with various configurations and associated vulnerabilities.
• Roughly 20-25% of cyber insurance premiums are dictated by the security controls in place.

👉 Read Push Security's analysis of MFA regulation, insurance, and browser attacks

Context

MFA is a control for verifying that a user is who they claim to be, but the control only works when it is actually enforced across every access path. In practice, organisations often have partial coverage, with browser-based SaaS logins, legacy exceptions, and app-specific gaps leaving identity surface area exposed.

This article treats MFA as a governance issue, not just an authentication setting. That matters for human IAM programmes, because regulators and insurers increasingly want evidence that MFA is present, consistent, and defensible across the full identity estate, not simply documented in policy.

Key questions

Q: How should security teams handle MFA gaps across SaaS applications?

A: Security teams should treat SaaS MFA as a coverage problem, not a single control deployment. The priority is to identify every login path, including browser-based access, exceptions, and legacy applications, then close the gaps with enforced policy and evidence. If you cannot show where MFA is missing, you cannot prove the control is reliable.

Q: Why do missing MFA controls create both breach and insurance risk?

A: Missing MFA increases the chance that stolen credentials or browser-based attacks will succeed, but it also creates a governance problem after the fact. If an organisation attested that MFA was in place and later cannot prove it, insurers may dispute coverage and auditors may treat the control as ineffective.

Q: What do teams get wrong about MFA compliance?

A: Teams often mistake a written policy for actual enforcement. The common failure is assuming that if MFA is enabled somewhere, it is enabled everywhere that matters. In modern SaaS estates, partial coverage leaves enough gaps for attackers and enough ambiguity for auditors to challenge the programme.

Q: Who is accountable when MFA was claimed but not enforced?

A: Accountability usually sits with the identity, security, and risk owners who certified the control without verifying coverage. In regulated environments, the relevant frameworks expect evidence, not intention, so ownership should include continuous validation of MFA enforcement and exception handling.

Technical breakdown

Where MFA coverage breaks across the modern identity surface

Modern MFA failure usually comes from uneven enforcement rather than a single broken control. Enterprises have many apps, many login methods, and many identity exceptions, so the practical gap appears where teams cannot see every browser-based authentication path. SaaS sprawl, ghost logins, and app-specific sign-in flows create pockets where MFA is missing even though the programme appears covered on paper. The result is a control that looks mature in policy but remains incomplete in operational reality. Practical implication: build visibility first, then close the gaps that exist outside central identity tooling.

Practical implication: build visibility first, then close the gaps that exist outside central identity tooling.

Why regulators now treat MFA as an enforceable control

Regulatory language has moved beyond vague security hygiene. Some regimes now explicitly require MFA for remote or administrative access, while others use broader safeguards language that auditors increasingly interpret as MFA expectations when risk is clear. That means compliance evidence matters as much as deployment. If an organisation cannot show where MFA is enforced, exemptions were approved, and edge cases were controlled, it may fail audit scrutiny even if the policy says MFA is standard. Practical implication: map MFA requirements to each control framework and retain evidence of enforcement, not just configuration intent.

Practical implication: map MFA requirements to each control framework and retain evidence of enforcement, not just configuration intent.

How browser-based attacks change the MFA threat model

Browser access has become a primary attack path because it sits between users and the SaaS applications that now hold core business data. Adversaries no longer need to attack the network perimeter first. They target identities, password reuse, session tokens, and consent flows that let them bypass or outlast MFA in the browser. This shifts the problem from static access policy to runtime identity abuse across the web session. Practical implication: pair MFA coverage with browser-layer detection for session theft, phishing, and access anomalies.

Practical implication: pair MFA coverage with browser-layer detection for session theft, phishing, and access anomalies.

Threat narrative

Attacker objective: The attacker aims to gain durable access to SaaS-backed business systems while bypassing or outlasting identity controls.

1. Entry occurs through a browser-facing identity gap, such as missing MFA on a SaaS login or a compromised credential that can be replayed where enforcement is inconsistent.
2. Escalation follows when the attacker uses that access to reach business applications, and the lack of strong second-factor enforcement allows the session to survive long enough for data access or control manipulation.
3. Impact lands in the form of ransomware, account takeover, or denied-insurance exposure when the organisation cannot prove that MFA was actually enforced on the compromised access path.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA is no longer a policy statement, it is a provable control boundary. The article reflects a broader shift in identity governance: control claims now need operational evidence. Regulators and insurers are both asking whether MFA exists everywhere it should, not whether it exists in principle. For practitioners, that means the programme question changes from deployment coverage to enforcement proof.

Coverage gaps expose the weakness of browser-era IAM assumptions. A programme designed around centrally managed, predictable application access breaks down when users authenticate through scattered SaaS and browser flows. This is not just incomplete deployment. It is a governance model that assumes the identity surface is smaller and more stable than it really is. Practitioners should treat browser access as a primary identity control plane, not a side channel.

Assumed MFA coverage was designed for visible, centrally governed login paths. That assumption fails when identities authenticate across hundreds of SaaS apps, browser sessions, and exception-heavy workflows. The implication is not just to add more MFA, but to rethink how enforcement, auditability, and exception management are governed across the full access surface.

Insurance is now functioning as a governance pressure test for identity controls. The Hamilton case shows that an attested control can become a liability if it cannot be demonstrated after a breach. This creates a discipline-wide lesson for human IAM and NHI programmes alike: unproven access controls are no longer an internal gap, they are an external financial exposure. Practitioners need to assume scrutiny will extend from policy to evidence.

Browser-based identity control gap: The most useful concept in this article is that MFA weakness now emerges where browser-mediated access escapes central visibility. That gap is the point where attackers operate, insurers evaluate claims, and auditors test governance maturity. Practitioners should treat that gap as an identity risk surface in its own right.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• In the same research, 45% of organisations cited lack of credential rotation as the top cause of NHI-related attacks, which shows how governance failures accumulate across identity controls.
• For a broader lifecycle view, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs explains how provisioning, rotation, and offboarding shape exposure over time.

What this signals

Browser-first identity is now a control plane, not an access convenience. The practical implication for IAM teams is that MFA coverage cannot be measured only at the IdP. If SaaS access, browser sessions, and delegated logins are outside your visibility, your programme is already operating with blind spots that regulators and insurers are increasingly willing to challenge.

The broader signal is that identity assurance is becoming evidence-based. Organisations that cannot show where MFA is enforced, where it is exempted, and how exceptions are monitored will find that policy language carries less weight than operational logs and control proofs.

This also changes the audit conversation for NHI and human identity programmes alike. Access controls that are not continuously verifiable become liability points, especially where browser-based attacks and SaaS sprawl widen the space between stated policy and real enforcement.

For practitioners

• Map MFA enforcement across the real application estate Inventory every SaaS, browser login flow, and exception path so you can see where MFA is missing or bypassed. Focus on accounts that access business-critical systems outside the main identity stack.
• Separate policy claims from proof of enforcement Document where MFA is mandatory, where it is optional, and where compensating controls exist, then retain evidence that those settings were active during the relevant period.
• Prioritise browser-based telemetry for identity risk Monitor session hijacking, consent phishing, password spraying, and anomalous login patterns at the browser layer so that identity abuse is detectable before downstream impact occurs.
• Test insurance and audit assumptions before a breach Validate that your attested MFA coverage matches reality, because missing enforcement can affect claims, audit findings, and liability after an incident.

Key takeaways

• MFA gaps are now a governance and evidentiary problem, not just an authentication weakness.
• The scale of modern SaaS estates makes partial enforcement dangerous because attackers only need one uncovered path.
• Practitioners should prioritise continuous visibility, proof of enforcement, and browser-layer monitoring before the next audit or incident.

Key terms

• Multi-Factor Authentication Coverage: The portion of an organisation's identity surface where MFA is actually enforced, not merely available in policy. Coverage matters because exceptions, legacy flows, and browser-based logins often create gaps that attackers exploit and auditors later question.
• Browser-Based Identity Risk: Risk that arises when users authenticate and access SaaS applications through the web browser, where session theft, phishing, and consent abuse can bypass or outlast traditional perimeter controls. It is increasingly the practical frontline for identity attacks.
• Control Evidence: Proof that a security control was active, correctly configured, and enforced at the time it mattered. In identity governance, evidence is what turns a policy statement into something auditors, insurers, and incident responders can rely on.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Push Security: MFA regulators, insurers, and policy-makers are getting stricter on MFA requirements. Read the original.