Who is accountable when MFA was claimed but not enforced?

Why This Matters for Security Teams

When MFA is claimed but not actually enforced, the problem is not just a missed setting. It is a control assertion failure that can invalidate access reviews, audit evidence, and risk decisions across identity, cloud, and application layers. Security teams often discover the gap only after an incident or failed verification, not during normal governance. That is why evidence-backed control testing matters, as reflected in the NIST Cybersecurity Framework 2.0, which emphasizes continuous improvement and verifiable outcomes. In NHIMG research, the Microsoft Midnight Blizzard breach and the Schneider Electric credentials breach both reinforce a familiar pattern: once identity protections are assumed rather than validated, adversaries can move faster than internal accountability processes can react. In practice, many security teams encounter the MFA gap only after privileged access has already been abused, rather than through intentional control validation.

How It Works in Practice

Accountability usually follows control ownership, but enforcement responsibility is shared. Identity engineering may configure MFA, application owners may rely on a federated identity flow, and security/risk owners may certify compliance. If MFA is “claimed,” the accountable parties are the ones who approved the control state without verifying that enforcement existed for all relevant paths. That includes bypass routes such as legacy protocols, service accounts, break-glass access, API-authenticated sessions, and IdP exceptions. Practically, teams should separate policy declaration from policy proof:

• Define where MFA must apply, including admin portals, VPN, SSO, and privileged workflows.
• Test enforcement from the user and attacker perspective, not only from the IdP console.
• Track exceptions with expiry dates, compensating controls, and named owners.
• Continuously sample logs and authentication events to confirm actual MFA prompts and success signals.
• Use control evidence in reviews, not screenshots or attestation alone.

This aligns with the broader identity governance mindset in The State of Secrets in AppSec, where confidence often exceeds actual control strength. It also maps to the evidence-driven posture of NIST Cybersecurity Framework 2.0 and the operational lessons in NHIMG coverage of the DeepSeek breach, where exposed credentials and weak control boundaries compounded exposure. These controls tend to break down in hybrid estates where federated identity, local admin access, and legacy authentication coexist because enforcement is fragmented across multiple trust domains.

Common Variations and Edge Cases

Tighter MFA enforcement often increases user friction and exception handling overhead, requiring organisations to balance stronger assurance against operational continuity. There is no universal standard for this yet, so current guidance suggests treating high-risk access differently from low-risk access. A few edge cases change how accountability is assigned:

• For third-party identity providers, the application team may own the integration, but the security team still owns validation of the relying party configuration.
• For break-glass accounts, MFA may be intentionally bypassed, but that exception must be documented, monitored, and time-bound.
• For machine-to-machine access, MFA is usually the wrong control; workload identity and short-lived tokens are more appropriate than human authentication factors.
• For delegated admin models, accountability can split between platform owners and business system owners, which makes evidence collection even more important.

The best practice is evolving toward continuous control monitoring, because manual attestations do not distinguish between “MFA enabled somewhere” and “MFA enforced everywhere it matters.” Where environments include legacy protocols, shared admin accounts, or fragmented federation, claimed MFA often fails at the exact point an attacker tests the boundary.

Related resources from NHI Mgmt Group

• Who is accountable when a breach exposes data through missing MFA?
• Who is accountable when a browser extension is repurposed for content injection?
• Who is accountable when SOX remediation keeps recurring every quarter?
• Who is accountable when offboarding leaves access behind?