NTLM vs. Kerberos: What’s the Difference?

Last updated on March 10, 2025

The main difference between NTLM and Kerberos is that NTLM is a challenge-response protocol used during workgroup and local authentication, whereas Kerberos is a ticket-based protocol that utilizes a trusted third-party authentication service.

Note that NTLM is a name for a package containing LAN Manager versions 1 and 2 and NTLM versions 1 and 2. Nevertheless, NTLM is often referred to as NTLM version 2 (NTLMv2).

NTLM vs. Kerberos: What’s the Difference?

NTLM and Kerberos are two widely used client-server authentication protocols. Both are available in Windows operating systems and are mainly used to authenticate users who log in to their Windows computers. But Kerberos and NTLM have many dissimilarities. We have compiled the most important NTLM vs. Kerberos differences in the following table.

NTLM	Kerberos
Challenge-Response Protocol	Ticket-Based Protocol
Passwords are not salted	Passwords are salted
Supports only symmetric key cryptography	Capable of both symmetric and asymmetric key cryptography
Implemented in older Windows versions and newer Windows operating systems for backward compatibility.	Generally implemented in Microsoft products such as Windows Server and Windows operating systems and Active Directory.
Mainly used by Windows computers that are not members of an Active Directory domain.	Used primarily by Windows computers that are members of an Active Directory domain.
NTLM does not support delegation of authentication. Supports impersonation.	Kerberos supports both impersonation and delegation of authentication.
NTLM does not allow for mutual authentication.	Kerberos has the feature of mutual authentication.
NTLM is less secure.	Kerberos provides high security.

Why Is Kerberos Better Than NTLM?

Kerberos is better than NTLM because:

• Kerberos is more secure – Kerberos does not store or send the password over the network and can use asymmetric encryption to prevent replay and Man-in-the-Middle (MiTM) attacks
• Kerberos is faster – NTLM slows down domain controllers while Kerberos uses a single ticket to access multiple network resources
• Kerberos supports delegated authentication – While NTLM only supports impersonation, Kerberos also supports delegation of authentication
• Kerberos supports mutual authentication – Mutual Authentication can stop some interception attacks and unauthorized access to network resources

What Are the Drawbacks of NTLM?

The biggest drawback of NTLM is the weak cryptography behind it. In addition, NTLM does not have all the features Kerberos does.

• Easy hash extraction – Widely available hacking tools can easily extract cached account credentials such as NTLM hashes.
• Weak hash algorithm – NTLM uses a weak MD4 password hashing algorithm, making all 8-character passwords hackable in less than 2.5 hours.
• Pass-the-hash vulnerability – NTLM is vulnerable to pass-the-hash (PtH) attacks.

30 Days of Free MFA for Windows & RDP →

Why Is NTLM Still Used?

NTLM is an outdated protocol. It is less secure and comes with fewer features than Kerberos. The question is: Why is NTLM still in use? Here are some reasons NTLM is still in use:

• Fallback Option – If Kerberos fails, the client will fall back to NTLM.
• Workgroup Authentication – NTLM is still used to authenticate to systems configured as members of a workgroup.
• Local Authentication –  NTLM runs during local logon authentication on non-domain controllers.
• Backward Compatibility – Older systems such as Windows 95, Windows 98, and Windows NT 4.0 are not members of an Active Directory domain, so they use NTLM to authenticate local logons.
• Non-Existent SPN – If the client asks for a service principal name (SPN) that does not exist in Active Directory (AD), Kerberos will not work. Examples would be using an IP instead of a name to access a resource and not registering SPN.
• Cannot Connect to DNS or DC – NTLM will be used when there is no connectivity between the client and DNS/DC.
• Hybrid Environments – NTLM still finds use in hybrid environments that combine non-domain clients with domain clients or domain accounts with local user accounts.

Historical Context and Evolution

Understanding where NTLM and Kerberos come from can provide valuable insight into their design and usage today. NTLM was initially developed during the early days of Windows networking to serve as a simple challenge–response mechanism. Over time, multiple versions emerged—NTLMv1 and NTLMv2—with each iteration attempting to bolster security. In contrast, Kerberos was introduced as a ticket-based system designed by MIT and later adopted by Microsoft for Active Directory environments. Its evolution reflects a growing need for robust, centralized authentication and the ability to support complex, distributed networks. This historical perspective explains the coexistence of these protocols and highlights the technological shifts that have influenced modern authentication practices.

---

Subscribe to the Rublon Newsletter

Stay secure and ahead of the curve—subscribe to the Rublon Newsletter for exclusive cybersecurity insights and expert tips!

---

Technical Deep Dive: How NTLM and Kerberos Work

For readers looking to understand the nuts and bolts, this section delves into the operational differences between NTLM and Kerberos:

• Encryption and Security: While NTLM uses symmetric key encryption with less robust hashing, Kerberos can leverage both symmetric and asymmetric encryption techniques, offering a more secure framework for modern networks.
• NTLM Mechanism: NTLM operates on a challenge–response basis. When a user attempts to authenticate, the server sends a challenge, which the client encrypts using a hash of the user’s password. This approach, however, relies on older cryptographic methods (like MD4/MD5) and is susceptible to certain types of attacks such as pass-the-hash.
• Kerberos Architecture: In contrast, Kerberos employs a ticketing system managed by a trusted Key Distribution Center (KDC). Here, users obtain a Ticket Granting Ticket (TGT) after initial verification, which they later exchange for service tickets when accessing resources. This process not only minimizes password exposure but also supports mutual authentication—ensuring both the user and service verify each other’s identities.

