Who is accountable when organisations rely on SMS-based 2FA and later fall short of strong-authentication expectations?

Why This Matters for Security Teams

When an organisation chooses SMS-based 2FA, it is making a control decision, not outsourcing accountability to the end user. That matters because regulators, auditors, and incident responders judge the strength of the authentication program as a managed security control, especially where phishing, SIM swap, account takeover, or privileged access are in scope. Guidance in NIST SP 800-63 Digital Identity Guidelines and NIST SP 800-53 Rev 5 Security and Privacy Controls makes the core point clear: authentication assurance must match the risk of the transaction and the environment.

This is why weak-factor decisions become governance failures. SMS may improve over password-only access, but it is still exposed to number-porting fraud, message interception, and device compromise. In parallel, NHIMG research shows how often weak identity controls translate into downstream exposure: NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. The lesson is not that every weakness becomes a breach, but that control selection carries accountability when the expected assurance level is not met.

In practice, many security teams encounter this only after an audit exception, fraud event, or regulator question has already exposed the gap.

How It Works in Practice

Accountability usually sits with the organisation that approved the authentication method, defined the policy exception, and failed to enforce stronger assurance where required. Security, IAM, risk, and compliance functions each own part of that decision chain, but none of them can shift responsibility to users who merely followed the login flow presented to them. If SMS is allowed, it should be because the organisation has documented why the control is acceptable for that use case, and how residual risk is managed.

Operationally, strong programs treat authentication as a policy decision tied to application risk, user role, and data sensitivity. That means:

• mapping each application to an assurance requirement under NIST SP 800-63 Digital Identity Guidelines
• reserving SMS only for low-risk scenarios, if it is used at all
• using phishing-resistant methods for admin, finance, support, and regulated workflows
• documenting exception approvals, expiry dates, and compensating controls
• reviewing whether the method aligns with sector obligations and internal risk appetite

Where teams need a governance baseline, NHIMG’s Ultimate Guide to NHIs is useful because it frames authentication and credential management as lifecycle problems, not one-time configuration choices. The same logic applies to human access: controls must be selected, monitored, and retired as threat conditions change. That is especially true in environments with shared devices, remote access, service desks, or legacy identity platforms that still depend on phone-number ownership as a trust signal. These controls tend to break down when high-risk users are forced onto SMS because legacy applications cannot yet support stronger factors.

Common Variations and Edge Cases

Tighter authentication control often increases friction and rollout cost, requiring organisations to balance assurance against user impact, support load, and legacy compatibility. That tradeoff is real, but it does not remove accountability; it changes how the organisation must justify the control choice. Current guidance suggests that SMS should not be the default for high-risk access, yet there is no universal standard for every sector and application, so policy must be risk-based rather than one-size-fits-all.

Edge cases often arise when:

• a regulator expects phishing-resistant MFA but the application only supports SMS or email codes
• contractors, emergency users, or call-centre staff need temporary access and stronger factors are not immediately available
• consumer-facing services rely on phone-number verification but also handle sensitive transactions
• an organisation has inherited a legacy identity stack and is using SMS as a transitional control

In those situations, the right response is not to argue that the user accepted the prompt. The organisation should record the gap, set a migration plan, and implement compensating controls such as step-up authentication, transaction monitoring, and tighter session risk checks. The broader lesson from the Twitter Source Code Breach is that identity weaknesses rarely stay isolated; they become entry points into larger governance failures when ownership is unclear. There is no universal standard for SMS acceptability across every context, but there is clear accountability for choosing, approving, and defending the control.

Related resources from NHI Mgmt Group

• What do organisations get wrong about SMS-based 2FA and fraud risk?
• How should organisations manage short-lived certificates in certificate-based authentication?
• What breaks when organisations rely only on document imaging for remote onboarding?
• What is the difference between role-based access and API key governance for NHI security?