Who is accountable when SMS MFA fails and an account is taken over?

Accountability sits with the organisation that chose the assurance model, not with the attacker or the carrier alone. If the business relies on SMS for sensitive access, security, IAM, and application owners all share responsibility for the risk acceptance and the recovery design.

Why This Matters for Security Teams

SMS MFA fails in a predictable way: the organisation still bears the accountability for choosing an assurance method that can be intercepted, SIM-swapped, socially engineered, or bypassed through account recovery. That means the issue is not only authentication failure, but governance failure across risk acceptance, support workflows, and recovery design. NIST’s NIST Cybersecurity Framework 2.0 treats this as a managed risk problem, not a carrier problem.

The practical lesson is that SMS MFA is often deployed as a convenience control, then later relied on for sensitive access without revisiting the threat model. That mismatch becomes visible in real incidents, including identity-driven compromises documented in the Microsoft Midnight Blizzard breach, where recovery and identity assurance choices became part of the blast radius. Security, IAM, and application owners all influence the outcome because they shape what recovery paths exist and how much privilege they protect.

In practice, many security teams encounter the accountability question only after an account takeover has already forced incident response, legal review, and customer notification.

How It Works in Practice

Accountability should follow control ownership. If SMS MFA is approved for a user population, the business owner, IAM team, and application owner all share responsibility for the decision to allow that factor, the conditions under which it is permitted, and the fallback process when it fails. The carrier may be a technical dependency, but it is not the control owner. The same logic applies to recovery: if a help desk can reset MFA or replace a phone number, then recovery is part of the trust boundary and must be governed as such.

Good practice is to map the full authentication path, not just the login step. That includes enrollment, recovery, number change workflows, step-up access, and support exceptions. Organisations should define which accounts can use SMS, which require stronger factors, and which require phishing-resistant methods instead. Current guidance suggests treating SMS as lower assurance for sensitive access, especially where privileged, financial, or administrative actions are involved.

• Assign an explicit control owner for MFA policy, not just an IAM implementer.
• Document who accepts the risk of SMS and who approves exceptions.
• Harden recovery with identity verification, audit trails, and supervisor approval for high-risk accounts.
• Use stronger methods for privileged access and step-up decisions.

NHIMG’s analysis of the DeepSeek breach shows how exposed credentials and weak identity controls can rapidly widen impact once attackers get a foothold. This aligns with NIST’s identity and access emphasis and the risk-management approach in the NIST Cybersecurity Framework 2.0. These controls tend to break down in high-volume service desks because exception handling becomes the easiest path around the intended assurance model.

Common Variations and Edge Cases

Tighter MFA assurance often increases support friction, so organisations have to balance usability against takeover resistance. That tradeoff is real, and there is no universal standard for every user group yet. A customer-facing portal, a payroll system, and a privileged admin console do not deserve the same authentication strength, even if they share the same identity platform.

One important edge case is outsourced support. If a third-party service desk can reset SMS MFA or approve recovery, accountability extends through the contract, the operating procedure, and the audit trail. Another is shared devices and number recycling, where the original phone number may no longer belong to the account holder. In those cases, SMS fails not only as a factor but as a durable binding between person and device.

For organisations with mature identity programs, the better question is not whether SMS ever fails, but which accounts remain exposed because policy still permits it. NHIMG’s coverage of the Microsoft Midnight Blizzard breach is a reminder that attackers often target the surrounding recovery and support process, not just the login screen. The accountability answer therefore remains with the organisation that designed and approved the assurance model, even when the technical failure appears to originate elsewhere.

Related resources from NHI Mgmt Group

• Who is accountable when weak MFA leads to account compromise?
• Who is accountable when zero-trust controls fail to reduce access over time?
• Who is accountable when layered security fails but identity trust was never rechecked?
• Who is accountable when segregation of duties fails in accounts receivable?