For IT professionals and security-conscious organizations, understanding this aging protocol, how it works, and why it’s still lurking on your network is more crucial than you might think. This blog is all about shining a light on NTLM’s inner workings, recognizing its risks and benefits, and offering practical advice for safeguarding your environment.
Read on as we strip away the jargon to explain what NTLM is, how it authenticates users, how it compares to Kerberos, and why it continues to matter—even as modern threats grow more sophisticated.
NTLM stands for New Technology LAN Manager. Developed by Microsoft, NTLM is a suite of security protocols designed to authenticate users on networks running Windows operating systems. At its core, NTLM provides a means to confirm someone’s identity without constantly demanding their password, making it an early player in the realm of single sign-on (SSO).
NTLM was the standard protocol for Windows domains up until Windows 2000, when Kerberos took over by default. Yet NTLM is still part of today’s Windows systems, mainly for legacy compatibility reasons. That means if your network has old applications or clients, odds are NTLM is still somewhere in the authentication chain.
Developed for Microsoft Windows environments
Relies on a challenge-response mechanism
Still present in many networks to support older systems
Replaced by Kerberos in newer Active Directory domains, but not fully retired
Authentication protocols can seem like a maze, but NTLM’s process breaks down into a straightforward three-step handshake between client and server. The main goal? Prove user identity without sending passwords over the network.
Here’s what happens when you attempt to log in using NTLM:
Negotiation
The client (your computer) starts a conversation with the server, listing NTLM as an authentication option.
Challenge
The server responds with a random “challenge”—a unique 16-byte number.
Response
The client, using the user’s password (or rather, a hash of it), encrypts the challenge and sends this “response” back to the server.
Verification
The server forwards the username, challenge, and response to the domain controller.
The domain controller retrieves the user’s stored password hash, uses it to encrypt the challenge again, and compares its result to the client’s response.
Access Granted (or Denied)
If the encrypted responses match, authentication is a success. If not, access is blocked.
Key points
The real password never travels the network in plain text.
Rather, password hashes are used to encrypt proof that the user knows the password.
This prevents eavesdropping but, as we’ll see, is far from bulletproof.
Despite its age, NTLM’s roots are still embedded in the fabric of many corporate networks. You’ll find NTLM used in situations such as:
Authenticating devices running old versions of Windows (Windows 95/98/NT)
Allowing modern servers to talk to outdated clients or applications that don’t support Kerberos
Handling local logons on standalone systems or non-domain-joined machines
Acting as a fallback method when Kerberos fails
Nobody sets out to rely on an old authentication protocol, but supporting legacy systems and complex networks can make a total phase-out difficult. Think of NTLM as the stubborn relative at a family reunion; it might not be the life of the party, but you can’t just show it the door.
NTLM’s core mechanism is the challenge-response handshake, as mentioned earlier, but there are nuances worth understanding.
Credentials gathering
Users enter their username, password, and domain into their device.
Hashing
The client creates a hash of the password (not the plaintext) and immediately gets rid of the actual password.
Initiation
The client sends just the username to the server.
Random challenge
The server throws down a 16-byte random number, daring the client to prove their identity.
Encrypted response
The client encrypts this challenge using the password hash, then sends the result as a response.
Third-party verification
The server checks with the domain controller, which encrypts the challenge with its own copy of the user’s hash.
Match and approve
If the hashes line up, access is allowed.
On the surface, NTLM keeps passwords off the network, favoring hashed comparisons. However, this method has aged poorly, making it a tempting target for modern attackers.
If NTLM is the defender stuck in the past, Kerberos is the fast, modern alternative Microsoft now trusts by default.
NTLM
Uses a challenge-response (three-message) exchange, validating identity each time for each resource.
Kerberos
Implements a “ticketing” system managed by a Key Distribution Center (KDC). After initial login, users get a ticket (session key) granting access for a defined period, reducing repeated password usage.
NTLM
Relies on password hashing, which, if stolen, can be abused by attackers in “pass-the-hash” techniques.
Kerberos
Uses strong encryption. Both tickets and authenticators are encrypted, making credential theft much less exploitable.
NTLM
No support for multifactor authentication
Vulnerable to brute-force and pass-the-hash attacks
Lacks salting on password hashes
Kerberos
Built around encrypted ticket-granting services
The default for Active Directory domains
Modern, flexible, and more resilient to most types of credential attacks
NTLM’s main flaw lies in how it handles password hashes and authentication. Without “salting” (adding random data to hashes), attackers with access to password hashes can impersonate users, with no need for the real password. This makes brute-force cracking and pass-the-hash attacks dangerously effective.
Add to that the static, simplistic cryptography of NTLM and lack of multifactor authentication options, and you have a recipe for compromise that modern threat actors love to exploit.
Kerberos, by contrast, brings session tickets, encrypted communications, and strong cryptographic routines. It adds layers of defense that NTLM simply can’t match.
Despite its faults, NTLM does offer a few genuine advantages, especially when looking through the lens of legacy support:
But for every advantage, there’s a corresponding risk. Compatibility is what keeps NTLM on life support; it’s also what makes it so dangerous in a modern context.
NTLM’s disadvantages have become increasingly critical as attackers grow bolder and more sophisticated.
Vulnerable to attack
Lack of password salting allows attackers to impersonate users using hashed credentials
Susceptible to brute-force and pass-the-hash exploits
No support for contemporary security standards
No multifactor authentication
Can’t harness the latest encryption algorithms
Obsolete but hard to terminate
Legacy systems require it, so it continues to have a presence
Think of NTLM as a ramshackle lock on a door. It works, but any determined burglar knows exactly how to force it open.
If NTLM still lurks in your organization, treat it the way you’d treat an unsecured backdoor. Don’t rely on hope. Make auditing, patching, and ultimately moving away from NTLM a clear security objective. It’s also worth considering investing in security solutions and identity protection strategies tailored for modern threats.
