Not always. Where core applications, sovereignty rules, cost, or connectivity prevent migration, banks can add compensating controls on top of AD. The decision should be based on whether the current architecture can meet evidence and enforcement requirements, not on whether cloud migration is fashionable.
Why replacing Active Directory is not the real MFA decision
The practical question is whether your current directory and access architecture can enforce phishing-resistant authentication, step-up checks, and auditable exception handling. In many banks, active directory remains part of that control plane, while MFA is delivered through stronger sign-in methods, conditional access, privileged access controls, and compensating monitoring.
That means the migration decision is usually about control effectiveness and evidence, not about treating AD as automatically incompatible with modern MFA.
Where banks get this wrong is assuming that a directory platform choice alone satisfies the security requirement. MFA depends on how authentication is enforced across user populations, admin paths, legacy apps, VPNs, and recovery flows. If those enforcement points are inconsistent, replacing AD can move the problem without fixing it.
What matters more than the directory brand
Start with the authentication paths that matter most: workforce sign-in, privileged access, remote access, and application-to-application trust. A modern bank can keep AD and still raise assurance by using phishing-resistant methods, tightening recovery, and removing legacy authentication where possible. NHIMG’s Workforce Identity Security Guide is useful when you need to separate sign-in hardening from directory replacement.
For high-risk accounts, the harder issue is not whether MFA exists, but whether it can be bypassed through help desk resets, legacy protocols, token theft, or weak exceptions. That is why banks should test evidence of enforcement, not just policy statements.
Compensating controls are legitimate when migration is constrained by core systems, sovereignty, or connectivity. In those cases, the objective is to reduce the residual attack surface around AD and prove that the bank can still meet the required assurance level. Strong MFA guidance is still useful here, and NIST’s Digital Identity Guidelines help frame authenticator strength and assurance, while the OWASP ASVS gives a control-oriented view of authentication and session requirements.
When replacement is justified, and when it is not
Replacing AD makes sense when the current architecture cannot enforce the required MFA posture for critical users and systems, or when legacy dependencies make assurance too fragile to sustain. It is less about fashion and more about whether the directory boundary is limiting policy enforcement, telemetry, or privileged access segmentation.
If the bank can isolate legacy estates, enforce phishing-resistant MFA for administrators, and wrap compensating controls around the remaining AD-dependent workloads, replacement may be unnecessary. If it cannot, then the migration business case becomes a security case as well.
The risk is not just account compromise. In financial environments, a weak directory or weak sign-in chain can become a path to lateral movement, privilege escalation, and broad operational disruption. NHIMG’s MFA Guide and Passwordless and Passkeys Guide show why phishing-resistant methods are often the real control objective, regardless of whether AD remains in place.
Risk and Threat Considerations
Banks face a concentration risk when Active Directory becomes the trust anchor for too many access paths, especially if older sign-in methods, synchronized credentials, or recovery channels still exist. Attackers rarely need a full directory replacement problem; they look for one weak path into the authentication estate and then expand from there.
Failure mechanism: Weak MFA coverage, legacy authentication, or over-permissive recovery processes can let an attacker turn one compromised credential or session into broader access across remote access, admin tooling, or connected cloud services.
Impact: The result can be account takeover, privileged access abuse, service disruption, and a control failure that is harder to defend with policy than with architecture.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Sets authenticator assurance and phishing-resistant sign-in requirements for MFA decisions. |
| Recommendation — Use phishing-resistant authenticators and assurance levels to validate whether current access paths meet bank requirements. | ||
| OWASP ASVS | V6 — Authentication | Directly addresses authentication strength, MFA, and login controls for applications and sessions. |
| Recommendation — Verify that authentication flows enforce MFA, session binding, and recovery protections across critical applications. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Applies to workforce authentication controls when banks assess whether AD can meet MFA requirements. |
| IA-5 — Authenticator Management | Covers lifecycle controls for authenticators, secrets, tokens, and recovery material. | |
| Recommendation — Enforce strong identification and authentication for organisational users across all high-value access paths. Control issuance, rotation, revocation, and recovery for authenticators and related credentials. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supports access governance, least privilege, and account control decisions around directory-based access. |
| Recommendation — Review and restrict access paths so directory and MFA controls are enforced consistently. | ||
Practitioner Guidance
What to verify: Test whether MFA is enforced at every high-value entry point, including VPN, admin portals, privileged sessions, and account recovery. If any path falls back to weaker methods, treat that as a control gap rather than a user-experience issue.
Decision rule: If AD can still support phishing-resistant MFA, strong recovery controls, and auditable exceptions for the bank’s critical workflows, do not force a wholesale replacement. If it cannot, migration becomes a security control decision, not just an infrastructure program.
What good looks like: The bank can prove that access to sensitive systems requires strong authentication, that exceptions are tracked, and that legacy dependencies are isolated with a clear decommission path.
Practitioner takeaway: Replace Active Directory only when it blocks enforceable assurance; otherwise, modernise the authentication layer around it and measure whether the control actually holds under failure and attack conditions.
Related resources from NHI Mgmt Group
- How should security teams govern Active Directory service accounts?
- Why does MFA for Active Directory reduce breach risk beyond just meeting compliance requirements?
- How should banks strengthen Active Directory security without moving to cloud identity?
- How should teams enforce MFA consistently across Active Directory accounts?