Every blog post about Microsoft killing NTLM is written for Windows admins and security teams. Why aren't we talking about what this means for SQL Server?
There is a good chance this message has been sitting in your SQL Server error log for years:
The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/YOURSERVER.domain.com:1433 ] for the SQL Server service. Windows return code: 0xffffffff, state: 63. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.
'Informational message' and 'Further action is only required if Kerberos authentication is required'... For years, we could ignore this, but not anymore. Microsoft published a three-phase roadmap on January 28, 2026 to disable NTLM by default in upcoming Windows releases -- and phase one is already live. That 'informational message' is about to become an action-item.
In most environments I audit, somewhere between 40 and 60 percent of Windows Authentication connections to SQL Server are running on NTLM -- and nobody knew until we looked. If you have not checked yours, now is the time.
What Is Happening
NTLM (New Technology LAN Manager) has been around since 1993. Kerberos replaced it as the preferred Windows authentication protocol over 20 years ago. But NTLM stuck around as the silent fallback -- the thing Windows quietly uses when Kerberos didn't work. Microsoft formally deprecated it in June 2024. Now they are moving to disable it.
Based on what Microsoft has announced so far, here is where things stand:
| Phase | When | What Happens |
|---|---|---|
| 1 | Now | Enhanced NTLM auditing in Server 2025 and Win 11 24H2 |
| NTLMv1 enforce | October 2026 | BlockNTLMv1SSO default flips from Audit to Enforce |
| 2 | H2 2026 | IAKerb, Local KDC ship; core Windows components prefer Kerberos |
| 3 | Next major Server release (no date announced) | Network NTLM disabled by default |
Important note: The October 2026 date applies to NTLMv1 only. Most SQL Server environments are already using NTLMv2, so that specific flip may not break anything for you immediately. The bigger change is Phase 3, where network NTLM (including v2) gets disabled by default. Microsoft has not announced a firm date for Phase 3, but it will coincide with the next major Windows Server release, which could be 2027 or later.
That said, the change is happening and this is not a fire drill. Now's the time to figure out where things stand with your SQL Servers.
Why Is This a SQL Server Problem?
SQL Server does not control which authentication protocol is used. Windows does. When a client connects using Windows Authentication over TCP/IP, the SSPI layer tries Kerberos first. If Kerberos can't work -- missing SPN, broken delegation, no domain controller visibility -- it falls back to NTLM. Silently. No error. No warning. Your connections work fine, and you never know the difference.
Until NTLM gets turned off. Then those connections stop working -- less silently.
Here are the scenarios where SQL Server silently falls back to NTLM:
Missing or misconfigured SPNs
If the Service Principal Name for your SQL instance is not registered in Active Directory -- or is registered against the wrong account -- Kerberos fails and NTLM takes over. This is the most common cause. Named instances with dynamic ports are especially prone to this.
Named Pipes connections
Named Pipes forces NTLM. Always. There is no Kerberos path for Named Pipes connections to SQL Server.
Connecting by IP address instead of hostname
If your connection strings or application configs use an IP address instead of a fully qualified domain name, Kerberos cannot resolve the SPN. NTLM takes over.
Linked servers with Windows Authentication
The classic double-hop problem. My favorite. 🙄 If Kerberos delegation is not configured for your service account, linked server queries using Windows Authentication will fail with 'Login failed for user NT AUTHORITY\ANONYMOUS LOGON'.
Local connections
Connections from the SQL Server host to itself (ie., SSMS on the server, local jobs, local apps) always use NTLM due to a per-service SID hardening feature added in Windows 2008. This is by design and won't change.
SSRS, SSIS, SSAS
These services have their own authentication paths and their own SPN requirements. If they are not configured for Kerberos, they are using NTLM.
Legacy drivers
The old OLE DB provider (SQLOLEDB) and older ODBC drivers may force NTLM in certain configurations, particularly with Named Pipes. If you have not updated to MSOLEDBSQL or ODBC Driver 17/18, it's worth checking.
Find Out What You Are Running Right Now
Run this from a client machine (not from the server itself -- local connections always show NTLM):
SELECT
s.login_name,
s.host_name,
c.auth_scheme,
c.net_transport,
c.encrypt_option,
s.program_name,
c.connect_time
FROM sys.dm_exec_connections c JOIN sys.dm_exec_sessions s
ON c.session_id = s.session_id
WHERE s.is_user_process = 1
AND c.net_transport <> 'Shared memory'
ORDER BY c.auth_scheme, s.login_name;
If your auth_scheme column shows NTLM for remote connections, those are the connections you need to investigate. Run this to see how big the problem is:
SELECT
c.auth_scheme,
COUNT(*) AS connection_count
FROM sys.dm_exec_connections c JOIN sys.dm_exec_sessions s
ON c.session_id = s.session_id
WHERE s.is_user_process = 1
AND c.net_transport <> 'Shared memory'
GROUP BY c.auth_scheme
ORDER BY connection_count DESC;
If you are running Windows Server 2025 or Windows 11 24H2, you can also check the new NTLM audit logs:
-- Run this on the Windows host via PowerShell (not T-SQL) Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" | Format-List
Event IDs 4020 and 4021 log client-side NTLM attempts. Event IDs 4022 and 4023 log server-side NTLM authentication. Event ID 4024 logs NTLMv1-derived credential usage specifically.
What To Do About It
1. Audit your connections. Run the DMV queries above across your environment. Get a picture of how many connections are using NTLM vs Kerberos. If you see NTLM on remote connections, you have work to do.
2. Fix your SPNs. This solves the majority of NTLM fallback in SQL Server. Verify SPNs are registered correctly for every instance -- default, named, clustered, and AG listeners. Use setspn -L domain\service_account to list what is registered. Use setspn -S to add missing ones. Microsoft's Kerberos Configuration Manager can help identify gaps.
3. Fix dynamic ports. Named instances with dynamic ports are an SPN headache. Consider switching to static ports, or ensure the service account has permission to register and unregister SPNs on startup.
4. Fix your connection strings. If anything is connecting by IP address, change it to the FQDN. This one change can flip a connection from NTLM to Kerberos without touching Active Directory.
5. Stop using Named Pipes for remote connections (if you can). TCP/IP with a valid SPN gives you Kerberos. Named Pipes never will.
6. Update your drivers. SQLOLEDB is deprecated and does not support TLS 1.3 or modern authentication. You should consider replacing it with MSOLEDBSQL and updating your ODBC drivers to version 17 or 18. While older drivers don't force NTLM on their own over TCP, they are end-of-life and don't support TLS 1.3, which Windows Server 2025 now enables by default. Updating your drivers now would address multiple security changes at once.
7. Test with NTLM off. When you are ready, Microsoft recommends testing NTLM-off configurations in non-production environments. The Group Policy setting Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers lets you block outbound NTLM traffic systematically. Start in audit mode, review the results, and work through the exceptions before enforcing.
Microsoft is giving everyone time to prepare -- use it. The phase-out is structured so you can audit now, remediate at your own pace, and be ready well before NTLM gets disabled by default. The work itself is straightforward, but it takes time to audit, test, and remediate across an entire environment -- especially if you have dozens of instances, linked servers, and legacy applications connecting via Windows Auth.
If you are not sure where your environment stands, or you don't have the bandwidth to audit and remediate this across your SQL Server estate, we can help. Better to know now than to find out later.
More to Read:
Microsoft: Advancing Windows Security -- Disabling NTLM by Default
Microsoft Support: Upcoming Changes to NTLMv1 in Windows 11 24H2 and Server 2025
Microsoft Learn: Determine the Authentication Type for SQL Server Connections
Microsoft Learn: Using Kerberos Configuration Manager for SQL Server
Microsoft: Understanding Kerberos and NTLM Authentication in SQL Server Connections