Implementation Best Practices and Troubleshooting

For IT administrators, successful deployment of these protocols requires more than just understanding theory—it demands careful implementation:

• Kerberos Configuration: Ensure your Active Directory environment is properly configured. This includes accurate DNS settings, synchronized system clocks across devices, correct registration of Service Principal Names (SPNs), and MFA for Active Directory.
• Avoiding Common Pitfalls: Problems such as clock skew, SPN conflicts, or misconfigured KDCs are common in Kerberos setups. Establish regular monitoring and logging practices to catch and resolve these issues promptly.
• Minimizing NTLM Usage: Although NTLM might serve as a fallback, strive to limit its use. Strengthen security by configuring policies that favor Kerberos and disable NTLM where feasible, thereby reducing the risk of vulnerabilities like pass-the-hash.
• Troubleshooting Tools: Utilize network monitoring tools and Windows Event Logs to diagnose authentication failures and performance bottlenecks, ensuring a smooth and secure authentication experience.

Comparative Use Cases: Which Protocol to Choose?

Choosing the right authentication method often depends on the environment and specific requirements:

• Legacy and Isolated Systems: NTLM may still be prevalent in older systems or standalone workgroup environments where Active Directory is not in play.
• Enterprise and Domain Environments: Kerberos is generally the protocol of choice in corporate settings due to its enhanced security features, including mutual authentication and delegation capabilities.
• Hybrid Networks: In environments combining both modern and legacy systems, a balanced approach may be necessary. Administrators should assess the specific security needs, compatibility issues, and performance considerations before deciding which protocol to prioritize.
• Decision-Making Checklist: A simple checklist—covering system age, network complexity, security requirements, and available infrastructure—can help organizations determine the most appropriate authentication strategy.

Future Trends in Windows Authentication Protocols

The landscape of network security continues to evolve, and so do authentication protocols:

• Adaptability and Integration: Future protocols will likely be designed with interoperability in mind, allowing seamless integration across on-premise, hybrid, and cloud environments.
• Rise of Multi-Factor Authentication (MFA): Modern security paradigms increasingly incorporate MFA as a standard, offering an extra layer of protection beyond passwords.
• Cloud and Zero Trust: With the shift toward cloud-based services, identity solutions like Microsoft Entra ID and zero-trust architectures are gaining traction. These solutions integrate seamlessly with traditional protocols while providing enhanced security.
• Beyond Kerberos and NTLM: Research and development are underway to create next-generation authentication systems that combine the strengths of existing protocols with innovative cryptographic methods, ensuring robust protection against emerging threats.

Enhancing NTLM and Kerberos Security with Multi-Factor Authentication (MFA)

Although NTLM and Kerberos have long been the backbone of Windows authentication, they each come with inherent vulnerabilities—such as susceptibility to pass-the-hash, replay attacks, and other credential-based exploits. Modern threat landscapes demand an extra layer of security, and this is where MFA comes into play. According to Microsoft, deploying multi-factor authentication can block over 99.9% of account compromise attacks, underscoring its critical role in fortifying legacy authentication protocols.

Why MFA is for NTLM & Kerberos is Essential

• Additional Security Layer: Even if an attacker manages to compromise user credentials through NTLM’s challenge–response process or bypass weaknesses in Kerberos, MFA requires a second form of verification—be it a one-time code, a biometric scan, or a hardware token—thereby significantly reducing the chance of unauthorized access.
• Mitigating Credential Theft: MFA effectively neutralizes risks from stolen or intercepted passwords. Microsoft’s statistic—often cited as blocking 99.9% of account takeover (ATO) attacks—illustrates that MFA stands as one of the most effective defenses against modern cyber threats.
• Complementing Kerberos’ Strengths: While Kerberos already benefits from features like mutual authentication and secure ticketing, integrating MFA further minimizes risks associated with replay attacks and ensures that even if a ticket is intercepted, additional verification is required before access is granted.
• Bolstering NTLM Environments: In scenarios where NTLM is still in use—often due to legacy systems or non-domain configurations—MFA compensates for the protocol’s weaker cryptography. By adding an extra authentication factor, organizations can significantly enhance security without having to overhaul entire systems immediately.

Get This Great MFA for Windows Logon and RDP

You can strengthen the protection of your Windows and RDP user logons with modern Multi-Factor Authentication (MFA) by using Rublon for Windows Logon and RDP.

Conclusion of Kerberos vs. NTLM

Kerberos is more secure and fresher than NTLM. Although NTLM comes with many drawbacks, it can still find use in some cases. Kerberos is the preferred protocol, and you should only use NTLM when Kerberos is not possible. All things considered, administrators in an organization need to carefully configure their domains, Active Directory, and networking to ensure a streamlined and safe user login experience regardless of the protocols used.