Many organizations assume that once multi-factor authentication (MFA) is deployed, the risk of account compromise drops to an acceptable level. For cloud services, this is largely true: according to Microsoft, enabling MFA for cloud identities prevents the vast majority of automated account takeover attempts. However, in Windows and Active Directory (AD) environments, attackers still gain access daily using valid usernames and passwords—and often do so without triggering any MFA challenge at all.
How Windows Authentication Bypasses Cloud MFA
Modern enterprises typically run a hybrid identity architecture. A cloud identity provider (IdP) such as Microsoft Entra ID (Azure AD), Okta, or Google Workspace protects SaaS applications and federated sign-in with MFA and conditional access. At the same time, a large portion of everyday authentication in Windows networks still relies on traditional AD protocols—Kerberos and NTLM—which do not inherently integrate with the cloud IdP and therefore do not invoke MFA.
On-premises logons and domain controllers
When a user signs in directly to a domain-joined workstation or server, the authentication request is processed by an on-premises AD domain controller. Unless Windows Hello for Business, smart cards, FIDO2 security keys or similar technologies are enforced, that logon effectively relies on a single factor: the password (or its hash). From the domain controller’s perspective this is a routine Kerberos or NTLM request, and cloud MFA policies are never consulted.
As a result, once an attacker obtains a password or NTLM hash—through phishing, malware, or credential dumping—they can authenticate to domain-joined systems and move laterally, completely bypassing cloud-based MFA that protects only web apps and SSO portals.
RDP and VPN: high-value entry points without MFA
Remote Desktop Protocol (RDP) and virtual private networks (VPNs) remain among the most targeted entry points into Windows environments. Even if RDP is not directly exposed to the internet, adversaries often reach it after an initial foothold and then use it for lateral movement. A direct RDP session to a server typically uses domain credentials and does not flow through the cloud IdP, meaning the session can be established without MFA.
To close this gap, many organizations deploy tools that enforce MFA at the Windows logon, RDP, and VPN level, and that can also protect offline logons with one-time codes. Solutions in this category, such as Specops Secure Access, make a single stolen password insufficient to access the operating system itself.
NTLM, pass-the-hash, and legacy authentication risk
NTLM, while officially deprecated in favor of Kerberos, is still widely used for legacy compatibility. NTLM is attractive to attackers because it enables pass-the-hash attacks: instead of knowing the clear-text password, an adversary can simply reuse the captured NTLM hash to authenticate.
In such scenarios, MFA provides no protection. If the system accepts the hash as proof of identity, no additional factor is requested. NTLM authentication is often buried inside internal services, legacy applications, and old integrations, and its presence is frequently rediscovered only during incident response or security audits.
Kerberos tickets and long-term persistence in AD
Kerberos is the primary authentication protocol in Active Directory. Here, the focus of attacks shifts from passwords to Kerberos tickets. With access to the memory of a compromised host or a highly privileged account, adversaries can steal or forge tickets, including “golden ticket” and “silver ticket” attacks that are well documented in offensive security frameworks.
These techniques allow attackers to maintain long-term, stealthy access and move through the environment with fewer interactive logons, reducing the likelihood of detection. In some cases, even rotating passwords does not fully eradicate the threat if a domain controller or key distribution center (KDC) has been compromised and its secrets remain under attacker control.
Local admins, SMB, and service accounts: internal blind spots
Many organizations still rely heavily on local administrator accounts for workstation support and break-glass access. When the same local admin password is reused across many devices, compromising one machine can quickly lead to compromise of dozens or hundreds. These local logons are validated on the endpoint itself and therefore bypass MFA and conditional access logic in Entra ID.
The SMB protocol, used for file sharing and remote administration, remains a reliable channel for lateral movement. With valid credentials, attackers can use administrative shares (such as C$) and remote command execution to pivot across the network. MFA is almost never applied at the SMB level because this traffic is considered “internal” and trusted.
Service accounts pose another significant risk. They run services, scheduled tasks, and integrations, often with broad privileges and non-expiring passwords. Because their authentication is automated and many legacy systems cannot handle modern protocols or MFA prompts, they frequently fall outside standard monitoring and password hygiene practices.
Strengthening Windows and Active Directory authentication
First, organizations should implement a modern password policy for Active Directory. Long passphrases (15+ characters), strict prevention of password reuse, and blocking of predictable patterns are now considered baseline. Credential stuffing attacks are fueled by billions of leaked passwords available to attackers, so real-time checks against breached password lists are critical.
Specialized products such as Specops Password Policy extend native Microsoft capabilities. Features like breached password protection compare AD passwords against large datasets of previously compromised credentials—often billions of records—and alert or block users who choose exposed passwords.
Second, it is essential to reduce NTLM usage. This requires discovering where NTLM is still in use, disabling it where feasible, hardening configurations where it must remain, and monitoring for suspicious NTLM traffic. At the same time, Windows authentication should be treated as its own attack surface, with MFA enforced at OS logon, RDP, and VPN through dedicated solutions rather than relying solely on cloud MFA for web access.
Finally, administrative and service accounts should be managed as high-risk assets: maintain an accurate inventory, apply least privilege, enforce frequent and automated password rotation, remove unused accounts, and closely monitor logons and behavior patterns associated with these identities. Organizations that extend their MFA strategy beyond cloud applications to encompass on-prem Windows and AD authentication—from password policy and NTLM control to MFA at logon and RDP—significantly reduce the likelihood of successful credential-based attacks and build a more resilient identity security posture.
