What’s the issue?
UNSAFE ASSEMBLY and EXTERNAL ACCESS ASSEMBLY are server-level permissions that allow a principal to create CLR assemblies with elevated permission sets. EXTERNAL ACCESS ASSEMBLY permits assemblies that reach the file system, the network, and the registry, while UNSAFE ASSEMBLY permits assemblies with no restrictions at all, including calls into unmanaged code.
These permissions are intended for the certificate-mapped logins used in module signing, where an assembly is signed with a certificate and the login created from that certificate carries the authorization. That model keeps the elevated capability tied to a controlled key rather than to a person or an application.
This check identifies logins granted either permission, excluding the built-in Microsoft certificate principals that hold them legitimately and excluding grantees that are already members of sysadmin.
Why is this a problem?
One or more logins can create CLR assemblies that run outside the SQL Server sandbox. Assemblies execute in the context of the SQL Server service account regardless of the permissions held by the login that invokes them, so the code operates with whatever the service account can do on the host rather than with the caller’s authority.
EXTERNAL ACCESS ASSEMBLY alone provides a substantial reach, since file system, network, and registry access from inside the engine covers most of what an attacker would want. UNSAFE ASSEMBLY removes the remaining restrictions entirely, including the ability to call unmanaged code, which effectively means arbitrary execution under the service account.
The grant appears only in the server permissions catalog, not in role membership, so a login holding it looks unremarkable in a standard access review while carrying a direct path to code execution on the SQL Server host.
What should you do about this?
Identify the affected logins by querying sys.server_permissions joined to sys.server_principals for UNSAFE ASSEMBLY and EXTERNAL ACCESS ASSEMBLY in a granted state, and review each holder to determine whether it exists specifically to sign assemblies or is a login used by a person or an application.
Revoke the permission unless the login exists specifically for assembly signing, using REVOKE UNSAFE ASSEMBLY FROM [LoginName]; or the equivalent for EXTERNAL ACCESS ASSEMBLY. Confirm first which assemblies depend on the grant, so removing it does not break code that is still in use.
Where assemblies are required, grant the permission to a certificate-mapped login used only for module signing rather than to a login used by a person or an application.