Who is accountable when organisations keep using weak second-factor methods that are known to be vulnerable?

Why This Matters for Security Teams

Weak second-factor methods are not just an implementation flaw; they are a governance decision with real exposure across fraud, account takeover, and control failure. When a team continues to accept an authentication method that is known to be phishable, interceptable, or recoverable through social engineering, the issue moves beyond user convenience and into risk acceptance. NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that authentication controls must be selected and maintained as part of a broader control environment, not treated as a one-time technical setting.

The practical problem is that many organisations inherit second-factor methods from legacy deployments and then leave them in place long after attacker tradecraft has moved on. That creates a gap between policy language and actual assurance. In fraud-heavy environments, weak second factors can also undermine step-up checks, reset flows, and help desk identity proofing, which means the weakness spreads into adjacent processes. For that reason, accountability belongs to the organisation’s governance chain, including security leadership, IAM owners, and the risk function, because they own the choice to retain the method and the decision not to replace it.

In practice, many security teams encounter this only after account compromise or payment fraud has already shown that the “second factor” was never much of a factor at all.

How It Works in Practice

In operational terms, accountability should be assigned to the party that approves, deploys, and tolerates the control. That usually includes the control owner, IAM architects, security governance, and sometimes business leaders if they accepted a convenience-driven exception. If a weak method is still in production, the question is not only whether it works technically, but whether it remains defensible against current phishing, SIM swap, push fatigue, or relay attacks. Guidance from NIST SP 800-63B Digital Identity Guidelines is especially relevant here because it distinguishes between authenticator types and their resistance to replay and interception.

A practical review usually starts with four checks:

• What second-factor method is in use, and is it resistant to phishing or interception?
• Who approved the method, and is there a documented risk acceptance or exception?
• What compensating controls exist, such as device binding, step-up verification, or transaction monitoring?
• Does the method still align with the threat model, user population, and regulatory obligations?

Where organisations have mature identity governance, weak methods are measured against fraud telemetry, help desk abuse trends, and incident data, then retired in phases. Where governance is weak, teams often assume the mere presence of a second factor equals strong assurance. That assumption is especially dangerous when the factor can be approved by call center staff, replayed through proxy phishing kits, or bypassed in account recovery. The decision should also be mapped to broader control expectations in the CISA Zero Trust Maturity Model, because identity assurance is only one part of a larger access trust posture.

These controls tend to break down in high-volume customer environments where shared support processes, recovery shortcuts, and legacy applications prevent consistent enforcement of stronger authenticator options.

Common Variations and Edge Cases

Tighter authentication controls often increase user friction and support cost, requiring organisations to balance assurance against operational continuity. That tradeoff is real, especially for consumer services, frontline staff, or regulated workflows where a full migration can take time. The important point is that convenience is not a defence for keeping a method that the organisation already knows is weak.

There is no universal standard for when every weak method must be removed, but current guidance suggests treating the highest-risk methods as candidates for rapid phase-out and documenting any temporary exception with an explicit expiry date. In some cases, a weaker method may remain acceptable for low-risk access while stronger controls protect privileged actions, payment changes, or sensitive profile updates. In others, the right answer is to eliminate the method entirely and move to phishing-resistant options, stronger recovery controls, and better transaction-level monitoring. The CISA Zero Trust Maturity Model is useful here because it frames identity assurance as a layered capability rather than a single checkbox.

This issue also intersects with Non-Human Identity governance when service accounts, API access, or automation use weak shared secrets and “second factor” language is applied loosely. In those cases, accountability still sits with the organisation that chose the control model, but the remediation path may involve secret rotation, workload identity, or stronger attestation rather than user-facing MFA. For audit teams, the key question is whether the control owner can show a documented rationale, an exception review cycle, and a migration plan. Where those elements are missing, the organisation is not managing a compensating control; it is simply deferring a known weakness.

Related resources from NHI Mgmt Group

• What breaks when organisations keep using shared API keys for machine-to-machine access?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?