Secure your network by disabling NTLM now

Security experts now recommend disabling NTLM by default in favor of modern authentication protocols like Kerberos. The decades-old NTLM (NT LAN Manager) protocol, though still present in many environments, carries well-documented flaws that attackers frequently exploit. Transitioning away from NTLM isn’t just a best practice—it’s a critical upgrade to your network’s defense against unauthorized access and credential theft.

Why NTLM poses security risks in modern networks

NTLM was designed for Microsoft environments in the 1990s and was quickly surpassed by Kerberos, which offers stronger encryption and mutual authentication. Despite its age and known vulnerabilities—such as susceptibility to relay attacks, pass-the-hash exploits, and offline brute-force cracking—NTLM remains enabled by default on many systems. This outdated protocol increases the attack surface by allowing lateral movement within networks, especially in environments still relying on legacy applications or misconfigured Active Directory setups.

Security standards from organizations like NIST and CIS now advocate for disabling NTLM wherever possible. Enterprises that continue to rely on it risk non-compliance with modern security frameworks and face greater exposure to data breaches. Removing NTLM support reduces reliance on a protocol that no longer meets contemporary security expectations.

Step-by-step: Disabling NTLM in Windows environments

To reduce exposure in Windows systems, administrators can restrict NTLM traffic through Group Policy or registry edits. This approach blocks outgoing NTLM authentication attempts to remote servers, forcing the use of more secure protocols like Kerberos.

Using Group Policy Editor

• Press Win + R, type gpedit.msc, and press Enter to open the Local Group Policy Editor.
• Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
• Locate the policy titled Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers.
• Set the policy to Enabled and choose Deny all accounts to block all outgoing NTLM traffic.

These changes take effect immediately after rebooting the system. Administrators should verify the policy is applied using the command gpresult /r or by checking the secedit output.

Registry-based configuration

For automation or remote deployment, you can enforce the same restriction via registry edits using PowerShell or deployment scripts.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RestrictSendingNTLMTraffic /t REG_DWORD /d 2 /f

This registry value (2) blocks all outgoing NTLM authentication, while a value of 1 restricts it only to remote servers in the same domain. A value of 0 disables all restrictions. After applying, restart the system to ensure the change takes effect.

How Linux systems can eliminate NTLM dependency

Linux environments integrated with Active Directory often rely on NTLM as a fallback when Kerberos authentication fails. By reconfiguring authentication stacks like sssd or pam, teams can prioritize Kerberos and reduce NTLM usage.

Configuring sssd to prefer Kerberos

The sssd daemon manages identity, authentication, and authorization on Linux systems. To ensure Kerberos is used instead of NTLM for Active Directory domains, update the /etc/sssd/sssd.conf configuration file.

[sssd]
config_file_version = 2
services = nss, pam
domains = example.com

[domain/example.com]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ldap_id_mapping = False
use_fully_qualified_names = True
fallback_homedir = /home/%u
default_shell = /bin/bash
ldap_sasl_mech = GSSAPI

Key settings include setting auth_provider = ad and explicitly specifying ldap_sasl_mech = GSSAPI, which forces the use of Kerberos via GSSAPI. After editing, restart the sssd service:

systemctl restart sssd

This configuration ensures Kerberos tickets are used for authentication, eliminating NTLM as a fallback mechanism.

Planning and testing your NTLM decommissioning

Disabling NTLM requires careful preparation. Start by auditing your environment to identify systems, applications, or services that depend on NTLM—legacy intranet portals, older third-party tools, or custom scripts are common culprits.

Pre-migration checklist

• Inventory all Active Directory accounts, services, and applications with NTLM fallback enabled.
• Review application logs to detect NTLM authentication attempts in real time.
• Identify test users and non-production systems to validate changes safely.
• Establish rollback procedures in case of unexpected failures.

Post-migration validation

After applying changes, monitor authentication logs for errors or warnings. Use tools like Event Viewer in Windows or journalctl -u sssd on Linux to track authentication failures. If an application fails to authenticate, check its support for Kerberos or SSPs (Security Support Providers) before reverting restrictions.

The future of authentication: Move beyond NTLM entirely

While disabling outgoing NTLM traffic is a strong first step, the ultimate goal is to remove NTLM support entirely from all systems. Enterprises should prioritize upgrading legacy applications, enforcing Kerberos-only policies, and auditing authentication flows regularly. As cloud and hybrid environments grow, migrating to modern identity protocols like OAuth 2.0 or SAML further reduces dependency on outdated methods.

Security is not a one-time task—it’s a continuous process. By retiring NTLM today, organizations can significantly reduce their exposure to credential-based attacks and align with evolving compliance requirements. Start small, test thoroughly, and scale the transition across your infrastructure to build a more resilient security posture.