How should financial institutions close MFA gaps across legacy systems?

Why This Matters for Security Teams

Legacy MFA gaps are rarely just an authentication problem. In financial institutions, they become a control gap across payments, trading, customer servicing, admin consoles, and remote access paths that were built before phishing-resistant MFA was standard. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls treats access control as a baseline safeguard, but older platforms often cannot enforce modern methods without compensating layers.

The risk is not theoretical. NHIMG research on the Microsoft Midnight Blizzard breach and the Zacks Investment Research breach shows how identity weaknesses can be exploited when controls lag behind the threat. In financial environments, attackers do not need to defeat every system; they only need one weak access path to pivot into high-value data or privileged workflows. In practice, many security teams discover these gaps only after audit findings, fraud activity, or incident response has already exposed the weakness.

How It Works in Practice

The effective approach is to treat legacy MFA remediation as an identity modernization program, not a one-time hardening task. Start with a complete inventory of access paths: VPN, VDI, admin portals, batch jobs, privileged vendor access, and embedded authentication flows in older applications. Then classify each path by business criticality, user type, and whether the system can support phishing-resistant MFA such as FIDO2 or certificate-based authentication.

Where native support exists, prioritise migration to stronger methods aligned with NIST SP 800-63 Digital Identity Guidelines. Where it does not, create a formal exception with clear ownership, an expiry date, and compensating controls. Those controls typically include network segmentation, conditional access, device posture checks, tighter session timeouts, step-up authentication, PAM for administrative functions, and monitoring for anomalous use. For systems that expose shared accounts or service credentials, pair MFA remediation with secrets rotation and removal of standing access wherever possible.

• Use risk-based prioritisation to move the highest-value access paths first.
• Document every exception as temporary, reviewed, and tied to a remediation plan.
• Require stronger controls for privileged users and third-party access than for low-risk internal workflows.
• Track failed logins, impossible travel, and unusual session chaining as compensating detections.

NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, which matters because hidden non-human access often bypasses human MFA controls entirely and creates false confidence in the control environment. These controls tend to break down in mainframe-connected workflows and vendor-managed applications because authentication is often embedded in the platform design and cannot be upgraded without code changes or replacement.

Common Variations and Edge Cases

Tighter MFA enforcement often increases operational friction, requiring institutions to balance user experience, availability, and regulatory pressure against attack reduction. That tradeoff is especially sharp in payment operations, call centres, mergers and acquisitions, and regulated third-party integrations where outages carry direct financial impact. There is no universal standard for every legacy exception, but best practice is evolving toward explicit risk acceptance rather than informal tolerance.

Some systems can only be protected through wrapper controls, such as placing them behind an identity-aware proxy or restricting access to a hardened jump environment. In other cases, the right answer is decommissioning or migrating the application rather than continuing to compensate indefinitely. For shared service accounts, MFA is often not the primary control at all; instead, institutions should focus on least privilege, vaulting, rotation, and tight workload authentication. For high-risk users, phishing-resistant MFA should be the default, not a later-phase enhancement.

Financial institutions should also recognise that MFA is not a complete answer if session theft, token replay, or excessive privilege remains unchecked. The strongest programmes combine authentication with conditional access, strong governance, and reviewable exceptions. Where legacy cannot meet the bar, the exception should be short-lived and visibly tracked, not absorbed into normal operations.

Related resources from NHI Mgmt Group

• How should security teams close MFA coverage gaps across legacy and remote access systems?
• How should healthcare teams enforce MFA across legacy and cloud systems?
• How should security teams make NHI best practices usable across the business?
• How can organizations manage unauthorized agents in their systems?