Who is accountable when scam losses are not blocked by weak authentication?

Why This Matters for Security Teams

When scam losses are not blocked, the failure is rarely just “bad MFA” or a single missed alert. It is usually a control design problem: the authentication method did not match the transaction risk, the approval path was too permissive, or the institution could not prove that access decisions were proportionate to the loss exposure. That shifts accountability upward into governance, not just operations, especially where reimbursement rules apply.

Security teams should read this through the lens of control adequacy, not incident optics. NIST SP 800-53 Rev. 5 makes access control and authentication a measurable control family, while ISO/IEC 27001:2022 expects risk treatment and accountability to be assigned, monitored, and reviewed. In real cases, weak authentication often becomes visible only after funds have moved, as seen in the Schneider Electric credentials breach and the Twitter Source Code Breach, where identity control failures had broader operational consequences.

NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, which is a useful reminder that identity control gaps quickly become loss events. In practice, many security teams encounter accountability disputes only after reimbursement, regulatory reporting, or customer complaints have already forced the issue.

How It Works in Practice

Accountability starts with the regulated transaction type. If the organisation allows a high-risk payment, account change, or beneficiary update with authentication that is too weak for the fraud profile, the control failure is owned by the institution even if the scam was externally initiated. The operational question is whether the authentication strength, step-up logic, and anomaly detection were appropriate for the value at risk and the likely abuse path.

A defensible program usually combines several layers:

• Risk-based authentication that escalates verification when the transaction amount, payee novelty, device, or location changes.
• Strong customer authentication or step-up checks for sensitive actions, not just sign-in.
• Clear fraud, IAM, and payments ownership so that exceptions are reviewed before losses occur.
• Evidence retention showing what was checked, when it was checked, and who approved overrides.
• Control testing against current scam typologies, not only against generic account takeover scenarios.

This is where NIST SP 800-53 Rev. 5 is operationally useful because it treats authentication as part of a broader control system, not a one-time implementation. ISO/IEC 27001:2022 adds the management system expectation: controls must be risk-based, reviewed, and assigned to accountable owners. For institutions with significant identity sprawl, NHIMG’s Ultimate Guide to NHIs is also relevant because weak authentication is often compounded by exposed service accounts, stale secrets, and poor revocation hygiene that widen the blast radius of a successful scam.

Where this guidance breaks down is in legacy payment environments that cannot support step-up authentication, real-time risk scoring, or auditable exception handling without major system rework.

Common Variations and Edge Cases

Tighter authentication often increases friction, support burden, and abandonment, so organisations must balance fraud reduction against customer experience and operational cost. Current guidance suggests the tradeoff should be handled by tiering risk rather than applying the same control to every transaction.

One important edge case is authorised push payment fraud. The customer may have initiated the action, but the institution can still be accountable if its authentication and warning controls were not adequate for the transaction context. Another is delegated access or business banking, where role confusion can make it unclear whether the weakness sits with IAM design, fraud rules, or customer administration.

There is no universal standard for this yet across all jurisdictions, but best practice is evolving toward documenting why a given authentication strength was sufficient for a specific transaction class, then proving that decision with monitoring and review. That includes making sure exception paths are explicit and time-bound, not informal.

When institutions rely on static credentials, shared accounts, or out-of-band controls that are easy to bypass, accountability will usually land with the organisation because the control model itself was not fit for the scam pattern. For deeper identity control context, NHIMG’s research and the broader control expectations in NIST and ISO remain the most practical reference points.

Related resources from NHI Mgmt Group

• Who is accountable when a bank authorises a scam transaction with weak authentication?
• Who is accountable when a man-in-the-middle attack succeeds through weak authentication?
• Who is accountable when weak authentication leads to payment fraud?
• Who is accountable when weak authentication remains in place after a regulatory update?