What’s the issue?
A logon trigger is a server-level object that fires in response to the LOGON event, after authentication succeeds but before the session is fully established. Triggers are created with CREATE TRIGGER ... ON ALL SERVER FOR LOGON and run under the security context specified in the trigger definition.
They are typically used to enforce connection policies that SQL Server does not provide natively, such as restricting which hosts or applications a login may connect from, limiting the number of concurrent sessions for an account, or recording connection details for audit purposes.
Why is this a problem?
The trigger executes code on every connection attempt to the instance, including connections from applications, monitoring tools, scheduled jobs, and administrators. Any inefficiency in the trigger logic is multiplied across every login, so a query that takes even a fraction of a second adds measurable latency to connection establishment across the entire workload.
A trigger that raises an error or fails to complete blocks the connection entirely. If the failure affects all logins, the instance becomes unreachable through normal connections, and recovery requires connecting through the dedicated administrator connection, which bypasses logon triggers.
Logon triggers can also be leveraged to establish persistent access. Because they run automatically with elevated context and are not visible in the places teams usually look, an attacker who has held sysadmin access can leave one behind to regain access or to capture credentials on every connection.
What should you do about this?
Review the triggers present by querying sys.server_triggers and retrieving each definition with OBJECT_DEFINITION. Confirm with the team that each one was created deliberately, and treat any trigger that cannot be attributed as suspicious until proven otherwise.
Evaluate the logic in each trigger for efficiency and error handling, since both determine the blast radius if something goes wrong. The trigger should complete quickly, avoid querying anything that could be slow or unavailable, and handle errors without denying legitimate connections.
Confirm the dedicated administrator connection is enabled and that remote DAC is configured, since that is the recovery path if a trigger locks out normal logins. Disable rather than drop a trigger when testing changes, using DISABLE TRIGGER [TriggerName] ON ALL SERVER;.