Who is accountable when phishing-resistant MFA remains only partial across a financial estate?

Why This Matters for Security Teams

Partial phishing-resistant MFA is not a checkbox problem, it is a control integrity problem. In a financial estate, the risk is concentrated where legacy users, service desks, privileged admins, and customer-facing workflows still accept weaker factors or fall back to recovery paths that can be phished. NIST’s NIST SP 800-63 Digital Identity Guidelines make clear that assurance depends on the strength of the authenticators used in practice, not the policy statement on paper.

That is why accountability lands on the identity and application owners who approved exceptions, plus the business and risk owners who allowed those exceptions to persist. In financial services, incomplete coverage often hides in remote access, contractor onboarding, call-centre resets, and privileged workflows where phishable factors remain easier to support than stronger controls. NHIMG has repeatedly documented how attackers exploit identity gaps after compromise, including in the Microsoft Midnight Blizzard breach, where identity weaknesses became an operational path rather than a theoretical issue. In practice, many security teams discover accountability only after a fraud event, credential abuse case, or audit finding has already forced the gap into view.

How It Works in Practice

Accountability should be traced to the control owner for each covered population and workflow, not diluted across the enterprise. That means separating three questions: who approved the control design, who accepted the residual risk, and who owns the systems where phishing-resistant MFA is still incomplete. The strongest programmes map these decisions to named owners, expiry dates for exceptions, and evidence that every critical access path can actually enforce resistance to phishing. NIST SP 800-53 Rev. 5 reinforces this style of accountability through access control and identification/authentication controls, while NIST SP 800-63 focuses on authenticators and assurance levels rather than vague “MFA enabled” claims.

In practice, teams should verify coverage across:

• employee, contractor, and third-party identities
• privileged admin access and break-glass flows
• help-desk recovery and account reset processes
• customer, partner, and API-facing sign-in paths
• legacy applications that still rely on SMS, OTP, or knowledge-based recovery

For financial estates, the hard part is usually not the modern SSO layer, it is the long tail of inherited applications and exception-driven access paths. NHIMG’s The State of Secrets in AppSec shows how fragmented security operations can become when controls are spread across many systems and owners, which is a useful analogue for MFA coverage gaps. If a control can be bypassed through a legacy app, a service-desk reset, or a privileged fallback route, then the enterprise has not achieved operational coverage even if headline adoption looks high. These controls tend to break down when authentication is federated across many inherited platforms because exception handling, not architecture, becomes the real source of exposure.

Common Variations and Edge Cases

Tighter phishing-resistant MFA coverage often increases operational friction, so organisations have to balance user experience, fraud reduction, and application compatibility. Current guidance suggests that partial deployment is acceptable only as a temporary transition state, not as a steady-state control posture. The main edge case is break-glass access: some financial institutions keep limited non-resistant paths for recovery or emergency operations, but those paths need stronger monitoring, step-up approval, and rapid review because they are predictable targets.

Another exception is customer authentication, where older channels may remain in service for regulatory or accessibility reasons. That does not remove accountability. It means product owners and risk owners must document why the weaker path exists, what compensating controls are in place, and when it will be retired. The same principle applies to machine-to-machine and administrator workflows where MFA may not be the primary protection mechanism, but phishing-resistant auth should still govern interactive access to consoles and sensitive data. The Zacks Investment Research breach is a reminder that identity failures often cascade across multiple systems once an attacker gets a foothold. Organisations that cannot prove which workflows remain partial usually cannot prove who owns the risk either.

Related resources from NHI Mgmt Group

• Who should own phishing-resistant MFA governance across the identity programme?
• How should security teams implement phishing-resistant MFA across multiple IAM systems?
• Who is accountable when phishing-resistant authentication is inconsistent across systems?
• Who is accountable when weak MFA remains enabled after a phishing incident?