What’s the issue?
SQL Server includes a server-level setting called Login Auditing that controls which authentication events are written to the SQL Server error log. The setting offers four levels: none, failed logins only, successful logins only, and both successful and failed logins. The default setting on installation is failed logins only, which records every authentication failure in the error log along with the source IP address (in supported versions), the login name attempted, and the reason for failure.This finding identifies instances where the Login Auditing level is set such that failed logins are not being written to the SQL Server error log. The most common cases are instances configured for “none” (no authentication events logged) or “successful logins only” (failures explicitly excluded).
Why is this a problem?
Failed login attempts are one of the most important signals available for detecting authentication-based attacks against SQL Server. Brute-force attempts, credential stuffing, and reconnaissance activity all show up first as patterns of failed logins, and the error log is the standard, built-in record of these events. Without failed login logging, the team has no immediate visibility into authentication failures unless a separate audit mechanism such as SQL Server Audit has been configured.The absence of failed login logging also affects troubleshooting of legitimate authentication issues. Users who cannot connect, applications with stale credentials, scheduled jobs pointing at the wrong instance, and similar problems all produce failed logins that the error log would normally capture. Without this record, diagnosing why a connection is failing becomes much harder.
Compliance frameworks generally require some form of authentication event logging, and the SQL Server error log is the simplest and most universal mechanism available. Disabling failed login logging without a compensating control such as SQL Server Audit creates a gap that auditors will typically flag.
The configuration may result from a deliberate change made during troubleshooting (to reduce noise in the error log) that was not reverted, or from a security hardening template that disabled logging without considering the operational impact. In either case, the default setting of “failed logins only” is the right baseline for nearly all production environments and should be restored unless a documented alternative is in place.
What should you do about this?
Review the current Login Auditing setting through SSMS on the Server Properties Security page, or by checking the AuditLevel registry value. Confirm the current value and identify whether the setting is “none,” “successful only,” or another configuration that excludes failed logins.Change the setting to capture failed logins at minimum, either through the SSMS dialog or by setting the registry value appropriately. The change requires a SQL Server service restart to take effect.
Pair the increased logging with the recommended error log retention practices including a higher number of retained log files and regular log cycling, so the resulting authentication record is preserved long enough to be useful for review and investigation. Without sufficient retention, the additional logging fills the available log files faster and overwrites itself before it can be reviewed.