The main failure is that authentication remains too easy to reuse and too hard to prove. Banks can still operate, but they lose a key control for demonstrating strong access governance, especially when auditors expect MFA evidence, contextual restrictions, and visibility over active sessions.
Why native MFA changes the control story in Active Directory
When active directory cannot enforce MFA on its own, the directory can still authenticate users, but it cannot by itself raise assurance at the point of login. That means password reuse, phishing, and token or session theft remain easier to exploit, and the organisation must rely on adjacent controls, such as federation, conditional access, or privileged access workflows, to close the gap.
The practical issue in regulated banking is not just whether users can sign in, but whether the bank can prove the sign-in was strong enough for the access being granted. MFA methods and bypass paths matter because the control failure is often at the assurance layer, not the directory layer.
Native MFA also affects how strongly the bank can separate ordinary access from privileged access. If the same directory path can be used for routine operations and sensitive admin activity, then step-up authentication, session revalidation, and device-based trust become harder to standardise, especially across legacy systems and hybrid estates.
Why audit evidence becomes harder to defend
Regulated banks do not just need secure access, they need repeatable evidence that access decisions are strong, contextual, and reviewable. Without native MFA in Active Directory, the audit trail often shifts from a direct directory control to a collection of compensating controls, which can be valid but is harder to explain, test, and evidence consistently.
That matters because auditors and internal control owners usually want more than a policy statement. They want proof of phishing-resistant sign-in where required, clear enforcement points for privileged users, and records that show which sessions were challenged or stepped up. Guidance in NIST SP 800-63 Digital Identity Guidelines is useful here because it ties assurance to authenticator strength and sign-in conditions, not just account possession.
In a banking environment, the absence of native MFA also makes it easier for control gaps to hide in exceptions. Service desks, remote access channels, break-glass accounts, and legacy admin paths can all remain technically functional while quietly weakening the evidence that a regulated access model is being enforced end to end.
Where the operational and compliance risk concentrates
The biggest concentration of risk is usually not the average user account, but the access paths that unlock production systems, finance workflows, and administrative change. If those paths depend on password-only authentication, then credential theft, MFA fatigue elsewhere in the estate, and replay of already-validated sessions become much more damaging.
That is why banks often treat missing MFA as a governance problem as much as an authentication problem. If the directory cannot natively prove stronger access at the right boundary, the bank must prove the compensating design, and the controls around that design, with much more discipline. PCI DSS v4.0 is a useful external benchmark for understanding how access restriction and account control expectations become more explicit when regulated environments handle sensitive data and privileged access.
Failure mechanism: password-based authentication stays reusable, replayable, and easier to phish or steal, while the bank loses a native control point for enforcing step-up checks and session assurance at the directory boundary.
Impact: control narratives become compensating-control heavy, privileged access is harder to demonstrate as strongly governed, and the organisation faces more friction in audits, exception handling, and incident review after account compromise.
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 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authenticator Assurance Level | Auth strength and phishing resistance are central to proving bank access. |
| Recommendation — Map sensitive access paths to the required assurance level and enforce stronger authenticators where risk is highest. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Bank staff AD logins depend on strong user authentication controls. |
| IA-5 — Authenticator Management | Missing native MFA pushes lifecycle and session trust into authenticator handling. | |
| Recommendation — Require strong identification and authentication for organizational users accessing regulated systems. Control authenticator issuance, rotation, recovery, and revocation for all high-value accounts. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Regulated banking needs governance over authentication material and login assurance. |
| Recommendation — Protect authentication information and define stronger authentication for sensitive access. | ||
| PCI DSS v4.0 | 8.4 — Multi-factor authentication for access into the cardholder data environment | Banks handling payment data need MFA at critical access boundaries. |
| Recommendation — Enforce MFA wherever access enters the cardholder data environment or other sensitive zones. | ||
Practitioner Guidance
What to verify: Distinguish between users who authenticate directly to Active Directory and users who are fronted by an identity provider, VPN, or privileged access layer. The important question is not whether MFA exists somewhere in the stack, but whether it is enforced where the regulated access decision actually happens.
Decision rule: If a production or privileged path can still succeed on password-only AD authentication, treat that as a control gap until a compensating design proves equivalent assurance, logging, and reviewability. If the path is only for low-risk access, document why the weaker control is acceptable and where the boundary begins.
What good looks like: Strong banking environments separate directory authentication from assurance enforcement, require step-up for sensitive access, and can show who authenticated, by what method, under what context, and with what session duration or reauthentication rule.
Practitioner takeaway: The absence of native MFA in Active Directory is not merely a convenience issue, it changes how the bank proves trust in access, so the real task is to make the compensating control chain as auditable as the login itself.
Related resources from NHI Mgmt Group
- How should security teams govern Active Directory service accounts?
- What breaks when MFA is the only control protecting Active Directory access?
- What breaks when attackers can abuse Kerberos delegation in Active Directory environments?
- Why does one-size-fits-all MFA often create more operational pain in Active Directory environments?