What’s the issue?
The TRUSTWORTHY database property indicates whether the SQL Server instance trusts the database and its contents. When set to ON, code in the database (CLR assemblies, stored procedures using EXECUTE AS, and similar mechanisms) can perform operations that cross the database boundary using the database owner’s authority, including reaching into other databases on the instance.The property is OFF by default for new databases and is preserved through restores. It is sometimes enabled deliberately to support specific cross-database scenarios, but more often it appears as a side effect of restoring databases from environments where it was set, or because someone enabled it during troubleshooting and never reverted the change.
This finding identifies user databases where TRUSTWORTHY is currently ON.
Why is this a problem?
The combination of TRUSTWORTHY = ON and a privileged database owner is one of the most powerful privilege escalation paths in SQL Server. When TRUSTWORTHY is on and the database owner is a member of sysadmin (such as sa), any member of the db_owner role in that database can create objects that execute with the owner’s authority, effectively giving db_owner members full sysadmin-equivalent control over the instance.This escalation path bypasses normal permission checks entirely. The db_owner member writes code, the code is marked to execute under elevated authority through EXECUTE AS OWNER or similar mechanisms, and the trust granted by TRUSTWORTHY allows the code to operate across the instance with the owner’s full privileges. The pattern is well documented as a common method for elevating from limited database access to full instance control.
TRUSTWORTHY = ON also weakens the security boundary around CLR assemblies and certain other elevated features. In versions prior to SQL Server 2017 (and in 2017+ when clr strict security is disabled), TRUSTWORTHY was part of the trust model that allowed EXTERNAL_ACCESS and UNSAFE CLR assemblies to be loaded, providing another path for elevated code execution that depends on the database being trusted.
What should you do about this?
Disable TRUSTWORTHY wherever possible using ALTER DATABASE [DatabaseName] SET TRUSTWORTHY OFF;. The change takes effect immediately. Most databases do not require TRUSTWORTHY = ON, and the default OFF state is correct for the vast majority of environments.For databases that genuinely require TRUSTWORTHY = ON to support a specific use case (typically older CLR or cross-database scenarios), confirm the requirement is current and consider whether the same functionality can be achieved through certificate-based module signing or sp_add_trusted_assembly for CLR assemblies, which provide the same effective access without requiring the database to be trusted.
Combine the TRUSTWORTHY review with the database ownership review, since the two interact directly. A database owned by a dedicated, low-permission, disabled login removes most of the escalation risk associated with TRUSTWORTHY = ON even if the property cannot be turned off, by limiting what the trusted owner can actually do.