What’s the issue?
SQL Server supports two authentication models. Windows authentication relies on Active Directory or local Windows accounts, where the identity is established by the operating system and no credential is transmitted or stored by SQL Server. SQL authentication uses a login name and password managed entirely within SQL Server, sent by the client at connection time.
The authentication type used by each connection is visible in the auth_scheme column of sys.dm_exec_connections, where SQL authentication appears as SQL and Windows authentication appears as KERBEROS or NTLM.
This finding is raised by sp_CheckSecurity when SQL authentication accounts for more than 10 percent of current connections to the instance, indicating that SQL logins are carrying a meaningful share of the workload rather than being limited to a few exceptional cases.
Why is this a problem?
SQL logins rely on a name and password that can be used by anyone who has them. Unlike a Windows account, there is no tie to a person, a device, or a domain policy, so a credential that leaks through a configuration file, a script in source control, a support ticket, or a departing employee’s notes remains fully usable until someone notices and changes it.
Password management is also weaker. Windows and Active Directory enforce complexity, length, history, expiration, and lockout centrally, and integrate with multi-factor authentication and identity governance tooling. SQL logins can enforce policy through CHECK_POLICY and CHECK_EXPIRATION, but these are set per login, are frequently disabled to accommodate applications, and offer nothing comparable to the broader identity controls.
Auditing suffers as well. SQL logins are commonly shared across applications, jobs, and people, so activity recorded under a single login cannot be traced to an individual. This undermines accountability during normal operation and makes forensic analysis after an incident considerably harder.
What should you do about this?
Identify the scope by querying sys.dm_exec_connections joined to sys.dm_exec_sessions, grouping by auth_scheme and capturing the login names, host names, and program names behind the SQL authentication connections. This shows which applications and processes are responsible.
Work with the application owners to migrate to Windows authentication wherever the application supports it. Modern applications and drivers generally do, and the migration usually amounts to changing the connection string and running the application under an appropriate service account or Group Managed Service Account.
For logins that must remain on SQL authentication, typically vendor applications that do not support Windows authentication, enable CHECK_POLICY at minimum, use long randomly generated passwords stored in a secrets management system, and rotate them on a defined schedule. Document each remaining SQL login with its owner, purpose, and the reason Windows authentication is not viable.