A Windows application can accept your credentials successfully while still using an authentication method your organization wants to retire. Understanding what NTLM is and how it works helps explain why these connections persist and how to assess them.
Quick definition: NTLM (New Technology LAN Manager) is a legacy Windows authentication protocol suite that uses password-derived material in a challenge-response exchange. It does not send the plaintext password across the network, but it can still be vulnerable to relay attacks and other credential-related risks.
This guide explains how NTLM verifies identity, how it differs from Kerberos, where its security risks arise, and how to reduce reliance on it without disrupting essential applications.
A Brief History of NTLM
NTLM evolved from earlier LAN Manager authentication methods used in Microsoft networking environments. At the time, challenge-response authentication was an improvement over approaches that exposed passwords more directly during network authentication. NTLM allowed a client to demonstrate knowledge of password-derived credentials without transmitting the plaintext password itself.
As Windows networking and Active Directory environments developed, Kerberos became the preferred authentication protocol for domain environments because it supports ticket-based authentication and mutual authentication. NTLM remained available for compatibility with older systems, local accounts, workgroups, and applications that could not use Kerberos.
NTLM Defined
NTLM is Microsoft’s legacy authentication protocol suite for Windows environments. It verifies identity using password-derived credentials without sending the plaintext password across the network. Password hashing transforms a password into a fixed-length value through a one-way function. NTLM uses material derived from that value to calculate an authentication response, rather than transmitting the password or its stored hash directly.
NTLM is not a general-purpose encryption protocol, and successful authentication does not automatically mean application traffic is encrypted. A message integrity code (MIC), when present and validated, protects the integrity of parts of the authentication exchange but does not eliminate every relay risk.
Important distinction: NTLM is not an Active Directory protocol. It is an authentication protocol that can be used in Windows environments. Active Directory domain controllers can validate NTLM credentials for domain accounts, but NTLM and Active Directory are not the same thing.
Where NTLM Is Still Used
NTLM remains relevant for workgroup authentication, local accounts, non-domain-joined devices, and older clients and servers. Some Windows Integrated Authentication configurations also use it for legacy compatibility.
It can appear in Server Message Block (SMB), HTTP, and other application connections, including some proxy deployments. The account domain and authentication context help determine whether credentials are validated locally or through a domain controller. Windows also uses the MSV1_0 authentication package for local account validation; local logon authentication is not necessarily the same three-message network exchange described below.
NTLM Versions
The older LAN Manager authentication protocol (LM) and NTLMv1 have well-known cryptographic weaknesses and should be disabled where possible after compatibility testing. NTLMv2 uses stronger challenge-response calculations but remains a legacy authentication method.
LMv2 is a response format associated with NTLMv2, not a separate modern replacement. Organizations should inventory actual usage before changing policy so they can identify applications or devices that may depend on older authentication behavior.
How NTLM Authentication Works
The NTLM network authentication protocol uses three message types exchanged between a client and server: NEGOTIATE_MESSAGE, CHALLENGE_MESSAGE, and AUTHENTICATE_MESSAGE. For a domain account, the server typically asks a domain controller (DC) to validate the response. The exchange proves possession of password-derived credentials; it does not send the password itself.
The diagram represents a simplified network exchange. Local interactive logon and some other authentication contexts follow different paths.
1. Negotiation Message
The client sends a NEGOTIATE message describing supported NTLM capabilities, including options related to signing and session security. The server uses these flags to determine compatible settings. Negotiation establishes how the exchange will proceed; it does not authenticate the client by itself.
2. Challenge Message
The server sends a CHALLENGE message containing an eight-byte random challenge, plus applicable target information and negotiation flags. The server challenge is not a 16-byte random number; NTLMv2’s proof component is 16 bytes, which can cause confusion.
A fresh challenge helps prevent simple replay attacks because an earlier response should not validate against a different challenge. It does not stop an attacker from relaying a live authentication exchange to another service.
3. Authentication and Verification
The client sends an AUTHENTICATE message containing identity details and a response calculated from password-hash-derived material. NTLMv2 response data incorporates challenge information and a timestamp. The server then validates the response locally or, for a domain account, through a domain controller.
Successful verification establishes identity; authorization determines what that identity is permitted to access. Signing or sealing can protect a session where supported and negotiated. Extended Session Security strengthens relevant calculations but does not make every NTLM connection resistant to relay attacks.
NTLM Versus Kerberos
Kerberos v5 became the default authentication protocol for domain accounts in Windows 2000, while NTLM was retained for compatibility with older clients and servers and for standalone computers. Kerberos uses tickets issued by a trusted Key Distribution Center (KDC), rather than relying on an NTLM-style challenge-response exchange for each target service.
Why Kerberos Is Usually Preferred
Kerberos supports mutual authentication: a client can verify the service’s identity, and the service can authenticate the client. Its ticket-based model also supports single sign-on (SSO) and access to resources across correctly configured domain and cross-forest trust environments. Kerberos still requires careful configuration and credential protection; replacing NTLM does not remove the need to secure endpoints and privileged accounts.
NTLM vs. Kerberos at a Glance
| Feature | NTLM | Kerberos |
| Authentication method | Challenge-response using password-derived material | Ticket-based authentication using a KDC |
| Mutual authentication | Not built in in the same way as Kerberos | Supported when correctly configured |
| Single sign-on | More limited; depends on the application and context | Supported through service tickets |
| Relay resistance | Vulnerable to relay in some configurations; protections are required | Different security model, but configuration and ticket protection remain important |
| Typical role in Active Directory | Compatibility and fallback | Preferred protocol for domain services |
On a phone, scroll the table sideways to see every column.
When NTLM May Be the Fallback
Common causes include local accounts, workgroups, legacy software, IP-address-based access, and missing or incorrect service principal names (SPNs). An application using a Windows authentication API may negotiate NTLM when Kerberos cannot obtain or use the required service ticket.
Domain controller connectivity problems can affect authentication, but NTLM is not a universal workaround: domain NTLM validation generally still requires a reachable DC. Investigate the hostname, domain name, target resource, and service configuration behind each fallback. A successful connection proves that something worked, not that the intended authentication protocol was used.
Why NTLM Creates Security Risks
NTLM security risks involve more than password disclosure. Credential interception, relay, offline cracking, and lateral movement can occur even though the plaintext password does not cross the network. Risk depends on the protocol version, password strength, service exposure, signing requirements, and other protections. NTLMv2 improves on NTLMv1, but stronger response calculations do not solve every protocol-level limitation.
NTLM Relay and Coercion-Based Attacks
In a relay attack, an attacker captures or induces an authentication attempt and forwards the live exchange to another service. The attacker may gain authenticated access without cracking the password. In coercion-based attacks, a system or user is manipulated into initiating authentication to an attacker-controlled or unintended endpoint; that authentication attempt may then be relayed if the target service and environment lack appropriate protections.
Name-resolution weaknesses involving Link-Local Multicast Name Resolution (LLMNR) or NetBIOS Name Service (NBT-NS) can contribute to some attack paths. Relay targets may include SMB services without required signing and inadequately protected LDAP or HTTP endpoints. Active Directory Certificate Services web enrollment endpoints also require careful review of authentication protections.
Relay differs from pass-the-hash, which uses a stolen NT password hash directly to authenticate. These attack techniques are distinct, although they can appear in the same broader intrusion.
Password-Hash Exposure and Offline Cracking
Captured challenge-response material can support dictionary or brute-force attempts against candidate passwords. Weak and reused passwords increase the practical risk. LM hashes and NTLMv1 exchanges are especially vulnerable. NTLMv2 timestamps and challenge values add freshness to the exchange, but they are not equivalent to modern password salting for stored credentials.
Missing Mutual Authentication
NTLM lacks Kerberos’s built-in mutual-authentication model. A client may participate in an exchange without equivalent assurance that the destination is the intended service. Separately, theft of local account hashes from the Security Account Manager (SAM) database or credentials from endpoint memory can enable further compromise.
Common NTLM Misconceptions
These points help avoid common misunderstandings when assessing Windows authentication:
NTLM does not send the plaintext password across the network, but authentication exchanges can still expose material to offline cracking or relay abuse.
NTLMv2 is stronger than NTLMv1, but it does not eliminate relay attacks.
A successful connection does not guarantee Kerberos was used. Check the authentication package and relevant logs.
Authentication and authorization are different. Authentication establishes identity; authorization determines the access that identity receives.
HTTPS alone does not guarantee an NTLM-enabled endpoint is protected against relay. Service-level protections and configuration still matter.
How to Identify NTLM Use in Your Environment
Inventory NTLM before restricting it because dependencies can hide in scheduled tasks, appliances, application pools, and device configurations. Include file shares, LDAP integrations, proxy authentication, and HTTP or HTTPS services. For each event, record the target service, username, account type, source device, destination, and logon context before deciding how to remediate it.
Review Windows Security Events
Start with Windows Security Event ID 4624 on the destination system and inspect the Authentication Package field. NTLM indicates NTLM authentication; Kerberos indicates Kerberos, although some records require correlation with additional events to understand the full path. Event ID 4776 can provide additional visibility into NTLM credential validation on the validating computer.
Compare the account name, workstation, source address, logon type, and destination system. Distinguish the MSV1_0 authentication package from the application that initiated authentication: Msv1_0.dll is a Windows component, not the business dependency you ultimately need to identify.
Example: What to Look for in Event ID 4624
In a Security event record, locate the Logon Information and Detailed Authentication Information sections. Review fields such as Account Name, Workstation Name, Source Network Address, Logon Type, and Authentication Package. If the Authentication Package field says NTLM, investigate which application or service generated the logon and whether Kerberos should have been used. Exact fields and availability can vary by Windows version and event context.
Operational warning: An event alone rarely explains the complete dependency. Correlate the event with the source device, destination service, application logs, and business owner before blocking NTLM.
Use NTLM Auditing Before Blocking
Enable applicable Restrict NTLM audit policies for incoming traffic, outgoing traffic, and domain authentication. Review the Microsoft-Windows-NTLM/Operational log alongside Security events. Collect data across normal operations, maintenance windows, and infrequent business processes; a short sample may miss monthly reporting jobs or disaster-recovery workflows.
Document each dependency’s business owner, remediation path, and test criteria. Include outdated cryptography on legacy systems, not merely the number of successful logons. Use controlled testing before enforcement so authentication failures can be traced to a specific policy change.
Not sure where NTLM is hiding in your environment?
We can help you audit NTLM use, map each dependency to an owner, and sequence remediation so nothing breaks.
Reducing NTLM Reliance Safely
Treat NTLM reduction as a phased security improvement: eliminate LM and NTLMv1 first, protect necessary NTLMv2 connections, and migrate remaining dependencies. Windows Management Experts, Inc.’s security-evaluation approach emphasizes assessment, prioritized remediation, and progress reporting. Apply that discipline by measuring exposure, validating business impact, and monitoring each change.
A Practical NTLM Migration Roadmap
Inventory NTLM usage. Enable auditing, identify dependencies, and document application owners and business impact.
Disable LM and NTLMv1. Confirm compatibility and test before enforcing changes across production systems.
Protect remaining NTLMv2 connections. Require SMB signing where supported, and use LDAP signing and channel binding where applicable.
Fix Kerberos configuration. Review DNS records, SPNs, delegation settings, service accounts, and access by IP address instead of hostname.
Restrict NTLM in stages. Pilot policy changes with a limited group, then expand after testing and stakeholder approval.
Monitor fallback events. Review authentication logs and failures after each change, and investigate unexpected NTLM use.
Strengthen Protections for Remaining NTLM
Require SMB signing where supported, using policies such as “Microsoft network client: Digitally sign communications (always)” and the corresponding server policy. Protect LDAP with signing and channel binding where applicable. Enable Extended Protection for Authentication on compatible HTTP services. HTTPS alone does not guarantee that an NTLM-enabled endpoint resists relay.
Apply multifactor authentication (MFA) where supported, but do not assume MFA on an interactive sign-in protects every downstream NTLM path. Credential Guard uses virtualization-based security to isolate certain secrets from the rest of the operating system, but it is not a replacement for service-level relay protections. Use signing or Extended Protection where applicable.
Move Workloads Toward Kerberos
Correct SPNs, DNS records, delegation settings, and service account configuration. Prefer the intended hostname over an IP address when accessing domain services. Update or replace applications and appliances that require NTLM where feasible. Use managed identities or modern authentication for supported cloud-connected workloads, and validate defaults and compatibility on the Windows versions in your environment.
Avoid Disruptive Changes
Do not apply a global “Deny all” policy without audit data, dependency testing, stakeholder communication, and a rollback plan. Pilot restrictions with a limited group before widening enforcement. Include non-domain-joined machines and legacy integrations in testing. Continue protecting LSASS memory because protocol migration alone does not prevent credential theft.
Key Takeaways
NTLM authenticates through challenge-response rather than transmitting plaintext passwords.
NTLM is not an Active Directory protocol, although domain controllers can validate NTLM authentication for domain accounts.
NTLMv2 is stronger than NTLMv1 but retains risks that require service-level protections and careful configuration.
Inventory actual NTLM use, disable LM and NTLMv1 after compatibility testing, protect remaining connections, fix Kerberos configuration, restrict NTLM in stages, and monitor fallback.
The goal is not simply fewer NTLM events, but fewer exposed authentication paths without breaking business workflows.
Frequently Asked Questions
Is NTLM Still Used Today?
Yes. NTLM remains in use for legacy Windows applications, workgroup devices, local accounts, and connections where Kerberos is unavailable or misconfigured. Audit your environment rather than assuming newer operating systems have eliminated it.
Is NTLM the Same as Kerberos?
No. NTLM uses password-hash-derived challenge-response authentication, while Kerberos uses tickets issued by a trusted Key Distribution Center. Kerberos supports mutual authentication and is generally preferred for Active Directory domain services.
How Do I Check Whether NTLM or Kerberos Is Used?
Review Windows Security Event ID 4624 and inspect the Authentication Package field, correlating additional events where needed. NTLM auditing policies provide broader visibility into incoming, outgoing, and domain authentication before enforcement changes.
How Do I Enable NTLM Authentication on a Server?
Configuration depends on the service, Windows version, and organizational security policy; NTLM may already be permitted. Confirm the dependency first, allow only NTLMv2 where supported, and configure signing, channel binding, or Extended Protection as applicable.
Fewer exposed authentication paths, without breaking business workflows.
We’ll assess your NTLM exposure, prioritize remediation, and report progress as each change goes in.
