What’s the issue?
Starting with SQL Server 2017, clr strict security treats every CLR assembly as UNSAFE regardless of its declared permission set, requiring each one to be authorized before it can load. The supported path is signing the assembly with a certificate or asymmetric key that holds UNSAFE ASSEMBLY permission.
The trusted assemblies list provides an alternative. Adding an assembly’s SHA2-512 hash with sp_add_trusted_assembly tells SQL Server to load that specific binary without requiring a signature, which was introduced to ease the upgrade path for existing unsigned assemblies.
Why is this a problem?
Trusting an assembly by hash bypasses the signing model that clr strict security was designed to enforce. Once the hash is registered, the assembly loads with unrestricted permissions in any database on the instance, with no certificate ownership to review and no key to control who can produce an authorized binary.
Adding to the list requires CONTROL SERVER, so a principal at that level can authorize arbitrary code to run under the SQL Server service account. This provides an escalation mechanism, since the entry is a hash in a system view rather than a recognizable object in a database.
This can be a legacy issue. Assemblies added during an upgrade to SQL Server 2017 frequently remain trusted years later, including hashes for binaries that were replaced, retired, or never actually deployed, leaving standing authorization for code that no one is tracking.
What should you do about this?
Review the current entries by querying sys.trusted_assemblies, capturing the hash, description, and the login that created each one. Match each entry against the assemblies actually registered in your databases through sys.assemblies to identify which are still in use.
Remove entries that no longer correspond to a deployed assembly using sp_drop_trusted_assembly, passing the hash. Verify that no application depends on the assembly before removing the entry, since the assembly will fail to load afterward.
Migrate the remaining assemblies to certificate-based signing, which ties authorization to a key you control and can review.