What’s the issue?
SQL Server supports several authentication schemes for incoming connections, visible in the auth_scheme column of sys.dm_exec_connections. For Windows authentication, the two relevant schemes are KERBEROS and NTLM, with Kerberos being the preferred protocol and NTLM serving as a fallback when Kerberos authentication cannot be completed.
When a client attempts to connect using Windows authentication, Windows first tries Kerberos. If the Service Principal Name (SPN) for the SQL Server instance is missing, duplicated, or registered to the wrong account, or if the client connects by IP address rather than by name, Kerberos fails and the connection silently falls back to NTLM.
This finding is raised by sp_CheckSecurity when NTLM accounts for more than 10 percent of current connections to the instance, which indicates that Kerberos is failing for a meaningful portion of the workload rather than for isolated edge cases.
Why is this a problem?
NTLM is a significantly weaker authentication protocol than Kerberos. It is vulnerable to relay attacks, in which an attacker positioned between a client and a server forwards the authentication exchange to a different target and authenticates as the original user. Kerberos is not susceptible to this class of attack in the same way, which is why Microsoft has been steadily deprecating NTLM across the Windows platform.
Widespread NTLM usage also blocks features that depend on Kerberos. Delegation scenarios, including double-hop authentication through linked servers, SSRS, and middle-tier applications, require Kerberos and will fail under NTLM. Extended Protection for authentication, which defends against relay attacks, is also most effective with Kerberos.
What should you do about this?
Identify the scope by querying sys.dm_exec_connections for the auth_scheme column, grouped by scheme and joined to sys.dm_exec_sessions to see which logins, hosts, and applications are connecting over NTLM. This indicates whether the fallback affects the whole instance or specific clients.
Verify the SPN configuration for the SQL Server service account using setspn -L <ServiceAccount> and check for missing SPNs, duplicate registrations, or SPNs registered to the wrong account. Duplicates are a particularly common cause and break Kerberos entirely for the affected instance. The MSSQLSvc/<FQDN>:<port> and MSSQLSvc/<FQDN>:<instancename> formats are the ones to confirm.
Register or correct the SPNs, either by granting the service account the ability to self-register or by having a domain administrator create them explicitly. Confirm that clients connect using the fully qualified server name rather than an IP address, since IP-based connections cannot use Kerberos.