business resources
Why Endpoint MFA Isn't Enough to Protect Active Directory
15 Jul 2026
Most organizations that have deployed MFA feel reasonably protected. They've added a second factor to their VPN, their remote desktop access, maybe their cloud applications. The authentication prompt appears, the user enters their code, and the session opens. The perimeter feels secured.
What often goes unexamined is what sits behind that perimeter. Active Directory — the directory service that manages identities, group memberships, access policies, and authentication for Windows-integrated services across the organization — continues to rely on password-based authentication for many directory operations, even in environments where MFA protects endpoints or remote access. Endpoint MFA doesn't change that. And attackers know it.
How Endpoint MFA Leaves AD Exposed
MFA deployed at the endpoint level works exactly as advertised: it secures the specific access point where it's installed. A Credential Provider on a Windows server secures that server's logon. A RADIUS proxy in front of a VPN gateway secures that VPN connection. But neither of these touches Active Directory directly.
Active Directory accepts authentication requests over LDAP and Kerberos. Any application, service, or tool with valid domain credentials — a username and password — can query the directory, authenticate users, enumerate group memberships, and traverse the trust relationships between domains. This is by design; it's how AD works.
The gap is straightforward: if an attacker obtains valid domain credentials, they can call AD directly, bypassing every endpoint MFA control you've deployed. The MFA prompt on the VPN never fires. The Credential Provider on the jump host never fires. The attacker authenticates to the directory itself with a username and password, and the directory responds normally.
This is not a theoretical attack path. It's the standard operating procedure for post-breach lateral movement in Windows environments.
How AD Credentials Get Compromised
Understanding why this matters starts with understanding how domain credentials are obtained in practice.
Credential stuffing and infostealers are the volume play. Verizon's 2025 Data Breach Investigations Report found that stolen credentials were the leading initial access vector for the second consecutive year, appearing in 22% of confirmed breaches. The infostealer picture is particularly telling: 30% of devices appearing in infostealer logs were corporate-managed endpoints — meaning malware ran on enterprise hardware and harvested saved credentials directly. Another 46% of compromised systems with corporate credentials in their data were unmanaged devices: BYOD laptops, personal machines used for work, home computers outside EDR visibility. These credentials end up in dark web marketplaces and get used against AD-backed login surfaces.
Pass-the-hash is the technique that makes endpoint MFA irrelevant in a different way. When an attacker compromises a Windows machine — through a phishing payload, a vulnerable service, or a supply chain compromise — they can extract NTLM hashes from memory using tools like Mimikatz without ever knowing the plaintext password. Windows NTLM authentication accepts the hash directly, so the attacker authenticates to other systems and to AD itself without a password. There's no MFA prompt in this flow because there's no password entry step.
Kerberoasting targets service accounts. Attackers with any valid domain credential can request Kerberos service tickets for accounts registered with Service Principal Names (SPNs) — which includes most service accounts in AD. Those tickets are encrypted with the service account's password hash and can be taken offline for cracking. Service accounts frequently have elevated privileges and weak passwords, making them a reliable escalation path.
Lateral movement via RDP is the connective tissue. Once an attacker has a working credential — harvested, cracked, or passed — they pivot from host to host using Remote Desktop. Mandiant's 2026 threat intelligence report (covering IR cases from 2025) found that RDP was used for lateral movement in approximately 85% of intrusions. Host-by-host, they work toward domain controllers, high-value servers, and eventually Domain Admin.
The common thread across all of these: endpoint MFA doesn't intercept the AD authentication that makes lateral movement possible. The directory is called directly, with credentials, and it answers.
AD attack | What it does | Why directory-level MFA stops it |
|---|---|---|
Credential stuffing | Reuses leaked passwords against AD-backed logins | OTP required at the directory, not just endpoints |
Pass-the-hash | Authenticates with a stolen NTLM hash | A stolen NTLM hash alone is not sufficient; authentication still requires a valid one-time password. |
Lateral movement via RDP | Pivots host-to-host with valid domain credentials | Every directory-level auth requires a second factor |
Kerberoasting | Cracks service account hashes offline | A cracked password alone is not sufficient; authentication still requires a valid one-time password. |
What Directory-Level MFA Actually Means
Protecting AD at the directory level means enforcing a second factor at the point where authentication actually happens — inside Active Directory itself, not on the application or endpoint that sits in front of it.
One approach that addresses this directly is Dynamic Strong Password Authentication (DSPA). Instead of adding an MFA layer to individual endpoints, DSPA operates at the AD/LDAP level by replacing static passwords with dynamic one-time passwords (OTP) generated using the TOTP algorithm. The static password ceases to function as a standalone credential; what the user actually authenticates with is a time-based code that changes on a configured interval. Because authentication depends on a time-based OTP generated by the registered authenticator, previously captured credentials quickly become unusable.
The practical effect on the attack scenarios above is significant. A harvested NTLM hash corresponds to the user's password at the time it was captured. If that password has been replaced by a dynamic OTP that changes every 30 seconds, the hash is stale before the attacker can use it. Credential stuffing against AD-backed login surfaces hits an OTP requirement instead of a static password check. Pass-the-hash attacks using extracted hashes find that the hash no longer corresponds to a valid current credential.
This is what a two-factor authentication for Active Directory solution at the directory level provides — protection that follows the credential itself, not just the access points that sit in front of it.
DSPA policies can be applied selectively by AD group, which matters operationally. Organizations can enforce directory-level OTP for privileged accounts and domain administrators first — the accounts most targeted in lateral movement scenarios — without touching the authentication flow for every user in the domain simultaneously.
Practical Considerations
A few implementation realities worth understanding before deploying directory-level MFA:
OTP time-step configuration. The administrator sets the interval at which OTPs rotate — 30 seconds is standard, but longer intervals (up to 600 seconds) are configurable for environments where users may have connectivity issues retrieving codes. Shorter intervals are more secure; longer intervals reduce authentication friction for specific use cases.
Group-based rollout. Applying DSPA selectively to AD security groups allows phased deployment. Start with privileged accounts and domain admins, validate the rollout, then extend to broader user populations. This reduces the risk of a large-scale authentication disruption during initial deployment.
Centralized deployment. Traditional endpoint- and application-level MFA often requires dedicated components for Windows logon, RDP, OWA, ADFS, and other services. With DSPA, MFA is enforced centrally through Active Directory, eliminating the need for separate deployments for each AD-integrated authentication flow.
Authentication methods. DSPA uses time-based one-time passwords generated by the Protectimus SMART authenticator app or delivered through Protectimus BOT. Because DSPA supports configurable OTP rotation intervals beyond the standard 30- or 60-second TOTP time steps, OATH hardware tokens are not supported.
Related deployment scenarios. Directory-level MFA is designed to protect Active Directory authentication. Organizations that need MFA for Windows logon and RDP can use the Protectimus Winlogon component, which supports OATH hardware tokens alongside software authenticators.
Compliance Standards That Point Here
Three frameworks are worth noting in this context:
NIST SP 800-63B AAL2 requires two distinct authentication factors for access to sensitive systems. Directory-level MFA based on TOTP helps organizations meet AAL2 requirements for multi-factor authentication.
NIS2 Directive (Article 21) requires essential and important entities to implement multi-factor or continuous authentication for access to network and information systems. Authentication that reaches Active Directory — which underlies many network resources in Windows environments — falls squarely within that scope.
ISO/IEC 27001:2022 (Annex A 8.5) calls for secure authentication controls for high-risk access scenarios, explicitly including privileged accounts. Privileged Active Directory accounts, such as domain administrators, authenticating to AD are exactly the accounts this control targets.
FAQ
Why isn't endpoint MFA enough to protect Active Directory?
Endpoint MFA secures the access point where it's deployed — a VPN gateway, a Windows server's login screen, a web application. It doesn't touch Active Directory directly. Attackers who obtain valid domain credentials can authenticate to AD over LDAP or Kerberos without going through any MFA-protected endpoint, bypassing every second-factor control that sits in front of the directory rather than inside it.
What is directory-level MFA?
Directory-level MFA enforces a second authentication factor at the Active Directory or LDAP layer itself — not on the applications or endpoints that use AD for authentication. The approach replaces static passwords with dynamic one-time passwords at the directory level, meaning any authentication attempt against AD requires a current, time-based OTP regardless of which application or service initiated it.
Does it work with on-premises Active Directory?
Yes. Directory-level MFA via DSPA integrates directly with on-premises AD without requiring Azure, Entra ID, or any cloud dependency. It works with standard on-premises domain controllers and also supports OpenLDAP and other RFC 4510-compliant LDAP directories.
Can MFA be required only for some AD groups?
Yes. DSPA policies apply selectively by AD security group. Organizations commonly enforce directory-level OTP for privileged accounts, domain administrators, and service accounts first, then extend to broader user populations as part of a phased rollout.
